ZenHub Community

Connect with global technologists to get answers, support and inspiration on the best ways to build great products using ZenHub

The new quick-access Productivity Insights is here!

Looking to keep tabs on your team’s productivity & sprint progress? The new quick-access Productivity Insights is here to help!

You can read the full blog here and check out some of the highlights below:

*On average, user stories spend:
5.5 days in development
6.3 days in review

*On average:
47% of user stories are completed in a sprint
27 user stories per sprint
11 user stories are completed by end of the sprint

Questions? Feedback? Want to just chat about it? Post your comments below and let’s talk!


I’m a bit shocked at some of the stats to be honest. I’d like some details on how this was calculated because it’s completely off from my experience (with current teams or in previous teams too).

For instance, I currently work with 3 teams and thus 3 concurrent sprints. Is the 27 stories presented here a “per team” metric or across the entire account. If it’s the latter, then although a tad high, this would be close to the total amount of stories pulled in across all 3 teams (each team having 6-8 stories).

Also, most of the teams I’ve worked with either have successful sprints or are off by 1-2 stories. A 47% story completion rate per sprint sounds abysmal to me, am I just really lucky with my teams or are other teams just generally bad at planning? Hmmm…


Hey Sascha,

Thanks for your reply, and I’m interested to hear about your team’s experiences!

For most organizations, each team has their own workspace. But in some organizations, multiple teams choose to work in the same workspace, meaning they may also work in the same sprint. So the 27 stories are an average from both scenarios - one sprint per team, and one sprint per organization.

To be honest I was a little surprised by the data as well, but there’s a few things to keep in mind when looking at the numbers:

  1. Teams that have been sprinting longer have higher completion rates. Teams that are just starting have very low rates. We’ve got a little bit of everyone in this sample.
  2. When teams first start with Scrum they often have longer sprints (up to 4 weeks) and work their way down to shorter sprints (closer to 2 weeks)
  3. Overloading Sprints can be a common problem for teams. We often see incomplete issues being moved to the following sprint.

We’d love to be able to provide more of this type of data in the future, so that teams can learn from one another. I’m curious to hear about what other types of insights you would be interested in! For example, how could we break down this data further so that it would be most useful?

1 Like