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, i.e.,

  • Method 3: Capacity is precisely calculated (in number of hours) using a fairly comprehensive, and 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 4-week sprint, there are 20 workdays (assuming 5 workdays per week and no days lost due to company holidays).   If a sprint starts later than Monday of Week 1 and ends earlier than Friday of Week 4, there will be less than 20 workdays for the sprint.  As an example, if the sprint starts on Tuesday of Week 1 (perhaps Monday was a heavy snow storm day and the company was closed), and ends on Thursday of Week 4 (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 time-box: If company has 2 holidays during the sprint time-box, the number of workdays in that sprint will reduce by 2, 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 3 vacation days in the upcoming sprint time-box, his capacity will reduce by 3 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 e-mail 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.

I have developed this Capacity_Calculator template to allow you (ScrumMaster or Project Manager for an agile team) to do the capacity calculation for each team member and the entire team very quickly.  You may customize this template to suit your organizational needs.  Its Instructions worksheet summarizes how to use the template for your needs.

  • In the Capacity worksheet of the Capacity_Calculator template, replace example persons with your team’s members.
  • Add columns needed for additional members of your team, along with formulas copied from other columns.
  • You may also consider any Guest Members on your agile team, who are responsible for very specific tasks for a limited duration.
  • During the Sprint Planning session, ScrumMaster enters data in Pink cells of the Capacity Worksheet for team members.
  • The Capacity worksheet will calculate the Capacity of each individual and the Team Capacity at the start of a sprint.
  • ScrumMaster may insert comments in Pink cells where he has entered data for his team.
  • Enter the individual capacities at appropriate place in VersionOne tool.
  • Once capacities for all team members are calculated using this template and the Sprint starts, the Capacity worksheet should NOT be changed.

As the Capacity_Calculator template is based on Microsoft Excel, it can be used to do what-if exercises to see the impact on capacity by changing various parameters, such as the % availability of each member, planned vacation days, and by changing factors that reduce or change the capacity of each individual, etc.  The template has evolved over the last three years with feedback from its use by over 50 agile teams, with many refinements based on that feedback.

The calculated capacity number is used to provide guidance to the agile team in terms of how much work (stories or features, and defects) it should plan to undertake for the upcoming sprint.   This was explained in Part 1 of this two-part blog series.    Please refer to Part 1 of this blog for details.

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.

As Method 3 comes with a Capacity_Calculator template, 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 8-hour day or 40-hour week.

Method 3 calculates capacity of individual team members and the entire team precisely and very quickly (using the Capacity_Calculator template), 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 coming from the Capacity_Calculator template; however, the template allows them to understand why the capacity number is low (and its specific value), 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, which is even a bigger benefit of the Capacity_Calculator template.

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 ScrumMaster) 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 VersionOne tool.  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 with its downloadable Capacity_Calculator template.  Let the capacity planning effort guide the conversation among team members and the product owner to complete the sprint planning process.

If you would like to receive a single file version (as a PDF document) of this 2-part blog series, please send me an email at Satish.Thatte@VersionOne.com requesting the document.

Part 1 – Agile Capacity Calculation

 

This entry was posted in Agile Development, Agile Management, Agile Project Management, Scrum Development, Scrum Methodology. Bookmark the permalink.

2 Responses to Agile Capacity Calculation – Part 2 of 2

  1. GDMS says:

    Can we decrease Sprint days based on Holidays?

    For example: Two weeks sprint (10 days), if 2days holiday fall in these two weeks sprint, can we reduce the days from 10 to 8 days? why we cannot increase the sprint day to 10 uniformly.
    What are all the impacts when we increase sprint days based on holidays?

    • Satish Thatte says:

      Hi GDMS,
      I recommend and prefer a constant sprint duration (calendar days) from sprint to sprint for a team, instead of varying sprint duration in response to company holidays, availability of team members, or any other reason. Constant sprint duration (2 weeks or 10 work days, as an example) creates a pattern or rhythm, which is known as cadence in the agile community. Sprint cadence reduces coordination and transaction costs, and supports predictability. For example, Sprint planning will be always on the 1st workday of the 2-week sprint timebox, and Sprint Review and Retrospective on the last workday of the 2-week sprint timebox. These ceremonies can be scheduled 6 months to 12 months in advances for all sprints and published on all team members’ and stakeholders’ calendars, simplifying scheduling and communication. When multiple teams need to work together in a synchronized mode (such as Scrum of Scrum, or SAFe), a constant cadence for all teams help inter-team alignment and synchronization.

      If you start adjusting sprint duration sprint by sprint (for whatever reason), this cadence will no longer be possible. Some sprints will be 7 while other sprints may be 9 or 11 days long, and there will be no discernible pattern or rhythm. When there are company holidays in a sprint, it will reduce the capacity of the team, which can be easily calculated using the Agile_Capacity_Calculator provided with this blog. Reduced capacity will mean less work should be planned for the sprint; but don’t change the sprint duration sprint by sprint as explained above. I hope this helps.

      Regards,

      Satish Thatte
      Agile/Lean Coach and Product Consultant
      VersionOne

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>