Capacity Planning in Agile Teams: Commitments Based on Data

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.

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.

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.

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.

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.

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.