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

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.

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.

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 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 describes how to create it in a joint session, and the article on 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.

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 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 also helps.

Milestone planning with Niehues Consulting

Niehues Consulting 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. The scope and terms of an engagement are discussed in the free initial consultation.