DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Velocity Is Not Enough: Rethinking Risk in Agile Software Development
  • How Does a Scrum Master Improve the Productivity of the Development Team?
  • Bounded Rationality: Why Time-Boxed Decisions Keep Agile Teams Moving
  • Why One-Week Sprints Make Vibe Coding Work Better

Trending

  • Why Pass/Fail CI Pipelines Are Insufficient for Enterprise Release Decisions
  • Lambda-Driven API Design: Building Composable Node.js Endpoints With Functional Primitives
  • Key Takeaways From Integrating a RAG Application With LangSmith
  • Why We Chose Iceberg Over Delta After Evaluating Both at Scale
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. How Many Stories Per Sprint? Rules of Thumb

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.

By 
Andrew Fuqua user avatar
Andrew Fuqua
·
Updated May. 18, 22 · Opinion
Likes (1)
Comment
Save
Tweet
Share
39.3K Views

Join the DZone community and get the full member experience.

Join For Free

The right amount is 5 to 15 stories per sprint. Anything less than 5 may be fine on the low end from to time. Over 15 is a high limit for a team. Most stories should not take more than half a sprint to develop and test.

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.

Sprint (software development)

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

Opinions expressed by DZone contributors are their own.

Related

  • Velocity Is Not Enough: Rethinking Risk in Agile Software Development
  • How Does a Scrum Master Improve the Productivity of the Development Team?
  • Bounded Rationality: Why Time-Boxed Decisions Keep Agile Teams Moving
  • Why One-Week Sprints Make Vibe Coding Work Better

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook