Capacity Planning - When? How? Tools?

Hamid Zarei
3 min readSep 19, 2020

--

Last week I was asked a question “Do you use capacity planning? When? How? Tools” So, I decided to share my experience and opinion with you this week.

Scrum teams often come up against this obstacle of sprint commitments during sprint planning. One of the most known challenges about sprint commitments is Team capability. Team capability can vary from sprint to sprint, depending on holidays, leaves, or any other personal or organisational commitments. Therefore, capacity planning is important in sprint planning.

Capacity planning means estimating and evaluating the Scrum team capacity for the upcoming sprint. Capacity planning has a great impact on the sprint backlog. A Sprint Backlog is nothing more than a list of the product backlog items that the team is dedicated to delivering, plus a list of tasks necessary to deliver certain product backlog items. Generally, there are two ways to Capacity planning: Story Points (velocity-based) and Hours (capacity- based).

1. Story Points (velocity-based)

Sprint’s Story Points planning determines how much work the team will do in the Sprint. This is a quick way to calculate the velocity and aiming the upcoming Sprint committing Story Points that closely matches the velocity.

2. Hours (capacity) based

Capacity- based is based on the sprint ability available to the team (in hours). I prefer Hours based on capacity planning, so I will explain only in this way in this article.

In the Hours based capacity planning, the team’s commitment is to do its best. The commitment of the team mustn’t be a guarantee.

When do we need to do capacity planning?

Some say that in a sprint planning meeting, capacity planning occurs and involves the Scrum Team. To me, the best time is right before the Sprint planning for every Sprint, which allows the resource’s holiday schedule or ceremony time the best visibility. Capacity planning allows a team to consider how many storey points they are likely to accomplish in a sprint, taking into account business and personal time off, and commitments that influence the overall time available for effective project work. Initially, with the team, I used to calculate all the factors an hour before Sprint Planning.

How to do capacity planning?

To calculate & plan your capacity, the technique is very simple. A basic equation is at the root of Scrum capacity planning: the number of team members multiplied by the number of days in the sprint multiplied by the number of effective hours in a day mines the total time off for each team member.

Are there any tools available for capacity planning?

Although you can use spreadsheets for calculating the capacity planning, there are some ALM tools available for this too. Agile Application Lifecycle Management (ALM) tools support standard agile practices. ALM covers the entire lifecycle from the idea conception, through to the development, testing, deployment, support and ultimately retirement of systems. They easily integrate with core agile processes.

If you are keen to know more about ALM tools, please see 10 ALM Tools To Deliver Better Projects by Ben Aston.

Sample Capacity Planning

Assuming we have five developer team members. I am not counting the Scrum Master and Product Owner here, as we don’t need to count their capacity in capacity planning. Please note that you only need to count the SM and PO in capacity planning if they are part of the developer team too.

If we assume:

· everyone has 6.5 hours (8hours working time — lunchtime — meetings — teatime, …) effective work hours per day

· the sprint length is two weeks (10 working days)

· some of developer team members asked leaves

· one of developer team member has 80% capacity for the upcoming sprint

Then the total capacity of the team for the next sprint is 287 hours.

Please share your thoughts with me on this.

Take a minute to follow me on Twitter if you enjoyed this post and want to see more.

--

--

Hamid Zarei

I am a results-driven, compassionate Scrum Master and Software Developer who believes in the art of the possible.