1.3 PRINCE2 Agile Key Terms You Must Be Able to Define

1.3 PRINCE2 Agile Key Terms You Must Be Able to Define

Quick summary: The syllabus names eight glossary terms you must be able to define at Bloom's level 1: backlog (project and product), benefit, dashboard (project and team), epic user story, project canvas, release map, timebox (iteration, release, stage) and waterfall. These recur as missing-word and standard questions, and several of them are Version 2 additions that do not appear in older PRINCE2 Agile material at all.

Backlog — project and product

A backlog is a prioritized list of everything that might be delivered. It is not a specification and not a contract: it is a living, ordered queue that is refined continuously.

PRINCE2 Agile distinguishes two scales:

• The project backlog holds requirements at project level. It is the project's view of what could be built, expressed at a level the project board and the chief product owner can reason about. Requirements are expressed here.
• The delivery (product) backlog is what an individual delivery team works from. Items are smaller, closer to ready, and refined into user stories the team can size and pull into an iteration.

The relationship between them is one of the chief product owner's central responsibilities: keeping the project backlog and the delivery teams' product backlogs aligned so that teams are building the things the project actually needs next.

Benefit

A benefit is a measurable improvement resulting from an outcome that is perceived as an advantage by one or more stakeholders. Three parts of that definition earn marks:

• Measurable — if you cannot measure it, you cannot demonstrate it was realized.
• Resulting from an outcome — the project delivers outputs (products); outputs enable outcomes (changes in behaviour or capability); outcomes yield benefits. A new system is an output, not a benefit.
• Perceived as an advantage by stakeholders — the same outcome may be a benefit to one group and a dis-benefit to another.

Benefits drive the business case practice, and in an agile context they are the reason frequent releases matter: an early release can start realizing benefits long before the project closes.

Dashboard — project and team

A dashboard is a visual, at-a-glance display of current status, designed to be read rather than studied.

• A project dashboard shows the project manager and project board where the project stands: progress against the release map, tolerance consumption, top risks and issues, benefit forecasts.
• A team dashboard shows a delivery team its own state: work in progress, blockers, burn charts, Definition of Done compliance.

Dashboards are the agile answer to the question "how do we keep the board informed without writing reports nobody reads?" Maintaining the information held on project dashboards is a named responsibility, and a team dashboard is one of the things a kickoff workshop establishes.

Epic user story

A user story expresses a requirement from the user's point of view, conventionally in the form "As a [role], I want [capability], so that [benefit]."

An epic user story is simply a user story that is too large to be delivered within a single iteration. It is a placeholder for a body of work that will be decomposed into smaller stories as it approaches the top of the backlog. Epics let a team hold long-range scope in the backlog without pretending to know detail it does not yet have.

Project canvas

The project canvas is a single-page artifact that captures the essence of the project: its purpose, the user groups it serves, the outcomes and benefits sought, the constraints, and the high-level approach. It is deliberately one page so that it can be read, challenged and revised in a room full of people.

It is produced collaboratively in a project canvas workshop, in which the user groups are defined and prioritized. Because it is short and visual, it is far more likely to be kept current than a long project brief — and it is one of the artifacts most amenable to being drafted quickly with AI assistance and then verified by a human.

Release map

A release map shows when features will be delivered across the life of the project. It sits between the project backlog and the plans practice: it takes prioritized requirements and schedules them into releases, so that everyone can see which capability lands when, and therefore when each benefit starts to accrue.

The release map is updated as part of the planning approach — specifically when the plan is documented — and it is a standing input to release planning workshops and stage boundary decisions.

Timebox — iteration, release, stage

A timebox is a fixed period of time that cannot be extended. When work will not fit, the scope of the timebox flexes; the end date does not move. PRINCE2 Agile uses timeboxes at three nested scales:

The nesting matters: a stage is not a sprint. Stages exist for management control and end at a stage boundary where the board decides whether to continue. Iterations exist for delivery cadence. Conflating them is a classic exam trap.

Waterfall

Waterfall is a sequential, linear delivery approach in which each phase — requirements, design, build, test, deploy — is completed before the next begins. Everything is specified up front, and change is handled by formal change control.

PRINCE2 Agile does not treat waterfall as an error. It treats it as an approach that suits stable, well-understood, heavily regulated work, and treats iterative and incremental delivery as suiting work where requirements will be discovered. A project may legitimately use both: waterfall for a hardware sub-project, iterative delivery for the software around it.