Take the 2-minute tour ×

Just ran across this figure, and wondering if there's another well know source than would help confirm these numbers:

Based on data I analyzed on successfully finished sprints, I determined that a team should average around 1 to 1-1/2 user stories (product backlog items of any sort, really) per person per sprint.

SOURCE: Mike Cohn's Blog on "Should the Daily Standup Be Person-by-Person or Story-by-Story?"

share|improve this question

closed as too broad by gnat, Giorgio, MichaelT, World Engineer Mar 21 at 13:43


So if you are doing more, does that mean you have great programmers or your Sprint is too long? –  JeffO Mar 8 '12 at 17:20

6 Answers 6

up vote 7 down vote accepted

Productivity is influenced by a number of factors - organizational culture, experience with the language and tools, knowledge of the project, specifics of the process being used, outside factors such as regulations, and capabilties of the team as a cohesive unit. This is why, when estimating projects, the most useful data is that of the specific team that will be conducting the work. As you generalize to organizational, industry, and then throughout software projects, productivity becomes a fuzzy area.

One of the advantages of iterative development is that you go through all of the phases many times on a single project, allowing you to gain insight into the process and the team. You might start with organizational data from past projects, but very quickly (2-4 iterations) get team-specific data for project planning.

The number that you cite (1-1.5 user stories per sprint) is the highest level of abstraction. The best time to use this number is when you have no industry-specific data from whatever domain your product falls in, no organizational data, and no team specific data - early on in your first projects using Scrum. It probably comes from teams using all kinds of variants of Scrum, including combining Scrum with other process improvement techniques (Kanban, CMMI, Lean). I'd trust using this number as it stands, since Mike Cohn and Mountain Goat Software are well-respected agile consultants. However, as soon as you have data from your organization (or, even better, your team), use that instead for planning sprints.

share|improve this answer

This would be a poor thing to worry about or even try to measure, this number is going to vary widely by skill of programmer, complexity of story, experience of programmer and team, experience of those creating stories, maintainability of code-base...

You should be worried about things like does everyone seem to be contributing to the best of their ability, is the client happier today than yesterday, does everyone/most think that this process is working better than the last process we tried?

share|improve this answer
So your comment, I mean answer is that Mike Cohn's analysis was useless, right? Also, you state, "this number is going to vary widely by skill of programmer, complexity of story, experience of programmer and team, experience of those creating stories, maintainability of code-base" -- but given no reference as to how you reached that conclusion. –  blunders Mar 8 '12 at 15:17
I wouldn't say its useless. that sounds kinda harsh –  user962206 Mar 8 '12 at 15:21
@user962206: Agree, though I don't believe rephrasing Ryathal's statement, "this would be a poor thing to worry about or even try to measure", as saying Mike Cohn's analysis was useless would be a stretch; meaning I was asking Ryathal if that's what he meant, since to me, that appeared to be what he was saying. –  blunders Mar 8 '12 at 15:26
@blunders yes I'm saying that number is useless, it's like saying each person should write 20LoC per day. –  Ryathal Mar 8 '12 at 15:37
Common practice in Scrum is to have the team estimate the complexity of the user stories presented to them. Some will be highly complex, some simple. Complex ones take more skill and time to complete than simple ones. Thus "this number is going to vary widely by skill of programmer, complexity of story, experience of programmer and team, experience of those creating stories, maintainability of code-base." –  Matthew Flynn Mar 8 '12 at 17:17

I think at a fine grained level saying "everyone should complete 1.5 stories per sprint" is the risky interpretation of the analysis. What I've found is that over time, the team settles on specifying stories of similar complexity. It forms a baseline by which you can appropriately plan going forward. In other words velocity. I never like measuring velocity by number of stories but rather by story points. In general though it washes out because of the difference in size between stories (smaller stories offset larger stories).

It's nice to see that he discusses differences in sprint length (longer sprints tend to tackle larger stories) and team size in the impact here. Also pulling back the curtain (i.e. having detailed tasks related to the stories) provides more visibility into what goes into completing the story (which is ultimately what that post is about -- visibility).

So as a rule of thumb, Cohn is saying target around 1-1.5 stories per developer per sprint. Much more than that, and you risk not hearing progress of a story until you're deep within a sprint. Lean addresses this by leaving stories in the backlog until they're ready to be pulled into development. What Mike is saying is that your effective Work In Progress for development should be limited to 1.5X where X is the size of the development team.

share|improve this answer
Maybe it's me, but since when would ad-hoc analysis by one leading professional about an average lead to the conclusion that "saying 'everyone should complete 1.5 stories per sprint' is the risky interpretation of the analysis." Fact is that people do analysis and that analysis is sometimes flawed. The question is about if another source respected source exist on the topic; of which so far only one answer addresses, if only by saying Mike's analysis is good enough and no other source is needed. –  blunders Mar 8 '12 at 17:24
For example, I discovered what appears to be a flawed calculation for the "7 people" per team from Jeff Sutherland; see the first comment in this answer for more information, which if you use Jeff's numbers, but not his calculations says a team of 7-people is the most expensive, and 14-people is the least based on my understanding of his numbers. –  blunders Mar 8 '12 at 17:32
What I was saying is that while Cohn's analysis lines up well with what I've seen. An extreme interpretation of that analysis would be (in other words someone could jump to the conclusion that) every developer should complete 1.5 stories per sprint. There is the risk that someone will get that message from that statement in isolation. What I argue (and from my understanding of the post) is that there is much more to take into account when planning/tracking an agile project. –  Mike Brown Mar 8 '12 at 17:32
Ahhh...I get what you're saying. I can confirm from my experience that over time, when applied successfully, an agile team will see about 1.5 stories per developer. But I think this is the result of the process and not a hard rule. –  Mike Brown Mar 8 '12 at 18:03
+1 @Mike Brown: Yes, that was my understanding from your original answer, and agree it's not a hard rule. –  blunders Mar 8 '12 at 18:13

For me, it depends on your sprint or depending the level of task to be done. From my current experience I am working on a system we created several user stories. for every week we would do stories that is assigned to be done on that week, if all task are done. we move to the next sprint even though we are ahead of schedule.(Assuming the task has been done correctly)

in my team for every person has 3 stories that is needed to be done. and I am surprised we are supassing our limitations.

it just depends on the programmer. but things like this should not be an issue. the issue here is that the client will get what they want or asked for.

share|improve this answer
+1 @user962206: Just to be clear, believe you're saying that within your current team that each person completes roughly three stories per sprint, and that sometimes sprints are completed faster than planned; also, appears you're saying that 3 stories are assigned per person, but since that goes against my understanding that stories are completed as a team, I'll assume I'm misunderstanding you. Thanks in advance for the clarification, and while you're not citing a well know source, it is better than no feedback! –  blunders Mar 8 '12 at 15:31
Well the source is basically from our experience and the insights of our instructor. it really depends on the level of the task to be done, and the experience of the programmer if the sprint is easy expect it to be done in a fast way. and in my team task are done by an individual or by pair. depends on the level of the task. –  user962206 Mar 8 '12 at 15:34

The last I heard was that it was 1.5/2x the number of team members.

Also note, that Mike Cohn is not implying you should use these numbers, he is simply saying that over the many years in the industry and the many teams he has coached, he has found 1.5x/2x stories per team member to work best. He gave this answer when I asked him what he considered to be the ideal user story size.

share|improve this answer

Daft question, but is not the answer driven out through a) intitial team estimation of story points (or whatever) from any sprint planning session and then b) sprint velocity and/or burndown?

We sometimes reach for the stars in the first sprint then quickly discover not all stories are what they seem (something always hidden). We then readjust our next sprint estimates for the next story pulldown from the backlog.

One or two stories max per dev is kind of where most my team's mobile app projects have landed - across a range of organisations, projects and platform devs.

share|improve this answer
how does this answer the question asked? –  gnat Oct 3 '13 at 15:18
It's not a daft question because you can split (or even merge) stories if you think it's a good idea to try to target an average number of user stories per team member per sprint. I'm not saying that's necessarily a good idea - I don't know, I haven't tried it - but in principle it wouldn't go against any scrum principle to do it, as long as it didn't bias the estimation process. –  Robin Green Dec 22 '13 at 15:04
