Andrew Fuqua
Reading: Agile Story Points: How Many Stories Per Sprint?
Save for Later
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 sprintis 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 userstories 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 lastcomment: should be able to complete each storyin 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.
WhitepaperLead a Structured and Disciplined Agile TransformationDownload NowNext› Where Does an Agile Transformation Start? Everywhere.
Leave Comment
Up Next:
Comments (11)
Ty Burn
ReplyThanks 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
Abbas Dar
ReplySeriously? 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
ReplyThanks 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
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
Andrew Fuqua
ReplyAh! Good catch Stephan. Thank you. I fixed the error.
Reply
Narayana Murty
ReplyHi 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 MurtyReply
Juan Nallar
ReplyA 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
Bryan Patrick Coleman
ReplyI stumbled across this article in a search I was doing for the opposite problem. I am now a manager, and am struggling with the number of velocity points the developers are estimating for each user story. When I developed my team would typically do 30 to 40 user stories per developer per two week sprint. Later when I first pulled together a team and was directly over the team they throughput was similar. Now that I have become a manager of managers, I am getting story point estimates that I would have estimated at maybe an hours worth of work coming across with 3 or 4 days on the estimate. Other than firing everyone and getting new developers are there any resources for getting your team to perform faster?
Reply
Sam P
ReplyBryan: If you’re getting estimates in days then there’s probably something wrong at the start. Assuming that the 3-4 day estimates are really in story points and you are just working backwards from the team’s velocity I think you still need to track whether the estimates are accurate and the work is slow (query why the work is taking so long), or whether the estimates are overly pessimistic and the work is fast/normal (query why the estimates are so pessimistic).
If you are measuring velocity by number of user stories completed (3-4 per day per person) rather than story points it doesn’t sound like story points are serving you well. Surely the user stories could be of wildly varying size so user stories/dev/sprint is not very meaningful. A sustained rate of 3-4 stories/day/person getting to done suggests either very small stories or very productive and error-free developers.
If the issue is that the real velocity is low, then it doesn’t sound like user stories, estimation etc are your issue and you will need to drill into the team-specific issues for low performance. There are unlikely to be generic answers which are useful.
Reply
Logan
ReplyWe are a team of two developers and together take on around 20-25 points per two-week sprint. This current sprint, the other developer is working a single 5-point ticket and says it’ll take the entire sprint. Meanwhile I’m doing a 5, a couple of 3’s and a bunch of 1’s, totaling 19 points. I’m letting it slide for this sprint, but this isn’t going to work for me long term.
Reply
GHRT1-74-bart
ReplyIn our team, estimations are based upon extremely experienced people, while most of the team consists of juniors. We take the average of the last 3 sprints and multiply by 1.5 to get something we never can do. But we want to be sure there is enough work for the sprint, so nobody has to wait for the next sprint to take any task.
For me personally, this is not a commitment anymore, it’s not even possible to finish the sprint on time. When things are red for a long time, I get even color-blind. But, when the goal is high, most are motivated to do some extra work, e.g. in the weekend. But no matter how much you do, the result of work is more work.
Reply
Leave a comment
Leave Comment
