What is the maximum story size to include in an iteration?
By popular demand (OK it was only one person who asked, but I am sure he is very popular), this post will cover our experience at Huddle on what makes an appropriate maximum story size for it to be planned in an iteration or sprint. Again this is a much asked, and much answered question, and this is not the right answer - just the answer that has worked for us (and a few that did not work along the way).
First up, we use story points to estimate stories, and our scale will be different from yours, so don’t take the actual story point size too seriously - you will need to map this back to your own scale. For reference we use a slightly mangled Fibonacci sequence for our estimates: 1/4, 1/2, 1, 2, 3, 5, 8, 13, 20… We currently have 9 developers and 3 QA analysts, and our velocity (for a two week iteration) is around 36. Which means that at the moment (and don’t ever tell the development team I did this calculation!) a point represents a bit over 3 man-days of effort. This is for production ready code, so includes test planning, test execution, bug fixing, to-ing and fro-ing with the customer to clarify requirements, and customer sign-off.
When we first started with our agile process, we scheduled an 8 point story or two. Big mistake. It turned out that estimating a story as an 8 just meant “really very big” and some things that were estimated as 8 turned out to be clearly impossible in one iteration. We were young and naive, but quickly learnt from our mistakes, and made 5 points our maximum.
Over the next few iterations it turned out that 5 point stories tended to be ones that involved some reengineering, and regularly expanded to keep a few people busy for the entire iteration. There was a major tendency for scope creep (often architectural scope creep rather than functional) and analysis at the start of the iteration often revealed that there was a bit more to it than we had thought. Noticing this trend, we decided that our maximum story size for inclusion in an iteration is 3 points; anything larger has to be split down in to smaller stories.
The 3 point maximum has worked well, and we have stuck with it for probably 9 months now. 3 points for us is roughly 10 man-days of effort, with probably 3 or 4 people working on it during the course of the story. In drawing conclusions, I think it is more useful to look at this absolute size of the story rather than the size relative to the iteration as a whole: i.e. 10 man-days is a more useful measure than the fact that at the moment our maximum story size is < 10% of our usual velocity. The maximum size of 3 points served us well even when we had a team of half the size. Having said that, having too few stories (fewer than 8?) in an iteration starts to make delivery of the iteration very “all or nothing”, and gives very little flexibility for descoping stories if new requirements emerge or circumstances change (see Colin Grossman’s excellent post on the Huddle blog covering our approach to this). As an example our current iteration has 25 stories in it, ranging in size from 1/2 point to 3 points.
So in conclusion, I recommend picking a maximum story point size at a point on your scale that represents no more than 10 man-days of effort, and reducing this further if your team size or velocity mean that you would regularly be planning fewer than 8 stories.
Of course more important that all of this is to remember to inspect and adapt. Use retrospectives to change what isn’t working and keep what is.