Skip to main content

Success Factors in a Scrum Sprint

Last week, I posted a summary of the responses to my poll on scrum sprint success and story size. I also proposed a simple definition of success: a successful Scrum team delivers what it promises.

A good Scrum team does not systematically over-commit. It doesn't under-commit either - not one single response indicated that the team usually delivered more that 110% of its commitment. By this definition, 32% of the respondents are "successful" while 68% are "improvable".

Let's take a closer look at Team Size, Story Size and Sprint Duration and how the relate to relate to successfully completing the a Scrum Sprint.

Team Size and Sprint Duration

Two week sprints are by far the most popular with 50 respondents, and the distribution of on the number of stories committed to each sprint looks pretty much like a bell curve centered around 6 stories/sprints. Three week sprints a relatively popular - 17 responses - but the volume of data is probably too small for a curve to form.  With a total of 13 responses, it's unlikely that the data for 1-week and 4-week sprints is at all representative.

Number of Stories

The number of committed stories peaks at 6 to 8 for teams doing two-week sprints and 4 to 5 for teams doing 3-week sprints. I am puzzled by the dip at 6 to 8 stories for three week sprints.

Number of Story and Sprint Success 

Queuing theory tells us that implementing more, smaller stories should be more predictable than fewer large stories. The numbers generally bear this out. (The data point for 2 to 3 stories is probably not representative - there were only 5 responses, all others had 15 or more responses).

Sprint Length and Team Success

Are shorter sprints better? A lot of common wisdom points to this conclusion, but it is not supported by the poll data. The average of all the data was that 38% of the teams are 'successful.' Teams doing 2 and 3 week sprints reported slightly worse than average and 1-week teams slightly better.

Most intriguing are the teams who reported 4 weeks sprints. They reported a success rate of 75%! There are only 8 teams reporting, so it may not be representative. But it may also be that the value of longer sprints are underestimated.

Team Size and Sprint Success

Teams with 1 to 3, 6 or 9 to 10 remembers were less successful that the other sizes. I don't think there is much of a trend here.

Maximum Story Size and Sprint Success

I was expecting that teams which took on very large stories would be less successful than those which do not. This was only true for those teams which reported taking on stories larger than 40% of the teams capacity for the sprint.  11 Teams reported taking on stories larger than 40% of the team capacity, only one reported being usually successful in accomplishing the sprint.

Much to my surprise, teams reporting taking on 35 to 40% were the most successful, followed by teams that limit the largest story to 5%. The sample sizes for those data points were rather small, with 5 or 6 respondents in each category, so I would take that with a grain of salt. Among those categories with more than 15 responses, the range of 15 to 30% did best.


Having analyzed the data, I think the survey would be much useful if there were a factor of 10 more data points - 800 to 1000 would be really good. Still, looking at this data, some trends are taking shape:
  • Doing Scrum well is very difficult. Most teams do not reliably deliver their sprint commitment by the end of the sprint.
  • There is no one right way to do Scrum. Both "Successful" and "Improvable" teams come in all sizes and configurations.
  • At least up to a point, more stories per sprint are better. It looks like 10 to 15 is a good number. Most teams should consider slicing their stories smaller.
  • Very big stories are are unlikely to be completed in the sprint, but an occasional moderately sized story doesn't look like it's a problem.
  • Maybe 4 weeks sprints are better than their reputation. The results could be wrong, but should be explored more deeply.
P.S. Does anybody with substantial readership think this study was cool and useful? I would love to repeat it with the goal of substantially higher feedback and see the trends become more apparent. Please contact me!

The story size poll is still active - I'll keep an I eye on it and when I get 200 responses, I'll evaluate the data again. Presently I have 85.


Unknown said…
Very insightful, thanks a lot!
Scrum Software said…
Very interesting statistics here.. I have to agree that there is no one way to develop with scrum. Companies and Project manager's sometimes seem to get caught up in all of the rules/fads of scrum instead of creating a system that works with their culture and team. Excellent post and I look forward to reading more.
I think this was very interesting as well. It would be nice to try it again and push for more input to see if the trends become a little bit more clear and then maybe ask some clarifying questions to try and draw unique differences and similarities.

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…