Agile capacity calculation — Part 2 of 2

In the first part of this two-part blog, I presented two methods for agile capacity calculation:

• Method 1: Capacity is not required to be estimated or calculated. This is an idealized and the simplest method.
• Method 2: Capacity is only roughly estimated (in number of hours) using a small number of parameters.

In this second part of the two-part blog post, I present the third and last method for agile capacity calculation:

• Method 3: Capacity is precisely calculated (in number of hours) using a fairly comprehensive, extensible, and customizable set of parameters.

The capacity to do actual hands-on work for each team member is calculated considering a number of parameters, such as:

• Number of weeks and workdays available in a sprint: For example, for a four-week sprint, there are 20 workdays (assuming five workdays per week and no days lost due to company holidays). If a sprint starts later than Monday of week one and ends earlier than Friday of week four, there will be less than 20 workdays for the sprint. As an example, if the sprint starts on Tuesday of week one (perhaps Monday was a heavy snow storm day and the company was closed), and ends on Thursday of week four (perhaps Friday was set aside for sprint review and retrospective), the sprint will effectively have only 18 workdays.
• Number of company holidays scheduled during the sprint timebox: If company has two holidays during the sprint timebox, the number of workdays in that sprint will reduce by two, which will also reduce the individual and team capacity.
• Personal vacation or paid time off for each team member: For example, if a team member is planning to take three vacation days in the upcoming sprint timebox, his capacity will reduce by three workdays (and the team capacity will reduce, too, by that amount).
• Full-time vs. part-time membership on the team: If a team member is not a full-time member of the team, but is planning to work only 50% of the time on the project, his capacity will reduce by 50%.
• Time needed to prepare for and attend daily scrum meetings.
• Time needed to do general email and phone calls, and attend company or non-project meetings.
• Time set aside for contingency.
• Any factors that will reduce the capacity of a team member, such as:
  • Support work for the previous release of software
  • Preparing the backlog for the next sprint while the current sprint is going on (so-called two-level scrum pipeline)
  • Training new member of a team
  • Self-training to increase cross-functional skills

Although this is a seemingly comprehensive list of factors to consider in calculating the capacity, it is not an exhaustive list. It may need addition, deletion, revision, and customization to suit the needs of your organization. It may seem that Method 3 requires too much computational effort. This computation, however, is done by an Excel-based template, giving you an almost instant capacity number.

If your team is a well-jelled agile team with demonstrated stable velocity, and all assumptions required by Method 1 are in place, you should use Method 1 as described in Part 1 of this blog. A well-jelled team with stable velocity is a very desirable goal. If you can indeed use Method 1, you really do not need to calculate the capacity. However, if Method 1 cannot be applied, you will need to use either Method 2 or 3.

I strongly recommend using Method 3 over Method 2. Although Method 2 estimates the capacity quickly, it provides you only a rough estimate of capacity if you have historical data available on hands-on work in a typical eight-hour day or 40-hour week.

Method 3 calculates capacity of individual team members and the entire team precisely, very quickly allows you do what-if exercises, and provides complete transparency for capacity calculations to all team members and management. I have seen many teams and their members are surprised to see lower than expected capacity number; however, this method allows them to understand why the capacity number is low, and how it can be increased in a realistic way. This transparency on capacity calculation enables an honest conversation among management and team members on how to balance the capacity and the workload.

Here are two examples of conversations I have observed in agile capacity planning done by the teams I have trained and coached.

• Agile team A calculates its capacity and finds that it is 30% less than the workload (prioritized list of features and defects) that its product owner wants the team to deliver in the next sprint. The team realizes that adding new members to the team is not a viable option to raise the team capacity for the next sprint. The team members discuss (facilitated by the scrum master) how they can increase team capacity by 10% by taking a number of steps (increasing the allocation of time of two part-time team members for the sprint, reducing planned vacation days for two other team members, etc.). Team members and product owner discuss how to reduce the workload by approx. 15% by taking two lowest priority features and one lower priority defect out of the sprint scope, and by reducing the scope of one of the features. The team capacity is now only 5% lower than the planned workload; the team feels comfortable with that situation and decides to proceed with the sprint.
• After the capacity and workload are roughly balanced (brought within 5% of each other), agile team B looks at the individual team member’s capacity and individual workload by using Digital.ai Agility, formerly VersionOne. Sheryl (user interface developer) is found to be overloaded, while Tim (Java developer) has excess capacity. Sheryl and Tim discuss how some of Sheryl’s workload (simple UI development) can be completed by Tim with guidance from Sheryl. They both realize that Tim is not going to be as productive as Sheryl is in UI development work as that is not his primary expertise. In the spirit of a cross-functional agile team, he volunteers to pitch in with guidance from Sheryl. This load balancing helps reduce Sheryl’s work overload to some extent, but she is still overloaded. No other option is feasible. The team discusses with the product owner and they agree to take two UI-intensive features out of the sprint scope, and bring in a non-UI-intensive feature currently in the release backlog into the sprint scope to facilitate proper load balancing between Sheryl and other team members.

In conclusion, use Method 1 if you are a well-jelled agile team and all assumptions required for Method 1 are met; otherwise, use Method 3. Let the capacity planning effort guide the conversation among team members and the product owner to complete the sprint planning process.

Part 1 – Agile Capacity Calculation