Sprint Capacity Calculation for Scrum Teams

I have been a scrum master for my current team for almost a year now. I have tried a 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, we essentially mean that it can be completed by 1 developer if he works 1 full day (i.e 8 hours) without any interruption. In the real world, no developer works uninterruptedly.

Ideal Scenario

Let's 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 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 for these into the estimates, we used the idea of focus factor. The 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 the 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 for in the capacity planning. Also, all stakeholders know 1 SP means the deliverables can be expected in 1.5 working days approximately.

Revising Focus Factor Periodically

The good part about the 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 that we got a dedicated team member to test our code changes. The same applies when developers are leaving the team.

As the team matures over time, developers get more productive and this means 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 the number of public holidays, leave plans in the sprint, etc. We also keep 25% of the total sprint capacity for technical improvements of the systems we build as a standard practice.

Please find the excel template here.

Check out my other stories:

Backend Technical Interviews: An Interviewer’s Perspective

Amazon SDE Interview Experience (On Campus)