7.4 Plans Artifacts and Techniques: Release Maps, Timeboxes and Estimation

7.4 Plans Artifacts and Techniques: Release Maps, Timeboxes and Estimation

Quick summary: The release map schedules when features will be delivered. Timeboxing fixes the end date and flexes scope. Velocity converts relative estimates into a release forecast. Trading or swapping keeps a timebox's size constant, with the product owner agreeing priorities. Work packages are the interface between the project manager and a delivery team.

The release map

The release map shows when features will be delivered across the project. It sits between the prioritized project backlog and the stage plans, and it is the artifact the project board reads to understand delivery.

What a release map carries:

• The planned releases in sequence, with target dates
• The features or capability areas each release contains
• The benefits each release is expected to start unlocking
• The stage boundaries the releases sit within

Its governance value is that it makes the connection between delivery and benefit visible. A board looking at a release map can ask the question that matters: if we stopped after release two, would we have something worth having? If the answer is no, the sequencing is wrong — the highest-value capability should be earliest, so that the option to stop is always live.

The release map is updated when the plan is documented, and it is a standing input to release planning workshops and to stage boundary decisions.

Timeboxing

Timeboxing is the practice of fixing a period of time that cannot be extended and flexing the scope within it. It applies at iteration, release and stage level.

Why the discipline is worth the difficulty:

• It forces prioritization. If the date cannot move, the team must decide what actually matters. Prioritization deferred is prioritization avoided.
• It makes progress measurable. A fixed cadence of completed increments gives a real throughput figure, where a sliding deadline gives none.
• It protects quality — provided the Definition of Done is held. The permitted response to a squeeze is to drop scope, never to skip testing.
• It counters Parkinson's Law and the student syndrome. Work does not expand to fill a period that cannot expand.

The rule that makes timeboxing legitimate: when work will not fit, scope flexes, not the date, and never the Definition of Done.

Estimation and velocity

Estimation is relative — story points or t-shirt sizing — because relative comparison is more reliable than absolute duration prediction.

Velocity is the number of story points a team completes per iteration. After a few iterations it becomes a forecasting instrument: a release containing 150 points, for a team with a velocity of 25, is about six iterations of work.

Three cautions that are also exam distractors:

1. Velocity is not a productivity target. Used as one, it produces estimate inflation and destroys the honesty the number depends on.
2. Velocity is not comparable between teams. Story points are calibrated within a single team.
3. Velocity needs history. A new team has no meaningful velocity, so its first release forecast is a range, not a number.

Trading and swapping requirements

Trading (or swapping) is the technique that keeps a timebox's committed size constant when something new arrives. New work can enter an in-flight timebox only if work of equivalent size leaves it.

This is how PRINCE2 Agile keeps embrace change and fixed timeboxes from contradicting each other. The team is not refusing change; it is refusing to pretend that added work is free.

The role to consult is the product owner. When requirements are traded or swapped, the product owner assesses and agrees the priority of what goes in and what comes out — because priority is their accountability. The project manager is involved when the trade affects the work package's tolerances or the release map; the developers and the team coach do not decide priority.

Trading also has a limit. If everything in the timebox is a Must have, there is nothing to trade out, and the change must be escalated as an issue instead. That is a signal that the MoSCoW prioritization was not honest.

Work packages

A work package is the agreement between the project manager and a delivery team about what will be produced. It carries:

• The products to be delivered and their descriptions
• The tolerances the team may work within — the practical expression of manage by exception
• The Definition of Done and any specific acceptance criteria
• Reporting arrangements: how and how often the team reports progress, typically via a team dashboard rather than written reports
• Constraints, interfaces and dependencies

The work package is the interface at which governance meets self-management. Above it, the project manager manages tolerances and the board relationship. Below it, the team decides how the work gets done. Getting that boundary right is most of what makes a PRINCE2 Agile project work: a work package specifying how the team should build something has crossed the line and destroyed the autonomy the delivery approach depends on.