Release Planning: Committing to Dates That Hold

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.

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.

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.

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.

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