Sprint capacity planning is one of the most often used complementary practices by Scrum Teams. This article provides all the basic information and practical examples to plan your next Sprint, if you are
- Scrum Master, Product Owners or Developers in the Scrum Team
- Delivery Manager,
- Agile Team Leader or Project Manager
This article will explain team capacity and team capacity planning. I will then explore seven key variables for capacity planning. Additionally, I will present two examples to assist you with your next capacity planning, before finally explaining what common sense entails to capacity planning.
What is Team Capacity and Team Capacity Planning
Team capacity planning determines the amount of work the team can effectively complete within the next iteration. The outcome of capacity planning should be used as an input for interaction planning. For teams using the Scrum framework, iteration is a Sprint, and iteration planning activities will be conducted during the Sprint Planning event.
Team capacity refers to the amount of work a team can accomplish during an Iteration, considering team member availability and productivity. Team capacity for iterations typically is provided in units of effort (i.e., hours, days, ideal hours, story points) that the team can dedicate to tasks related to product development (like software design, coding and implementation, testing, quality assurance, deployment, etc.) in the next iteration.
Team capacity planning should be held just before or during planning the next iteration because this is the last reasonable moment to make it and provide the most current understanding about team capacity. Typically, the process is not very complicated and can be done by a team almost on the spot without huge effort. In the following paragraph, we will explore a list of factors that should be considered regarding capacity planning.
Key variables for capacity planning
The capacity of the Scrum team in the next sprint that is building the product is shaped by several dynamic variables. They should be considered when determining how much work can be completed in the next iteration. These factors are essential because they help to align commitments (i.e., Sprint goal) and forecasts on what can be accomplished (i.e., a set of Product Backlog Items), as well as the initial plan regarding how the team chooses the work to be done (planning the work necessary to create an Increment). The chosen work is intended to be achieved with consideration of realistic team capabilities. Below are the key variables
- Team Size: The number of team members, such as developers, testers, or UX designers, directly affects the total available hours (Rubin, 2012)
- Level of focus: The level of dedication of individual members, whether full-time or part-time and split across projects or products.
- Individual availability: Various events, such as holidays, planned training, and sick leave, can reduce individual capacity and impact the Scrum team’s total capacity.
- Length of iteration: The duration of an iteration (the duration of a Sprint) will affect team capacity. As a crucial factor, iteration length can vary throughout product development (this may be associated with certain penalties and/or benefits).
- Unit of Effort: Different Scrum teams may utilise various effort or complexity units; therefore, capacity should be articulated in the units the team employs to define task-related effort.
- External Distractors: Various events, such as Bank holidays, Christmas break, regulatory reviews, company events, and others, can consume significant time and limit capacity and are known before the begining of the Sprint.
- Change in team composition: Introducing a new team member typically requires other team members’ effort. This effort can be treated as a separate task added to the Sprint Backlog for the next iteration, or it can reduce the team’s total capacity. On top of that, some of the team use practice to reduce the capacity of newcomers by some percentage because they will not be as effective as “old team members” (for the record, I am not a massive fan of this practice)
Practical Example – calculation of capacity
To illustrate, team capacity planning can be performed using the seven key variables mentioned above. Below, you can find two different examples. Let us consider that the Scrum Team is developing a digital product; each example will have different variabilities.
Example 1
Team Size – 5 developers
Full-Time vs. Part-Time Members – 4 full-time members and one person engaged in 50% engagement.
Length of iteration: 2 weeks
Individual Availability: All people will be fully available in declared capacity
Units of Effort: Hours
External Factors: 1 Day of a bank holiday during the Sprint
New team member introduction: N/A
How to calculate it:
Forecasted Capacity » (4×8) + (1×4) x 10 – 1 x ( (4×8) + (1×4) = 324 hours
Example 2
Team Size – 7 developers
Full-Time vs. Part-Time Members – 5 full-time and 2 part-time team members engaged in 50% engagement.
Length of iteration: 1 week
Individual Availability: 1 full-time member will be on holiday
Units of Effort: Story Point
External Factors: N/A
New team member introduction: N/A
Velocity: 24 story points (fully available in one week’s Sprint)
How to calculate it:
((5×8) + (2×4) )x 5– (( 1×8)x5) = 240 – 40 = 200
Velocity / Total Time
24 / ((5×8) + (2×4)) x 5 = 24/ 240 = 0,1
Forecasted capacity » 200 x 0,1 = 20 story points
Common sense for capacity calculation
This article lists variabilities and examples of calculations that should be used with good intent. Good intent, in terms of using team capacity as a valuable tool to support planning for the next iteration, has a few aspects:
The entire Scrum Team is accountable for creating a valuable Increment every Sprint. Any calculation should not become an excuse for the team’s failure.
Developers create a plan for the Sprint, the Sprint Backlog. Capacity planning is often associated with capacity utilisation. Some people, especially those who tend to micromanage others, treat other people as resources. A big group of these micromanagers are typically on a mission to ensure the resource is fully utilised. A Scrum team is not intent on fully utilising team members’ capacity. Good teams understand that Scrum is about maximising value from complex problem solving. In that context, capacity planning can increase the predictability of delivery and help plan more effectively and in a more informed way. Capacity is one of the factors (e.g., past team performance, Definition of Done, current state of increment, sprint retrospective improvements, Product Backlog, Product Goal, and others) that the Scrum team uses during Sprint Planning.
Capacity planning is a complementary practice for the Scrum Team. It can be helpful for some of the team, but others might decide not to use it. You can freely check if it is helping your team, inspect it, and adapt if needed.
If you need help with your Scrum and Kanban implementation or support in your digital, business, operation or Agile transformation, visit pawelrola.com or contact me on LinkedIn.
Let’s work together to bring the organisations of the future!
Share this content:
Bibliography
Rubin, K. S. (2012). Essential Scrum: A Practical Guide to the Most Popular Agile Process. London: Addison-Wesley Signature Series (Cohn)