February 12, 2015

How Many Stories per Sprint? Rules of Thumb

I'm often asked how many stories you should have in a sprint. People are looking for guidance.

I've heard some coaches recommend “3-6 stories per iteration per developer”. That's a bad rule of thumb. For a team of 7 developers you would have over 20-40 stories which is likely way too many. That kind rule of thumb also subtly takes the focus off of swarming and puts attention toward a developer per story, a story per developer.

My rules of thumb:

5 to 15 stories per sprint are about the right number, particularly for the clients I often work with in which there are maintenance teams knocking down a backlog of small defects and teams doing Web work with lots of small changes to do. 4 stories in a sprint may be okay on the low end from time to time, and 20 is an upper limit for me.

Most stories shouldn't take more than half the sprint to develop and test. Having 1 story each sprint that takes more than half the sprint is about all I would advise, and in that case all the other stories should be very small. For a 2 week sprint, it's better if every story can be completed in 1 to 3 days. (Adjust that for longer sprints.)

I need to elaborate on my comment that it's better if every story can be completed in 1 to 3 days. After stating that I'm often asked whether that's the developers working independently or all together. The answer is "whatever you are doing today." It is best if the team can swarm stories such that multiple developers can work on a story at the same time. If  2 or 3 devs can work on a story at the same time, then you can have larger stories finished within that 1 to 3 day rule of thumb. But if the team isn't there yet, if that's not the way they work today, then having stories that are too big given the way they are working is counter productive.

What's the maximum number of points for a story? How big is too big? How many points is too big for a story varies according to the team's pointing scale. I've known teams that start with 5 (5, 10, 20, 30, 50, 80). For them, 50 and 80 were too big. I've also known teams where a 1 point story would take less than half a day. For them, a 13 might not be too big. If a 1 takes more than a day, then 13 is probably too big. Generally, too big is an order of magnitude larger than the typical small story.

Here's an example: Assume my 1 point story takes a day or two and once in a while we have something that is truly tiny and we call those half a point. The 1 pointer is my typical low end of the range. I have something smaller, but it's not typical. A 13 is an order of magnitude larger that 1 point story. It's very difficult to keep the scale linear when there is that much diversity in your story sizes.

No comments:

Post a Comment