# Release Planning: Committing to Dates That Hold

Author: Marin Niehues, Niehues Consulting · Published: 2023-11-20 · Delivery & Steering
Source: https://www.niehuesconsulting.de/en/blog/release-planning-reliable-commitments/

Reliable dates come from a team's measured throughput: the commitment states a range with a probability, such as the date that holds in 85 cases out of 100. A single effort estimate, by contrast, yields a number with no confidence level, and it is exactly this number that companies keep missing. This article shows why release dates are so often missed, how to derive a forecast from your team's data and which commitment to give customers, board and business units.

For managing directors, release planning is a question of trust. A date given to sales, to a customer or to the board becomes a commitment, and every postponement costs credibility. The article is written for decision-makers who agree dates with software teams, product development or functional projects and who want to know how to improve the hit rate without padding every plan with buffer.

**A date without a probability is a hope. Those who derive the commitment from the throughput of recent weeks and choose the desired confidence level explicitly hit more often and can announce postponements earlier.**

## Why are release dates missed so often?

Release dates are missed because effort estimates are systematically too optimistic and because scope changes during the work. Psychology knows the phenomenon as the planning fallacy. Daniel Kahneman and Amos Tversky described it in 1979, and Roger Buehler, Dale Griffin and Michael Ross examined it in 1994 in a study of psychology students. The participants estimated that their senior thesis would take 33.9 days on average, and it took 55.5 days on average. Even the worst-case estimate, at 48.6 days on average, fell short of the actual duration.

Two consequences follow for practice. An estimate without a confidence level is no use as a date, even when it is meant honestly and realistically. And a team that produces its own plan is no different from others: it is subject to the same pattern as any other person. Reasons from the organisation come on top: dependencies on other teams, approvals with waiting time and new requirements that arrive after the plan is made. In "Software Engineering Economics" in 1981, Barry Boehm showed that the uncertainty of an estimate at the start of an undertaking is many times larger than shortly before the end. The depiction of this finding is called the cone of uncertainty. A single number at the start hides this spread. Where waiting time arises in delivery is described in the article on [time to market](/en/blog/reduce-time-to-market/).

## How do you build a forecast that holds?

A forecast that holds is built from the number of work items the team has actually completed in recent weeks and the number of items still outstanding. The approach follows flow forecasting, which builds on the measures of the Kanban Guide of 2020 and is described by Daniel Vacanti in "Actionable Agile Metrics for Predictability" (2015): instead of estimating the effort of each item, you use the observed throughput and its spread. How to collect these measures is shown in the article on [flow metrics](/en/blog/flow-metrics-throughput-wip-wait-time/).

**Calculation: from throughput to a date with a probability**
An example with assumed values: the release contains 60 items. In the last twelve weeks the team has completed 3, 5, 4, 6, 2, 5, 4, 5, 3, 6, 4 and 5 items. The mean is around 4.3 items a week, the standard deviation around 1.2. The date that holds in half of all cases lies at 60 divided by 4.3, around 14 weeks. For a date with 85 per cent confidence, the calculation deducts the spread of the weekly values, which partly evens out over many weeks, and arrives at around 15 weeks. The larger uncertainty is the scope: if the release grows by 15 per cent to 69 items, the dates move to around 16 and 18 weeks. The honest answer to the question of when the release will be finished is therefore 14 to 18 weeks. The method is a rough approximation that assumes weeks are independent of one another. A Monte Carlo simulation draws the weekly values anew a thousand times and gives the probabilities more precisely.

The calculation holds under three conditions. The team works in a similar composition as in recent weeks, the items are of a similar order of magnitude, and the scope remains essentially stable. If the scope grows, the calculation is repeated with the new number of items. This takes minutes each week and is the reason the forecast makes postponements visible early.

## Which commitment do you give to whom?

You give each recipient the commitment that matches their risk: internally a range, to customers a date with high confidence, and contractually a date with buffer. The level of confidence follows the cost of a delay. A delay carrying a contractual penalty justifies a higher confidence level than an internal target for which a week's postponement has no consequences.

**Commitment levels for release dates**
Commitment | Confidence | Recipient | Typical use
Internal range | 50 to 85 per cent | Team and department heads | Steering daily work and early decisions
Date commitment to customers | around 85 per cent | Customers and sales | Announcements and project plans
Contractual date | 95 per cent or higher | Customers with contractual penalties | Contracts with fixed deadlines
Fixed date with variable scope | Date is set, scope is steered | Board and business unit | Trade fairs, deadlines, external requirements

A commitment with 95 per cent confidence is more expensive than one with 85 per cent, because it contains more reserve and pushes the date back. This trade-off belongs in the hands of leadership. The question is then how many additional weeks the safeguard costs and what a delay would cost. Contractual deadlines and penalties are matters for your legal department or lawyers: this article provides an overview and does not constitute legal advice.

## How do you plan a release in four steps?

You plan a release in four steps: slice the scope, measure throughput, produce a forecast with a probability and reassess weekly. Each step can be carried out in the existing ticketing system.

1. Slice the scope into items of similar size: the items should be small enough for the team to finish each within a few days. An item that takes weeks distorts the forecast. The definition of when an item counts as finished is fixed in advance.
2. Collect throughput for the last eight to twelve weeks: items completed per week are counted. For teams without a history, measurement begins with the first cycle, and the forecast becomes more accurate as the data grows.
3. Produce the forecast: from the number of items and the throughput come a range and the probability for the desired date. The executive team chooses the confidence level from the table above.
4. Reassess weekly: each week the new throughput and the current number of items go into the calculation. If the date moves outside the range, the message goes to those concerned at once and not only when the date is reached.

## What if the date is fixed?

If a date is fixed, scope becomes the steering variable. Before the start, leadership divides the scope into items that are essential and items that can be dropped if delays occur, and the team delivers the essential ones first. The forecast then shows early whether the essential part fits into the time. If it does not, the date and the team's capacity remain as levers, and the decision is taken weeks before the deadline. A steady rhythm of small deliveries, as described in the article on [introducing Kanban](/en/blog/introducing-kanban-flow-over-utilisation/), makes this steering easier, because every week a part of the scope is finished and the remaining volume shrinks.

## Release planning with Niehues Consulting

[Niehues Consulting](/en/) is a Düsseldorf consultancy for AI management and organisation design from the delivery perspective. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. Within delivery management he works as delivery manager, project manager or product owner and takes responsibility for committed dates being met.

The approach follows the Niehues Delivery Model with its three phases. Three of its review questions matter most for release planning: Who decides, who delivers, who uses? What is the baseline, and how do we measure success? Which metric shows after 90 days that the solution is landing? The forecast from throughput supplies the baseline, and the weekly reassessment shows whether delivery stays within the range. The entry point is a free initial consultation of 30 minutes, which you can arrange via [contact](/en/#kontakt).

**Conclusion**
Dates hold when they are committed from measured throughput and with an explicitly chosen probability. The single effort estimate is subject to the planning fallacy and often ends in a postponement. Those who slice scope into small items, recalculate weekly and give customers a date with 85 per cent confidence postpone less often and earlier.

**Sources**
- Kahneman, Tversky: Intuitive Prediction: Biases and Corrective Procedures, TIMS Studies in Management Science, 1979
- Buehler, Griffin, Ross: Exploring the Planning Fallacy, Journal of Personality and Social Psychology, 1994
- Boehm, Barry: Software Engineering Economics, Prentice Hall, 1981
- Vacanti, Daniel: Actionable Agile Metrics for Predictability, book, 2015
- Coleman, Vacanti: The Kanban Guide, 2020

## Frequently asked questions

### How do you plan a release reliably?

You plan a release reliably by slicing the scope into small items and deriving a forecast with a probability from measured throughput. The commitment then states a range, such as 14 to 18 weeks, and not a single date. Weekly reassessment keeps the forecast current.

### Why are project deadlines missed so often?

Deadlines are missed because estimates are too optimistic and scope grows during the work. Research on the planning fallacy shows this bias even among people who know their work well. Dependencies and waiting times reinforce it.

### What is a Monte Carlo simulation in release planning?

A Monte Carlo simulation draws weekly results at random a thousand times from the team's history and uses them to calculate how long the remaining scope takes. The result is a distribution of dates with probabilities. The method replaces the estimation of individual items with measured data.

### What confidence should a date commitment have?

For customers, a date with around 85 per cent confidence has proved effective, and where contractual penalties apply a higher value is appropriate. The higher the confidence, the later the date. Leadership chooses the value according to the cost of a delay.

### What should you do if the delivery date cannot move?

With a fixed date you steer the scope. You divide it in advance into essential items and items that can be dropped, and deliver the essential ones first. The forecast shows weeks before the deadline whether the essential part fits.

### How much data does a throughput forecast need?

Eight to twelve weeks of history are enough for a first reliable forecast. With less data the range becomes wider and the statement more cautious. New teams start with the first cycle and improve the forecast with every week.

### Does this work without story points?

Yes, the forecast counts completed items and needs no story points. The prerequisite is items of similar size. Counting takes less effort than estimating in points, and a team that runs both for a few weeks can see whether they forecast equally well for its own work.

### Who is responsible for a release date?

The date is a shared responsibility: the team supplies the data and the forecast, and leadership chooses the confidence level and decides on scope and capacity. A delivery manager or product owner brings both together and reports deviations early.