Calculating Team Capacity: A Step-by-Step Guide

Explore these proven methods to know how much work your teams can do

One of they key practices that has helped me and my teams to plan better has been the ability to calculate my teams’ capacity.

At the end, our main goal is to answer this question: “How much work can my team complete in a specific amount of time?”

But in order to get an accurate estimation there are some pre-requisites you need to have in place.

Pre-requisites to Ensure a Good Predictability

1. Have a defined and consistent hierarchy of work items

I have seen teams creating very large stories that take several days or even weeks to be completed.

Or sometimes a team does not have a common agreement of the size of their work items and what is a reasonable timeframe to close each of them.

In order to be consistent, it is important to discuss with your team and create a hierarchy of work.

I typically recommend the following hierarchy and timeframes:

Program Initiative. Timeframe: From a quarter to several quarters, even a year.

Program Feature. Timeframe: From one month to several months.

Epic. Timeframe: From one week to several weeks.

Story, Technical Tasks, Bugs, Spikes, Production Defect. Timeframe: from one to four days.

Sub-tasks. Timeframe: from two to three hours.

They may vary from one team to another but what is important for your teams is to have a common agreement and to be consistent.

But having a hierarchy defined is not enough.

2. Your process needs to be in control

Let’s use some concepts of the statistical process control or most known as SPC:

“A process is in control when it exhibits predictable and stable behavior.”

In order to do this, we need to make sure that there are no special causes or patterns that are assignable to events or factors that cause significant shifts in our outcomes.

Here is a list of my recommendations to prevent significant shifts:

1. A proper work intake process is in place.

For example, your team is not interrupted every minute to take new work and even if there is urgent work to do, there is a process in place to manage those exceptions.

You need to have a defined cadence for your team to take new work such as the Sprint Planning ceremony in Scrum or Replenishment sessions in Kanban.

2. A correct software development workflow is in place.

The steps in your project management tool (e.g. Jira) match what the team does in reality.

3. Have a good definition of ready and done or exit criteria for each of the steps of your workflow.

The team follows each of the steps in your workflow in a consistency manner.

4. To ensure efficient workflows, your team prioritizes workloads they can confidently manage.

   1. In Scrum, this translates to forecasting realistic work they can likely deliver within a Sprint.

   2. To avoid multitasking and maintain focus, consider implementing Work In Progress (WIP) limits, a key Kanban practice.

5. You have an effective workflow management.

   1. Visualize your workflow by using a Kanban or Scrum board with columns representing workflow stages.

   2. Track the time it takes to complete a task from start to finish. Identify and address bottlenecks that increase lead time.

   3. Measure the time between completing consecutive tasks. Analyze cycle time to improve efficiency and reduce waiting times.

To learn more about identifying and managing workflow constraints, watch this video on the Theory of Constraints:

6. A cross-functional team equipped with the right skills

• Analyze which skills are required on your team so they can tackle diverse tasks and overcome challenges.

• A team lacking the proper skills will encounter frequent roadblocks and delays.

If you are using Jira, you can use the control chart report in order to understand if your process is in control.

3. Your work items are created in small and in similar batch sizes

Work items that are consistent in size and as small as possible will help you to:

• Improve the flow of work: as they increase the transparency and it is easier to identify and address bottlenecks.

• Increase the quality: it is easier to catch and fix errors early on.

• Allow for continuous feedback and adaptation: Break down work into smaller, manageable chunks and deliver them in iterations.

• Help reduce variability in the work process: When work is done in large batches, it is more likely that there will be unexpected delays or problems.

Your teams should have an estimation process and a scale in place to control this. If you are interested to learn more about the work estimation, read this article I posted before:

So How Do I Calculate My Team’s Capacity?

Step 1: Track your team member’s availability

It is crucial that you track the availability of your team members. You may want to use a spreadsheet to track your team’s availability that could be in days or hours.

By tracking your team member’s availability:

• You set realistic expectations.

• You avoid overcommitment.

• Your team can strategize and make better decisions to know how to tackle the work to come.

Be careful of this anti-pattern! Tracking the availability is not aimed to micro manage the team members but to estimate how much work they can handle on a certain period of time and help the team organize better when somebody is not available.

There are some considerations when you are calculating your team’s availability in hours:

Focus factor: is the percentage of time that team members can focus on development work during a given period, taking into account interruptions and other factors that may affect their productivity. I typically use between 80% to 90%.

Ceremony time: the time spent on ceremonies and meetings should be deducted from the total available hours.

Therefore, the Total Availability in hours formula for one team member is:

Total Availability (in hours) = [(Working hours)*(No. of days available in a Sprint already excluding the PTOs) - (Ceremony time in a Sprint)]*Focus Factor

Example: ([8 hrs * 10 days] - 7.5 hrs)*90% = 65.25 Hours

Another simple way to calculate the Availability is using Team member’s available within a Time Box:

Effective team members available during a Time Box = (Total # of effective days your team members are available within a Time Box) / (Time Box Length in Days) = Team Members available per Time Box

For example:

• If your Sprint length is 10 business days

• Your team size is 7 team members

• All the team will take one day off due to a holiday

• And one team member will be out the entire Sprint

Team’s availability in days = 6 team members * 9 business days = 54 effective days

Effective team members available during the Sprint = 58 effective days / 10 Days per Sprint = 5.8 Team Members Available per Sprint.

Here you can find some examples on how I track the availability of my teams:

Example of an Availability sheet by Week

Example of a Scrum availability sheet considering focus factor and deducting ceremony time.

Step 2: Understanding the difference between Throughput, Velocity and Load

The throughput refers to the amount of work that is completed or delivered within a given period of time it could be a week, a sprint, a month or a quarter.

It is a measure of the team’s outcomes and it is typically expressed in terms of completed tasks, features or user stories.

Example: Last week we completed and released 12 stories. And in total 60 tasks were completed last month.

On the other side the velocity refers to the amount of work that the team can deliver within a specific time frame, based on their historical performance. It is a statistic.

It is usually expressed in terms of story points or tasks completed per week or Sprint and it is calculated using a rolling average typically three to four Sprints or weeks.

For example, considering the team's velocity is 14 tasks per Sprint.

If a team has 100 tasks similar in size in scope for the quarter (6 Sprints), then that specific scope will take approximately 7 Sprints to complete (100/14 = 7.14). Therefore, the scope needs to be reduced.

An example of a Load, Velocity, Throughput vs Estimated Capacity chart

Finally the load is the amount of work we add to each time box (e.g. a Sprint or a week).

For example, historically my the team is able to complete 14 tasks per Sprint as it is their current velocity.

But the team is loaded with 20 tasks during this Sprint, this means that my team overcommitted and most likely they won’t be able to complete all the work and there will be carry over work for the next Sprint.

Step 3: Calculating my team’s capacity

Photo by Goh Rhy Yan on Unsplash

Some warnings before I explain these calculations:

• This process is absolutely NOT to be used to compare teams. As each team has their own context.

• This is not to track individual’s productivity. This metric is to be used on a well functioning and cross functional team.

• Do NOT use this as a direct measure of productivity. There are many factors that can affect these calculations as it only gives you a hint that something may be wrong or needs to be adjusted. We need to explore the reasons that impacted it.

When to use these calculations:

• This is going to be used to help us estimate my team’s ability to complete work (number of tasks or story points) during the future weeks, iterations or quarters.

When using these calculations you should consider that this does not account for big changes on your team’s composition or external factors that may impact your team’s historical performance.

So, if this happens, you would need to wait to collect some more historical data and make adjustments to your future estimations.

• I typically use these ratios to remove the team’s availability factor and focus only on the factors that impacted the team’s productivity over time. Meaning how my team has improved or slowed down over time to take actions to put it back on track.

Some examples are:

• Changes on the team composition or skills

• Team Morale

• Unresolved blockers

• Bad requirements definition

• Work incorrectly broken into smaller pieces

• Unexpected high complexity work

Software Development Team discussing in front of a board. Generated with Bard AI

Method Using Tasks per Member per Time Box Ratio

Throughput Ratio = Throughput [Points or Tasks during a specific Time Box] / [No. of Members available]

Let’s run a hypothetical example:

Sprint 1:

Team’s throughput = 12 tasks completed on Sprint 1.

Team’s composition: 7 team members.

Sprint Length: 10 business days.

Availability: The maximum team’s availability is 10 business days * 7 team members = 70 effective days.

Meaning 7 team members are available during the whole Sprint.

Therefore, my Sprint 1 throughput ratio is calculated in the following way:

• Throughput Ratio (using Days) = (12 Tasks/Iteration) / (7 Members available) = 1.714 Tasks per member per Sprint

---

Sprint 2:

Team’s throughput = 11 tasks completed on Sprint 2.

Team’s composition: 7 team members. But with two team members taking time off one day each.

Sprint Length: 10 business days

Availability:

Team’s availability in days = (5 team members * 10 business days) + (2 team members * 9 business days) = 68 effective days

Effective team members available during the Sprint = 68 effective days / 10 Days Sprint length = 6.8 Team Members available per Sprint

• Throughput Ratio (using Days) = (11 Tasks/Iteration) / (6.8 Members) = 1.618 Tasks per member per Sprint

---

Sprint 3:

Team’s throughput = 10 tasks per Sprint

Team’s composition: 7 team members. 1 members will be out during the entire Sprint and 2 members will be out one day.

Sprint Length: 10 business days

Availability:

Team’s availability in days = (4 team members * 10 business days) + (2 team members * 9 business days) = 58 effective days

Effective team members available during the Sprint = 58 effective days / 10 Days per Sprint = 5.8 Team Members available per Sprint

• Throughput Ratio (using Days) = (10 Tasks/Iteration) / (5.8 Members) = 1.724 Tasks per member per Sprint

---

So this is how this metric for the last 3 Sprints look like:

Throughput Ratio Sprint 1 = 1.714 Tasks per member per Sprint

Throughput Ratio Sprint 2 = 1.618 Tasks per member per Sprint

Throughput Ratio Sprint 3 = 1.724 Tasks per member per Sprint

You can see that this ratio is varying by decimals and independently of the team members availability, this shows you a better picture of the team’s productivity per Sprint so I recommend you to track this metric and anything pushing this number low or up would be something worth investigating.

A caveat is that the less team members you have, the highest the possibility that the productivity will slow down as there may be a lack of critical skills (e.g. QA team members) during that time within the team to deliver the committed outcome. This is something to take into account when planning a Sprint so do not only use the numbers.

Image that shows sticky notes on a Kanban board and a team discussing in front of the board. AI generated with Bard.

Calculating the team’s velocity (average of the last 3 Sprints):

Velocity Ratio = ( 1.714 + 1.618 + 1.724) / 3 = 1.685 Tasks per member per Sprint

Then, how many tasks would my team be able to complete on Sprint 4?

If you have the following:

Sprint Length: 10 business days.

Team’s composition: 7 team members.

Availability: All members will be out one day during the Sprint as there is a holiday and 1 member will be out the entire Sprint.

Team’s availability in days = 6 team members * 9 business days = 54 effective days

Effective team members available during the Sprint = 54 effective days / 10 Days per Sprint = 5.4 Team Members available per Sprint

Expected Sprint 4 Capacity = Velocity Ratio (Average) * Team Members available

Expected Sprint 4 Throughput = 1.685 (Tasks per Sprint per team member) * 5.4 Team Members Available = 9.1 Tasks (approximately 9 Tasks)

This is the maximum load your team should plan for your iteration 4.

Method Using Tasks per Hour per Time Box Ratio

This approach is using the number of hours available per team members per Sprint, considering the focus factor and deducting the ceremonies time as elements to calculate your availability.

The Throughput Ratio formula will be a little bit different but the logic is the same:

Throughput Ratio = Throughput [Points or Tasks done during a specific Time Box] / [No. of Team Members available in Hours]

Example:

Using the example I gave above where the individual availability considering ceremonies and focus factor was: 65.25 Hours

Assuming all the 7 team members will be available for the entire Sprint then: Total Availability in hours = (7 * 65.25 Hours) = 456.75 Hours

Throughput Ratio Sprint 1 = 12 Tasks / 456.75 Hours = 0.02616 Tasks per Hour

For simplicity let’s say we run the same exercise for Sprint 2 and 3 and we obtained:

Throughput Ratio Sprint 2 = 0.02632 Tasks per Hour

Throughput Ratio Sprint 3 = 0.02593 Tasks per Hour

Velocity Ratio (Average) = (0.02616 + 0.02632 + 0.02593) / 3 = 0.02614 Tasks per Hour

What will be our capacity of our entire team if they will be available during Sprint 4 only 9 days out of 10?

Focus factor = 90%

Ceremony time = 7 hrs - Let’s say one day less mean 30 minutes less of ceremonies.

Availability in hours = ([8 hrs * 9 days] - 7 hrs)*90% * 7 = (58.5 Hours * 7) = 409.5 Hrs

Then our Capacity for Sprint 4 is

Velocity Ratio (Average) * Availability in Hours = (0.02614 Tasks per Hour) * 58.5 Hours = 10.7 Tasks (approximately 11 Tasks)

Final Thoughts

You can automate all of this using a spreadsheet and create your own template. Also you can download this template I created as an example.

Make sure to consider a buffer and do not plan for full capacity as there are always unexpected unplanned work such as bug fixes or expedited requests.

For example: If your team’s capacity is 12 tickets during the next Sprint, plan just for 2 or 3 tickets for unexpected work. You may need to measure how many injects you receive each Sprint to determine this number.

Any metrics are there to give us a sense of how things are going with our teams. Make sure you study these numbers, interpret them and apply your common sense before any remediation actions.

I hope this post was helpful to you.

Give me your comments, share or like this article to continue supporting this blog.

Thank you for reading!

Hope you enjoyed this article! Let me know what you think in the comments. If you're feeling generous, you can buy me a coffee to fuel my writing!

---