Capacity Planning in an Agile Scrum Environment

Estimation is an important aspect of Scrum. Every Scrum Team estimates the amount of work they can take up in their upcoming sprint in their Sprint planning meetings. To do that, they estimate each user story in story points and then sum up the story points. In most cases, they target to take up the number of story points equal to (or close to) the average velocity of their last three sprints or in some cases, the average velocity of all the sprints the team has worked in. But there is an underlying problem when we target to deliver story points equaling to story points delivered in the last sprints.

• If there is a holiday in the upcoming sprint, our capacity for the sprint decreases, in that case, it is obvious that we can't deliver the same number of story points as we did in the last sprints.
• If during sprint planning, we find that few of the team members are going for planned leaves, it is obvious that in the upcoming sprint, we can't deliver as per our average velocity.
• Team meetings, organization meetings, and other organization-level engagements eat away developer's time and hence they get less hours for coding than stipulated eight hours.
• If the team is new, then there is no average velocity. In that case team can't judge how much they can achieve in the upcoming sprint.

Scrum Teams do factor in the above factors and most often they take lesser story points for their upcoming sprint, but do they calculate how much of lesser story points they should take if there is a single day holiday vs how much less they should take for say a three-day holidays during the sprint? Also, how much less should the team take if one person will be on leave for three days vs two persons each for three days? To deal with those problems, some Agile Teams measure the capacity of the team for each sprint before committing to the number of story points by doing Capacity Planning.

What exactly is Capacity planning?

Capacity planning is a process by which the Scrum Team calculates the total number of hours the entire team will get for development work in the upcoming sprint. We can assume the capacity of an individual team member as a glass in which different activities take up spaces (as shown in the figure). Hence, Scrum events, organization activities, holiday that falls within the sprint, team members’ availability in this project, planned leaves of the team member, focus factor and lastly development time, all fill the glass till the glass is full. Hence, if we consider that the maximum hours that a team member gets in a two-week sprint is 80 hours (8 hours x 10 days), subtracting each of the above-said activity hours from it will give the exact number of hours an individual will get for development in that sprint.

Adding up the capacity of each team member will give the total capacity of the team.

Now, the question is – How can we map the capacity of the team in hours to the velocity the team can achieve in story points?

Scaled Agile Framework (SAFe) has given a very good and simple guideline to establish the capacity of the team if no historical data exists:

• For every full-time developer and tester on the team, give the team eight points (adjust for part-timers)
• Subtract one point for every team member vacation day and holiday.
• Find a small Story that would take about a half-day to develop and a half-day to test and validate and call it a one.
• Estimate every other Story relative to that one.

Example: Assuming a seven-person team composed of three developers, two testers, one Product Owner, and one Scrum Master, with no vacation, and a two-week iteration.

Estimated capacity = 5 x 8 points = 40 points/Iteration.

Now, how can we find the capacity in story points if we have a historical velocity of a team but in upcoming sprint we find there are organization holidays and employee planned leaves?

First, calculate the total time the team will spend in ceremonies in that sprint:.

Next, calculate holidays, team members’ absence and engagement in other projects, focus factors, etc. Subtract those time from the working hours to get the productive hours for each person for the sprint.

Take the average velocity of the team from previous sprints. Find the capacity your team had for those historical sprints. Divide velocity in story-points of each sprint by its corresponding capacity in hours. You will get a measure of your team’s velocity per hour. You can take an average of your team's velocity per hour for all historical sprints to get your team's average velocity per hour. Now deduce the number of story-points you can take for that sprint by multiplying the capacity of the team in hours with the average velocity per hour.

Hence, by using the above method, you can easily measure the capacity of the team in the upcoming sprint and take the appropriate number of story points, considering all factors that can affect your sprint's velocity.