# Capacity Planning in Agile Teams: Commitments Based on Data

Author: Marin Niehues, Niehues Consulting · Published: 2024-04-11 · Delivery & Steering
Source: https://www.niehuesconsulting.de/en/blog/capacity-planning-agile-teams/

Capacity planning in agile teams works when you calculate the time actually available and derive commitments from the throughput measured over recent weeks. Estimating individual tasks remains useful as a basis for discussion, but the commitment to executives and customers rests on data: how many items did the team actually finish in past cycles, and how likely is it that this result repeats?

This article sets out a calculation from net capacity to a commitment with a probability, compares the common methods and lists review questions for leaders who depend on dates.

**A reliable commitment states a range and a probability, for instance "five sprints with 85 per cent confidence". A single date without a probability hides how uncertain it is.**

## Why do commitments in agile teams fail so often?

Commitments in agile teams fail because they are built from estimates that are systematically too optimistic and from a capacity that exists only on paper. Psychology has a name for the first problem: the planning fallacy, described by Daniel Kahneman and Amos Tversky in 1979 and tested experimentally by Roger Buehler and colleagues in 1994, is the tendency to underestimate the duration of one's own projects even when similar projects took longer in the past. A team that estimates every task one by one in a planning session repeats the error task by task.

The arithmetic of working time adds a second problem. A full-time employee is not full-time capacity for the product. Holidays, sickness, support for legacy systems, coordination with other teams and the team's own events consume time. In "Quality Software Management" (1992), Gerald Weinberg described a rule of thumb for context switching: whoever works on several projects at once loses a noticeable share of time to the switch with every additional project. The exact percentages are a rule of thumb without a measured basis, but the direction matches many observations from practice. Frederick Brooks had shown in "The Mythical Man-Month" in 1975 that adding people to a running project creates coordination effort, so the result does not speed up in proportion to headcount.

Two consequences follow for this article's approach. Capacity follows from measured deductions, and the commitment comes from observed performance. How throughput and cycle time are measured is covered in the article on [flow metrics](/en/blog/flow-metrics-throughput-wip-wait-time/).

## How do you calculate the capacity of an agile team?

A team's net capacity is the number of working days in the cycle minus absences, operational duties and a buffer for unplanned work. The 2020 Scrum Guide sets the sprint at one month or less and expects the team to select from the Product Backlog what it believes it can complete within the sprint. The team checks that judgement with a simple calculation.

**Worked example: net capacity of a team of six**
Step | Calculation | Result
Gross capacity | 6 people times 10 working days | 60 person-days
Absences | Holidays and leave, example value | minus 4 person-days
Operations and support | Share for legacy systems, example value 10 per cent of gross capacity | minus 6 person-days
Net capacity | 60 minus 4 minus 6 | 50 person-days
Buffer for unplanned work | 20 per cent of net capacity, example value | minus 10 person-days
Plannable capacity | 50 minus 10 | 40 person-days

The values in the example are illustrative. In practice the team reads the deductions from recent cycles: how many days actually went into operations and support, and how many tasks arrived unplanned during the cycle? The buffer is the part of the calculation that is missing most often, and it is also the part that keeps commitments intact. It belongs in the plan as a fixed item, so that one bad week does not break the commitment.

## Which is better: story points, velocity or throughput?

Throughput, meaning the number of finished work items per period, is the most robust measure for commitments, because it needs no estimate and can be counted directly. Story points and velocity express the size of tasks in a team-internal unit. They help the team talk about complexity. For commitments to the outside they are of limited use: the unit cannot be compared between teams, it drifts over time, and it invites leaders to judge teams by velocity, which destroys the figure's meaning.

Daniel Vacanti described the alternative in "Actionable Agile Metrics for Predictability" (2015) and, together with John Coleman, in the Kanban Guide (2020): count finished items per period and the cycle time per item. From these two time series, Little's Law shows how work behaves in the system. John Little proved in 1961 that the average number of items in a system equals the arrival rate multiplied by the average time an item spends there. For a team this means that average cycle time equals the number of started items divided by throughput. Reducing the amount of work in progress shortens waiting time without anyone working faster. The approach is described in the article on [limiting work in progress](/en/blog/limit-work-in-progress-deliver-faster/).

**Planning methods compared**
Criterion | Hour estimates per task | Story points with velocity | Throughput with probability
Basis | Opinion of the estimators | Past point totals | Counted finished items
Effort per item | High | Medium | Low
Statement on uncertainty | None | Usually none | Range with probability
Suitability for external commitments | Low | Medium | High
Prerequisite | Detailed task breakdown | Stable team composition | Clean definition of done and ideally ten observations

## How do you turn throughput data into a commitment?

You turn throughput data into a commitment by looking at the distribution of past cycles and choosing a number that was reached in most of them. Take six sprints in which a team finished 11, 9, 13, 8, 12 and 10 items. In five of six sprints at least nine items were finished, and in all six at least eight. The median is 10.5. With 40 items in the backlog, the median means about four sprints. At nine items per sprint the team needs five sprints, and at eight items also five. The message to executives is then: five sprints are realistic with high probability, and four sprints are reached only in an above-average run.

Six observations are a thin basis. With ten to twenty cycles the statement becomes steadier, and for longer undertakings teams simulate the future with the Monte Carlo method. The method draws throughput values at random from the team's own history thousands of times and counts in how many runs the backlog is empty by a given date. The result is a probability distribution from which you can read "85 per cent confidence by this date". A spreadsheet is enough for the calculation. It presumes that items are cut to similar size and that the definition of done stays constant, as shown in the article on [release planning](/en/blog/release-planning-reliable-commitments/).

## Checklist: is your capacity planning reliable?

A team's capacity planning is reliable when every one of the following questions can be answered with yes.

1. Does the team know its net capacity per cycle, with deductions taken from recent cycles rather than assumptions?
2. Is a buffer for unplanned work fixed in the plan, sized from measured interruptions?
3. Does each person work mainly in one team and on one undertaking, so that context switching stays low?
4. Is throughput counted per cycle and kept for at least ten cycles?
5. Do external commitments state a range with a probability?
6. Is the commitment recalculated as soon as team size, backlog or throughput change noticeably?
7. Is the number of simultaneous undertakings in the portfolio limited, so that teams do not serve several line-management orders in parallel?

The seventh question is often underestimated. If three departments have each booked a third of the same team, the capacity has been allocated three times, and no team-level planning technique solves that. It belongs in portfolio governance, as described in the article on [decluttering the project portfolio](/en/blog/declutter-project-portfolio/).

**Typical capacity planning mistakes**
- A position's capacity is equated with the time available for the product, although operations, coordination and absences have to be deducted.
- Velocity is used as a performance measure for teams, and the team starts to optimise points instead of outcomes.
- Commitments are derived from the best sprint of the past instead of the distribution of all sprints.
- Dependencies on other teams do not enter the calculation.:::

## Capacity planning with Niehues Consulting

[Niehues Consulting](/en/) is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver and works as delivery manager, project manager and product owner in projects ranging from VC-funded scale-ups to DAX 40 corporations. He has worked in more than 20 countries on six continents. For capacity planning this means that the figures come from the running operations of the teams, and commitments are worded so that executives can take them into their own planning.

The approach follows the Niehues Delivery Model. Three of its review questions matter most here: who decides, who delivers, who uses? What is the baseline, and how do we measure success? Which roles, decision paths and interfaces does operations need? The scope and terms of an engagement are discussed in the free initial consultation, which you can arrange through the [contact form](/en/#kontakt).

**Conclusion**
Capacity is a calculated quantity: gross time minus deductions minus buffer. Commitments come from counted throughput and state a range with a probability. Anyone who also limits the number of parallel undertakings keeps dates without teams having to work faster.

**Sources**
- Schwaber, Sutherland: The Scrum Guide, 2020
- Coleman, Vacanti: The Kanban Guide, 2020
- Vacanti: Actionable Agile Metrics for Predictability, book, 2015
- Little: A Proof for the Queuing Formula L = λW, Operations Research, 1961
- Brooks: The Mythical Man-Month, book, 1975
- Weinberg: Quality Software Management, Volume 1, book, 1992
- Kahneman, Tversky: Intuitive Prediction: Biases and Corrective Procedures, 1979; Buehler, Griffin, Ross: Exploring the Planning Fallacy, Journal of Personality and Social Psychology, 1994

## Frequently asked questions

### How do you calculate sprint capacity?

You calculate sprint capacity by multiplying the working days in the sprint by the number of people and deducting absences, operational duties and a buffer. The result is the plannable capacity. The team then compares its selection for the sprint with the number of items it actually finished in recent sprints.

### What is the difference between capacity and velocity?

Capacity describes the working time available in a cycle, while velocity is the sum of story points the team completed in earlier cycles. Capacity is an input and velocity is an outcome. For external commitments the number of finished items per cycle is the better basis, because it needs no estimation unit.

### How much buffer should an agile team plan for?

The buffer follows the amount of unplanned work in past cycles. The team measures how many person-days went into disruptions, bug fixing and requests, and plans that share as a fixed deduction. The example value of 20 per cent in this article is a starting point for the calculation. The measured cycles supply your own value.

### How accurate is a Monte Carlo forecast for agile delivery?

A Monte Carlo forecast is as accurate as the history it draws on. With ten to twenty cycles and a stable team it produces a usable range with a probability. If team size or the nature of the work changes markedly, the simulation is repeated with the new data.

### How do you commit to a date when scope is uncertain?

You give management a range with a probability and the scope it refers to, for example "40 items by the end of the fifth sprint with 85 per cent confidence". If the scope changes, the statement changes and is recalculated. That keeps the commitment testable.

### Does capacity planning work without Scrum?

Yes, it works in any work system in which finished items are counted. Kanban teams work without fixed cycles and count throughput per week. The forecasting method stays the same: historical weekly values show how many items will be finished by a given date.

### What should you do when people work on several projects at once?

You reduce the number of simultaneous assignments per person and allocate capacity to undertakings in a binding way. Every additional assignment costs switching time, and the sum of commitments quickly exceeds the person's capacity. The portfolio decides which undertakings receive capacity now and which wait.

### How many cycles of data do you need for a reliable forecast?

Six cycles are enough to start, and ten to twenty give a reliable statement. The fewer observations exist, the wider the stated range must be. Start counting immediately, because older data cannot be created afterwards.