7.3 The Plans Practice in an Agile Context

7.3 The Plans Practice in an Agile Context

Quick summary: The plans practice facilitates communication and control by estimating how much work is to be delivered and when, and by what means. PRINCE2 Agile plans in layers — project, stage, team, iteration — with detail increasing as the horizon shortens.

Purpose

A plan is not a prediction; it is a communication and control device. It states what will be delivered, by whom, by when and at what cost, in enough detail for the relevant level of management to make decisions and to detect deviation.

That framing matters in an agile context because it answers the usual objection ("we can't plan, requirements will change"). The response is that you plan at the level of confidence you actually possess: precisely for the next iteration, coarsely for the next release, directionally for the project.

Layers of planning

The release map is the artifact that links these layers. It schedules when features will be delivered, so the board can see which capability lands in which release and therefore when each benefit starts to accrue.

Stages, releases and iterations

This distinction generates exam questions every sitting.

• A stage is a management control period. It exists so that the project board can make a go/no-go decision at its boundary. Stage length is chosen for management reasons — risk, investment size, decision points — not for delivery cadence.
• A release is a set of features delivered together into use.
• An iteration (or timebox, or sprint) is a delivery cadence, typically one to four weeks.

They nest: a stage contains one or more releases; a release contains one or more iterations.

A stage is not a sprint. Treating them as equivalent produces one of two errors: board decisions every two weeks, which is unworkable, or no meaningful control points at all.

Progressive elaboration

Planning horizons differ deliberately:

• The next iteration is planned in detail: specific stories, estimated, meeting the Definition of Ready.
• The current release is planned at feature level: which capability, in roughly what order, at what confidence.
• The rest of the project is planned at epic level: what capability areas exist, sized in t-shirts, sequenced by benefit.

This is progressive elaboration, not vagueness. The distant plan exists and is testable; it is simply expressed at the resolution the available evidence supports. Elaborating distant work in false detail is waste, because the detail will be invalidated before it is used.

Planning activities

The PRINCE2 Agile planning approach runs through a recognisable set of activities. Those the exam refers to include:

• Preparing estimates — sizing the work, using relative estimation such as story points or t-shirt sizing.
• Preparing the budget — converting effort and duration into cost, including risk and change budgets.
• Organizing work packages — grouping products into packages that can be agreed with a delivery team, each with its tolerances and its Definition of Done.
• Documenting the plan — recording the agreed plan, and this is the activity in which the release map is updated.

Alongside these sit the product-focused steps PRINCE2 has always used: defining and analysing the products, identifying activities and dependencies, and analysing the risks in the plan.

What tailoring looks like

• Estimation is relative rather than in absolute hours, and forecasting uses velocity once a team has history.
• Plans are living. They are baselined so deviation can be detected, but re-planning at the end of each iteration is normal rather than exceptional.
• Scope is expressed as prioritized backlog items, so the plan naturally contains the flexibility that time-and-cost-firm delivery requires.
• Detail is deferred, not omitted. Deferring the detail of low-priority items is progressive elaboration; failing to define what the project delivers overall is a breach of focus on products.
• Team plans are made by the team. The project manager agrees the work package and its tolerances; how the team meets it is the team's decision.

The relationship with progress

Plans and progress are a pair. Plans set the baseline; progress compares what has been delivered with what was planned and controls deviations that would cause an exception. If a question mentions estimating and scheduling, it is plans; if it mentions comparing delivery against plan, it is progress.