Size Matters: Creating Optimally Sized User Stories

In Agile development methodologies, User Stories express desired product functionality from the perspective of a given persona. It’s these User Stories that the development team will estimate and ultimately implement as part of a development iteration/sprint. As a product manager, if you want predictable results and a steady burn-down from your development team, it’s incumbent upon you to provide the team with stories that are just the right size.

It would be easy to assume that story size is a function of the feature desired, but you’d be incorrect in doing so. In truth, story size is determined by the product manager when he/she determines how best to break-up the desired functionality into User Stories. Any non-trivial product feature can be written as a single large story, or multiple smaller stories. It’s easier up front to write one big story, but the cost will be paid as volatility during implementation. Given the logarithmic scale used to estimate story points, the larger the story, the less precise the estimate. The less precise the estimate, the more volatility there will be in your release. It’s really that simple.

The optimal story size is one that balances the up-front work required to split a feature into multiple stories, with the desired predictability on the back end. If you track the actual points required to complete stories for a few releases and graph the difference by story size, you will start to see a picture like the graph below.

story-sizing-graph
To obtain this information, I measured the difference of “actual points to complete” vs. “estimated points to complete” for stories of various sizes over several releases. The data clearly shows that stories that are estimated as 8 points or more are not only estimated more poorly than smaller stories, but that the estimates are off by a greater degree. As you can see in the graph, there is a clear inflection point at the 5-point mark; this was our optimal story size.

Since we used the point scale proposed by Mike Cohn (1, 2, 3, 5, 8, 13, 20…), it’s true that this observation is simply a function of the algorithmic scale used to estimate. More pragmatically, however, what this indicates is that you will have more volatile, less predictable releases when your releases contain large stories. For this team, the optimal story size was 5 points. Your team may have a different optimal story size, but you can be certain it will be in the 3-8 range.

In summary, if you want more predictable, repeatable results from your development team, then help them out by making the effort during release planning and create optimally sized stories. Track estimates vs. actuals, look for the inflection point, and then try to keep your stories that size as much as possible.

Share

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

Comments

We have been doing Agile Development for over 2 years now and our experience matches yours. Couple of additional thoughts. We started using the scale that you talk about but we found that this was difficult for new team members to start actively participating in planning, so we moved to the model of 1 point = 1 day. However the same assumption holds true. Storied that estimate over 5 (a week) had a higher likelihood to miss estimates. As a best practice we try and keep points on a story to 5 or less. If its bigger than that we think hard about how it could be simplified or broken apart/iterated. Couple other things we started doing to help get a better handle on estimates and team throughput: 1. During planning we estimate both technical risk and business risk (H,M,L) which have multipliers associated with them, so for a given story we have best case and a risk adjusted. 2. We do some level of capacity planning for the team before each sprint. We factor in any overhead requirements, vacation, developer skill level etc. We then get an estimated point capacity and use that during planning so that we know when we are getting close to our limit for a given sprint time.

Kevin, I really like the idea of the risk factor. Have you written this up anywhere? I’d like to read more about the specifics.

In his book “Agile Estimating and Planning,” Mike Cohn recommends using a risk rating to affect prioritization (high risk – high reward stories first), but it seems you are talking about something different here.

Leave a comment

(required)

(required)