Sprint Capacity Calculation for Scrum Teams

I have been a scrum master for my current team for almost a year now. I have tried couple of methods to calculate sprint capacities and it took several iterations to arrive at something that now works best for us and is explained in detail in this article.

Story Points and Developer Days

In our team we estimate tasks in terms of story point(SP) and it was very important for us to keep it as simple as possible for us to estimate tasks and also to make it easily convertible to time estimates so that all tech and non-tech stakeholders could understand when we say a task would take X story points(SPs). We kept an SP as follows:

1 SP = 1 Developer Day

If we commit that a task takes 1 story point for completion, what we essentially mean is that it can be completed by 1 developer if he works 1 full day (i.e 8 hours) without any interruption. In real world, no developer works uninterrupted.

Ideal Scenario

Lets assume that we have a team of 5 developers and sprints are 2 weeks long (i.e 10 working days) with typical working hours being 8 hours a day. Assuming that developers are working uninterrupted in the sprint:

Total Developer Hours = 5 Devs x 10 Days x 8 Hours/Day = 400 Hours
1 Developer Day = 8 Hours
Total SPs in a Sprint = 400 Hours / 8 Hours = 50 SPs

Now let us look at how to accommodate the missing pieces in our calculations so far.

Focus Factor

In all the above discussion we overlooked the fact that developers indeed get interrupted during their work. This is a very common problem in my team as our product features were spanned across multiple horizontals in the company. So to account these into the estimates, we used the idea of focus factor. Focus factor reflects how much percent of the time a developer effectively gets to work on tasks in the sprints.

We took multiple iterations to fine tune this number as we had to carefully consider following key factors where we spend most of our time:

  • Scrum ceremonies (planning, grooming, retrospectives, demos etc.)
  • On-call responsibilities
  • Design review meetings
  • Code reviews
  • Other meetings like manager 1:1, hiring interviews, learning curves etc.

After iterating through historical data from every team member, we finally ended up with the fact that we were 60% efficient during the sprint which lead us to:

Focus Factor = 0.6

Sprint Capacity with Focus Factor

With the definition of focus factor clear, let us try to accommodate it in our calculations:

Total Effective Developer Hours  = 400 Hours x 0.6 = 240 Hours
Total Effective SPs in a Sprint = 50 SPs x 0.6 = 30 SPs
1 SP = 1 Effective Developer Day = 8 Hours / 0.6 = 13.33 Hours

As developers, we continue to estimate tasks without considering any interruptions as these are already accounted in the capacity planning. Also, all stakeholders knows 1 SP means the deliverables can be expected in 1.5 working days approximately.

Revising Focus Factor Periodically

Good part about focus factor is that you can tune it proactively depending on each sprint. I always try to keep at least one or two upcoming sprints ready and I look at the kind of tasks involved and also team dynamics changes if any to see focus factor adjustments are needed for these sprints. eg: In our case, we revised it recently to consider the fact that we got a dedicated team member for testing our code changes. The same applies when developers are leaving the team.

As the team matures over time, developers get more productive and this mean they can do a lot more in 1 SP than they did one year ago. This can be tackled two ways:

  1. During task estimations, we try to give a lower estimate for things we got too good at, which previously would have been costly because of some learning involved. This is what we adopted as its natural solution.
  2. Increase the focus factor.

Excel Template (bonus)

To make things more streamlined, I have coded this into an excel template with other factors also in consideration like number of public holidays, leave plans in the sprint etc. We also keep 25% of total sprint capacity for technical improvements of the systems we build as a standard practice.

Please find the excel template here.

Sprint Capacity Calculation for Scrum Teams was originally published in Noteworthy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Related Articles

28 Lesson Plan Templates for Teachers & Online Instructors

Looking for the best lesson plan templates for all kinds of subjects and grade levels?
In this post, we’ve gathered 28 beautiful lesson plan templates that are professional, easy to customize and print-friendly.
Browse through the options below to organize …
The post 28 Lesson Plan Templates for Teachers & Online Instructors first appeared on Visual Learning Center by Visme.


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

Receive the latest news

Subscribe To Our Weekly Newsletter

Get notified about chronicles from TreatMyBrand (TMB.) directly in your inbox