Over a million developers have joined DZone.

How Many Stories Per Sprint? Rules of Thumb

How many user stories should you have in a spring? How big is too big? How many stories per iteration per developer? Make the most of your sprints.

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

I’m often asked how many user stories you should have in a sprint and how big is too big for a story. People are looking for guidance.

Stories Per Sprint

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. It also subtly takes the focus off of swarming and puts attention toward a developer per story.

5 to 15 stories per sprint is about right. Four stories in a sprint may be okay on the low end from time to time. Twenty is an upper limit for me if we’re talking about a Web team with lots of small changes to do. Twenty-five may be okay for maintenance teams knocking down a backlog of small defects, but that’s way too many for new development of actual user stories. If you can do that many, your stories are too big, your sprint is too big or your definition of done is too weak.

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 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 that last comment: should be able to complete each story in 1 to 3 days. 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. (And higher quality and better cross-training.) 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.

Points Per Story

What’s the maximum number of points for a story? How big is too big? How many points is too big for a story depends on the team’s pointing scale. I’ve known teams that start with 5 (5, 10, 15, 25, 40, and 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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Andrew Fuqua, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}