User Stories Revisited Part 3 – Sizing

In the third part in my series on user stories (Part 1 here, Part 2 here) will briefly cover some points on estimating user stories.

“How big should a user story be?” “What’s the difference between an epic and a story?” “How do I estimate the size of a user story?” “How do I know when a story should be split?” “How do I split stories?” When I first started working with user stories, I had these questions and I was very frustrated with the available literature. There were few clear examples or instructions given.

It didn’t take long for me to understand why. There are simply too many factors to consider to give any clear guidelines or templates. The same story can have wildly different sizes and may need to be split in different ways, depending on your team, your product, dependencies and a myriad of other factors. As an example, the story

As a user making a purchase, I want to be able to log into my account at any point in the transaction so I don’t miss the opportunity to apply my coupons.

could be fairly small if the account information and shopping site are managed under one domain, the team has experience working with this functionality, and there are no dependencies on other systems or teams. On the other hand, if this requires cross-domain authentication, a new or unknown API, legacy code and/or dependencies on services managed by different teams, this becomes much, much larger. These factors will also influence the way the story is split.

First tip is that estimating and splitting the stories must be done with the developers who will be doing the work. This may seem obvious to some, but a lot of organizations trust analysts, architects, lead developers and project managers to do this work. In fact when I first started working with user stories, many moons ago, I split all the stories myself, thinking I was being more efficient. In reality I was making a mess.

Second, expect to have to repeat the estimation exercise. The first pass may result in more questions than answers, as your developers will often think of situations and opportunities you didn’t.

Third tip is that estimating is a learning process. If you’re new to the product, team or to Scrum, there will be some trial and error. A lot of trial and error.

Here are some guidelines to help figure out whether the stories are generally too large or too small.

The stories may be too big if:

  • your team’s estimates are consistently wrong, meaning that the team does not achieve the sprint goal within the sprint or completes the stories early. You might think that finishing early means the story was too small, but it’s also possible that it was too big, with many unknowns and the team’s estimate was a worst-case scenario
  • the decisions made throughout the sprint most often require reducing the scope of the story rather than exploring ideas and making it better
  • the team isn’t able to contribute much to the story. Usually ideas surface as the team is working through the story and these can be worked into the product. However, if the team is struggling to deliver on time each sprint, they will deliver to the minimum specification
  • you’re often arguing with the team to reduce their estimates. Negotiating with the team to change the scope of the story in order to reduce the effort is fine, but you should always respect their estimate

The stories may be too small if:

  • the backlog is impossible to prioritize or keep track of. You’re overwhelmed with the stories and you can’t remember what many of them relate to
  • during planning the team has consistently 1 or 2 subtasks per story, or none
  • there is no room to be creative in implementation. The story almost codes itself
  • your stories describe UI elements. You definitely need to step back a bit and focus on communicating the value that the story will deliver to the user and the organization, meaning the what and why of the story, rather than the how

One last tip – an epic is simply something that you and your team agree can’t be completed in one sprint. Different tools, like JIRA or Taiga, define and apply the concept a little differently, but when it comes down to it, an Epic is simply a story you need to split.

Keep in mind that these are my own experiences. There are many good books out there on Agile estimating and story writing which have a lot more to say on the subject than I can summarize in a blog post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s