Agile capacity calculation — Part 1 of 2

Capacity of an agile team is an important measure that should be used to inform the team how much workload it should undertake during its sprint planning meeting for an upcoming sprint. If the capacity and workload are not in balance, then the team members should have an informed conversation with the product owner on how to achieve the balance.

I will present three methods for capacity calculation:

• Method 1: Capacity is not required to be estimated or calculated. This is an idealized and simple method.
• Method 2: Capacity is estimated (in number of hours) using a small number of parameters. This is an approximate but quick method for estimating the capacity of an agile team for a sprint.
• Method 3: Capacity is precisely calculated (in number of hours) using a fairly comprehensive, extensible, and customizable set of parameters. This is an accurate method for calculating the capacity of an agile team for sprint.  The actual calculations are done very quickly using an Excel template.

I present Methods 1 and 2 in this first part of a two-part blog series. I will present Method 3 in Part 2. At the end of the Part 2, I will offer recommendations about which method you may select for your use, based on your agile team’s specific situation.

Method 1: Capacity is not required to be estimated or calculated.

Let us consider the simplest (and somewhat idealized) method of a well-jelled agile team; i.e., a team whose members have worked together as an agile team for several sprints in the past and have achieved stable velocity. For example, an agile team has worked during the last four sprints and has demonstrated measured velocity in a narrow range (within plus-minus 10%) such as 19, 21, 20, 19 story points. In this example, the average velocity of the team (averaged over the past four sprints) = (19+21+20+19)/4 = 19.75 = approx. 20.

If the same team (exactly the same members) are planning to work as a team in the next sprint, and the number of work days available in the next sprint is the same as that in the last few sprints, and no team member is expected to be pulled off the project for any significant effort, then the agile team in this kind of ideal scenario can comfortably plan 20 story points worth of work in the upcoming sprint.

In this method, the actual capacity of the team for the upcoming sprint need not be estimated or calculated due to several idealized assumptions are assumed to be met, such as:

• A well-jelled agile team has achieved stable velocity; and the average velocity measured over the past four sprints is a leading indicator of the estimated velocity for the upcoming sprint.
• The same well-jelled team will work in the next sprint; i.e., exactly same members will continue.
• The number of work days available in the next sprint is very close to the number of work days in the past few sprints; i.e., the next sprint will not have an unusual number of company holidays, no team member is expected to take long personal vacation, and no team member is expected to lose capacity due to other assignments outside the sprint work.
• The technology platform will stay the same for the next sprint (no change from the previous sprint).
• No new domain knowledge by any team member is required for the next sprint.

Method 2: Capacity is estimated in number of hours using a small number of parameters.

This method is applicable when one or more assumptions justifying Method 1 is not true or is at least questionable. If one or more of the following conditions are applicable, Method 1 should not be used:

• The agile team is not a well-jelled team yet; it has experienced erratically changing velocity sprint by sprint in the past.
• The agile team composition is likely to change for the next sprint from the previous sprint; this will certainly change the team dynamics and team productivity.
• Capacity of the team for the upcoming sprint is expected to be different from the previous sprint due to upcoming holiday season, summer or winter vacations, etc.
• Team members are expected to work on a different technology platform during the next sprint.
• One or more team members need to learn and apply new domain knowledge for the next sprint.

In this kind of scenario, we cannot take the average past velocity as the leading indicator of the estimated velocity for the upcoming sprint. We need to estimate the number of hours available for the team to do actual hands-on work during the upcoming sprint. In this method, a simplified model is used by considering historical data in the organization for typical “hands-on time” in a given eight-hour day (if this data exists and is available). Based on historical data, the team may use 60% to 80% of the eight-hour day as the time available to do actual hands-on work. The remaining time (40% to 20%) is taken away for general email and phone calls, company meetings, preparing for and attending daily scrum meetings, etc. So each full-time team member is estimated to have 4.8 hour to 6.4 hour per day (or 24 to 32 hours in a 40-hour work week) to do hands-on work. As an example, if an agile team has eight full-time members and uses four-week sprints, it will estimate its capacity to be 8 x 4 x 24 = 768 hour (assuming 60% hands-on work), or as much as 8 x 4 x 32 = 1,024 hours (assuming 80% hands-on work) for the upcoming week.

Note that this is only a rough estimate of the capacity of an agile team, as it is based on a single parameter (% of time available to do hands-on work, typically 60% to 80%, based on organization’s historical data). If historical data is not available, some organizations use a guesstimate number (say 75%) based on anecdotal evidence, or its sense of comfort level with this number.

The estimated capacity number is used to provide guidance to the agile team in terms of how much work (stories or features to be implemented, and defects to be fixed) can be planned for the upcoming sprint. For example, if the team capacity is estimated to be 800 hours, its estimated work should be close to 800 hours; the team may exceed its capacity, but by no more than 5%; i.e., in this example, estimated work should not exceed 840 hours.

An agile team now needs to estimate or calculate the number of hours of planned work based on its prioritized sprint backlog.   The effort for each story and defect needs to be estimated in number of ideal hours (not elapsed hours). This can be done at the story or defect level by the team based on its collective knowledge of the work involved. Alternatively, each story and defect can be broken down into tasks and tests; each task and test is estimated in number of ideal hours, and those estimates are rolled up to get an estimate of the effort for story or defect in ideal hours.

As Method 2 provides only an estimate of the capacity based on a single or small number of parameters, it is only an approximate measure. If you need to precisely estimate the team capacity in number of hours based on a comprehensive set of parameters, you will need to follow Method 3. This method will be presented in the second-part of this two-part blog post.