Skip to main content

Saved Posts

How Many Stories Per Sprint? Rules of Thumb

Andrew Fuqua
Reading: How Many Stories Per Sprint? Rules of Thumb

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.

User Stories Per Sprint

I’ve heard some coaches recommend “3-6 user stories per iteration per developer”. That’s a bad rule of thumb. For a team of 7 developers you would have over 20-40 user 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 user 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 small, your sprint is too big or your definition of done is too weak.

Most user 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.

Swarming User Stories

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 user 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 counterproductive.

Points Per Story

What’s the maximum number of points for a user 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.

Next Where Does an Agile Transformation Start? Everywhere.

@AndrewMFuqua is a founding member of XP-Atlanta in 2001. Currently an Enterprise Transformation Consultant, Andrew has previously held positions in management, product management and software development at companies like Internet Security Systems, Allure Global, and IBM. Andrew earned a BS and MS in computer science and has an MBA from Duke University.

Comments (7)

  1. Ty Burn
    Reply

    Thanks tons for writing this article.

    The information matches closely with my experience, and gave me a reference point that I need as I push back on a global enterprise client that is dicing up the work into non-productive little elements.

    The one point I might make more strongly is the value of simplicity & cost of complexity.

    The simplest decomposition of the work is probably the right one. Anything more or less will be sub-optimal. Obviously there are facets and nuances to what is simple. Practitioners can make individual judgements on that front.

    Reply
  2. Abbas Dar
    Reply

    Seriously? What are you talking about? There is no defined number on how many user stories you take into a sprint. You take in however many stories that your sprint capacity allows, whether that be 2,3,4, 10, 20 or even 40 it doesn’t matter! What matters is that in, each user stories develops that functionality, whether it be, let’s just say for simplicity sake creating a new field on an application form; end to end, such that the user story will create the field, have data populated into it with validation and store the value of that input into the database. You wouldn’t break that story into 3 given the architectural layer, you’d have one and 3 technical sub-tasks in order to complete that one user story. Once you’ve hit the maximum capacity of your sprint based on the teams estimation and the calculated capacity the number of user stories at the end of that whether it be 2, 4, 10, 20 or however many, still has no relevance what so ever!

    Reply
    • Andrew Fuqua
      Reply

      Thanks for asking for clarification, Abbas.

      You say that 2 is fine, 40 is fine, any number is fine. How about five hundred stories in one sprint for one team? Would that be too many? How about two thousand stories per sprint per team? You’d probably agree that there is some upper limit that would be excessive, unmanageable. I’m stating a case for where I think that limit is, and how one might want to think about it.

      And can you agree that zero (0) stories per sprint are too few? So there is a minimum reasonable limit as well.

      I’m arguing that stories can be too small. I’m arguing that stories can be too big. I’m arguing that a team can have too many or too few people on it. I’m arguing that a sprint might be too long… or too short. I’m suggesting that the number of stories a team can do is an indicator of those issues.

      I’m suggesting that if a team can only get 1 or 2 stories done in a sprint, it might be difficult to finish every sprint cleanly, with no stories partially complete, without having to split stories because they started something that couldn’t be finished in the same sprint.

      I’m suggesting that it’s difficult to track and demo 50 stories each sprint, if a team can do that many.

      In any case, it’s worth considering the size of stories, of the team and of the sprint.

      Reply
  3. Stephan
    Reply

    ” If you can do that many, your stories are too big,”

    I guess you meant to write: your stories are too small.. right? If the stories are big, how could you do more than 20 of them in a sprint :)

    Reply
  4. Narayana Murty
    Reply

    Hi Andrew,

    Very helpful Article.

    Please let me know if there is any universally accepted standard or technique to map a story point to no of hours.
    For example, map a story point to 4 hours or a story point is equal to 8 hours.
    Is there any minimum or maximum limit on the no of hours a story point can be mapped to.
    For example, a story point can never be less than 1 hour or greater than 3 hours.

    Thank you,
    Narayana Murty

    Reply
  5. Juan Nallar
    Reply

    A user story explains what the user wants. I can or cannot fit in a sprint. Stop saying User Stories are PBIs as it confuses most of the people.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *