# Milestone Planning in Agile Programmes: Dates for the Board, Room to Manoeuvre for Teams

Author: Marin Niehues, Niehues Consulting · Published: 2024-05-06 · Delivery & Steering
Source: https://www.niehuesconsulting.de/en/blog/milestone-planning-agile-programmes/

Milestones suit agile programmes when they describe an outcome or a decision rather than a list of tasks. The board gets dates it can steer by, and the teams keep the freedom to choose their own route in short cycles. What matters is to grade milestones by reliability: firm for the current quarter, probable for the next, directional for everything after.

This article shows how to build such a plan, which milestone types exist, and how to tell whether a milestone gives a team freedom or takes it away.

**A programme needs dates, because boards, customers and partners tie decisions to them. Teams need freedom, because they only learn what works by doing the work. Milestone planning joins the two by fixing the what and the when and leaving the how open.**

## How do milestones and agile working fit together?

Milestones and agile working fit together when the milestone names an observable outcome and the team chooses freely in which steps it gets there. The 2020 Scrum Guide has no milestones; it describes sprints of one month or less with a sprint goal. Programmes with several teams, suppliers and a budget that someone has to release need a further level on which dates are agreed between the parties. That is where milestones belong.

The conflict arises when the milestone is a task list with a date. "Requirements document complete" or "interface built" forces the team to fulfil a plan drawn up before the first experience. "Five pilot customers process orders in the new portal" describes an outcome and leaves the choice of means to the team.

Uncertainty adds to this. In 1981, in "Software Engineering Economics", Barry Boehm showed that estimates at the start of an undertaking vary by a large multiple and narrow as work progresses, a relationship known as the cone of uncertainty. A date that a programme fixes twelve months ahead therefore contains a wide range, even if it looks like an exact date.

## What kinds of milestones are there?

There are three kinds that you should manage separately: outcome milestones, decision milestones and external fixed dates. Each kind calls for a different attitude from the team and a different level of reliability.

**Milestone types in an agile programme**
Criterion | Outcome milestone | Decision milestone | External fixed date
Example | Five pilot customers work in the new portal | Release of the next budget tranche after the pilot phase | Trade fair, contract end, a partner's delivery date
What is fixed | The outcome and how it is tested | The date of the decision and its criteria | The date
What stays open | Detailed scope | The result of the decision | The content finished by then
Handling | Forecast with probability, scope as the adjustable lever | Criteria in writing beforehand, data ready on time | Plan backwards, cut content by priority
With Niehues Consulting | Outcome and metric defined per milestone | Decision rights and criteria clarified | Scope cut by value and deadline

The distinction stops every date in the programme from getting the same hardness. A fixed date such as an industry trade fair cannot move, and scope remains the only lever. An outcome milestone, by contrast, may move if the forecast says so, and the decision milestone is a conversation that has to take place reliably.

## How do you grade the reliability of milestones?

You grade reliability by horizon: firm for one quarter, probable for the next, directional for everything after. Agile planning knows this principle as a rolling wave, in which only the next section is planned in detail. The Project Management Institute describes it in the PMBOK Guide as rolling wave planning. Product development knows a related view as a roadmap with the columns "Now, Next, Later", developed by Janna Bastow in 2012.

For a programme this results in the following structure.

1. Horizon 1, the current quarter: outcomes and dates are binding, and teams plan sprints and tasks themselves. Commitments to third parties rest on a forecast with a probability.
2. Horizon 2, the following quarter: outcomes are named, dates are time windows. The programme commits to the order, and the day remains a window.
3. Horizon 3, the rest of the programme: direction and decision points. Dates get ranges, and the programme says openly that they will sharpen.

The board gets what it needs for decisions: a schedule with clearly marked certainty. The teams get planning security for what they are doing now, without the quarter after next fixing their work.

## How do you calculate milestone dates reliably?

You calculate milestone dates reliably by deriving the date from the teams' measured throughput and protecting it with a buffer that applies to the whole programme. For an individual milestone, the forecast from the article on [delivery forecasting with Monte Carlo simulation](/en/blog/delivery-forecasting-monte-carlo-simulation/) is the right tool. It supplies a probability for every date.

The buffer question is an old insight in project management. In 1997, in "Critical Chain", Eliyahu Goldratt described how teams build buffers into individual tasks, how those buffers are used up by early delays and by filling the available time, and how the deadline is missed anyway. His proposal was to estimate tasks at realistic duration and manage the buffer collectively at the end of the path. For an agile programme this means showing a programme buffer openly ahead of the milestone and reporting its consumption regularly, rather than leaving each team a hidden margin.

## Which dependencies threaten milestones?

Dependencies between teams threaten milestones most, because they create waiting time that no single team can influence. A map of dependencies therefore belongs to milestone planning. The article on [big room planning](/en/blog/big-room-planning-dependencies/) describes how to create it in a joint session, and the article on [dependencies between teams](/en/blog/managing-dependencies-between-teams/) covers managing it in day-to-day operations. Every milestone that depends on a second team gets a named owner on both sides and a date by which the dependency has to be resolved.

**Checklist: is this milestone fit for agile work?**
- Does it describe an outcome that an outsider can verify?
- Is it clear which metric or decision closes it?
- Is it established what kind of milestone it is and how firm the date is?
- Is there a forecast with a probability for the date?
- Are dependencies on other teams named and dated?
- Does the team keep the choice of means?

## How do you report milestones to the board?

You report milestones to the board as a traffic light with a probability, and the share of completed tasks plays no part in it. For each milestone the report gives the outcome, the planned date, the current probability of meeting it, and the decision the programme needs if the probability falls. This moves the conversation from whether everything is on track to which lever leadership wants to pull: scope, order, capacity or date. The question of levers also resolves many conflicts with business units, as the article on [stakeholder management](/en/blog/stakeholder-management-agile-projects/) shows.

A programme that reports the probability monthly avoids the classic pattern in which a milestone sits at green for weeks and then jumps to red in a day. The probability drops visibly before the date is missed, and leadership decides while there is still room. For planning individual deliveries, [release planning](/en/blog/release-planning-reliable-commitments/) also helps.

## Milestone 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, in projects ranging from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the service area of delivery management and organisation design he takes on programme steering as delivery manager, project manager or product owner and designs the planning rhythm, roles and reporting lines.

The approach follows the Niehues Delivery Model. Three of its test questions matter most for milestone planning: Which business outcome should change measurably? Who decides, who delivers, who uses? Which roles, decision paths and interfaces does operations need? You start with a free initial consultation of 30 minutes, which you can book via the [contact form](/en/#kontakt). The scope and terms of an engagement are discussed in the free initial consultation.

**Conclusion**
Milestones and agile teams go together when the milestone is an outcome or a decision, when reliability is graded by horizon, and when dates are reported as probabilities. The board then steers on data, and the teams keep their route.

**Sources**
- Boehm, Barry: Software Engineering Economics, book, 1981
- Goldratt, Eliyahu: Critical Chain, book, 1997
- Schwaber, Sutherland: The Scrum Guide, 2020
- Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), standard

## Frequently asked questions

### What is a milestone in an agile project?

A milestone in an agile project is a date on which a verifiable outcome exists or a decision is taken. It describes what has been achieved and leaves the team to decide how to get there. In programmes with several teams it serves to align the parties involved.

### Does Scrum need milestones?

The Scrum Guide provides for no milestones, though a programme with several teams usually needs them. A single team works with sprint goals and a product backlog. Once budgets, suppliers or external dates come into play, milestones link the team to its surroundings.

### How do you plan an agile programme with fixed dates?

You plan backwards from the fixed date, cut scope by priority and leave the choice of means with the team. The date stays as the fixed point and the content is the adjustable lever. A forecast shows which scope will be finished by then, and with what probability.

### What is the difference between a roadmap and a milestone plan?

A roadmap shows outcomes in horizons, while a milestone plan gives dates with a level of commitment. The two combine well: the roadmap orders outcomes into Now, Next and Later, and milestones give the horizons dates and probabilities.

### How many milestones does a programme need?

A programme needs enough milestones for the board to take one or two outcome-based decisions per quarter. More milestones create reporting effort without improving steering. The number follows from the decisions the programme actually needs.

### What do you do about a milestone that cannot be met?

You put the levers in front of leadership early: cut scope, change the order, add capacity or move the date. A falling probability shows the moment when the decision falls due. The earlier it is taken, the more options remain.

### How do you stop milestones forcing teams into a plan?

You word milestones as outcomes with a metric and plan only the next horizon in detail. The team decides within its sprints which work leads to the outcome. The checklist in this article helps you test milestones for that quality.

### What is rolling wave planning?

Rolling wave planning means that only the next section is planned in detail while later sections stay rough. With each section the next becomes more precise. The Project Management Institute describes the method in the PMBOK Guide, and agile programmes use it as a basic planning principle.