6.1 How the PRINCE2 Principles Support the Agile Context
Key Takeaways
- None of the seven PRINCE2 principles conflicts with agile — each is either reinforced by agile working or actively enables it.
- Continued business justification is strengthened because frequent releases produce measured evidence of benefit rather than forecasts.
- Manage by exception is the principle that makes self-managing delivery teams compatible with project board control.
- Focus on products aligns naturally with backlogs, acceptance criteria and the Definition of Done, all of which describe outputs rather than activities.
- Tailor to suit the project is the principle under which PRINCE2 Agile itself operates — but tailoring never removes a principle.
6.1 How the PRINCE2 Principles Support the Agile Context
Quick summary: PRINCE2 Agile's central claim is that no principle has to be weakened to work in an agile way. Several are actively strengthened. This section walks each of the seven and identifies both the support and the genuine friction.
Principle by principle
Ensure continued business justification
Agile strengthens this principle more than any other.
In a plan-driven project, continued justification is tested against a forecast: the business case says the benefits will appear eighteen months from now, and until then you are re-reading your own projection. In agile delivery, releases put working product in front of real users early, so the board can test justification against measured evidence — is anyone using it, are the outcomes appearing, is the benefit forecast holding?
The MVP is the clearest expression of this: a deliberately small release whose purpose is to buy evidence about the business case before the remaining budget is committed.
The friction: agile's tolerance for emergent scope can drift into building whatever seems interesting. The principle is the corrective — every backlog item should be traceable to a benefit, and a project whose justification has evaporated should be stopped regardless of how well the team is delivering.
Learn from experience
Agile institutionalises this principle. Where a plan-driven project might hold a lessons review at each stage boundary, agile builds learning into the delivery cadence itself: a team retrospective workshop every iteration, a project retrospective at project level, and a review event that inspects the product against real feedback.
The friction: retrospectives can become ritual. Learning only counts when it changes behaviour, which requires psychological safety and the authority to act on what is found.
Define roles, responsibilities and relationships
Agile does not dissolve this principle; it adds to it. A PRINCE2 Agile project still has an executive accountable for the business case, a senior user representing those who will use the product, and a senior supplier accountable for delivery capability. Agile adds a product owner who orders the backlog, a team coach who serves the team, and delivery roles including developers and testers.
The work this principle demands in an agile context is relationship mapping: how does the product owner relate to the senior user? Who does the team coach report to? What does the chief product owner decide that individual product owners do not? Chapter 9 answers these.
The friction: the genuine risk is duplicated or ambiguous authority — a senior user and a product owner both believing they set priorities. The principle requires that this be resolved explicitly at initiation rather than discovered mid-delivery.
Manage by stages
Compatible, provided the two rhythms are not confused. A stage is a management control period ending in a project board decision; an iteration is a delivery timebox. A stage typically contains one or more releases, each containing several iterations.
Agile makes stage boundaries better, because the board reviews a working increment rather than a progress report.
The friction: the classic error is equating a stage with a sprint, which either burdens the board with a decision every two weeks or leaves the project with no meaningful control points at all.
Manage by exception
This is the principle that makes the whole blend work.
Self-managing teams need real authority; project boards need real control. Manage by exception provides both by making the boundary explicit. Tolerances are set for each performance target at each level; within them the team acts without referring upward; only a forecast breach is escalated.
Without it, one of two failure modes appears. Either the board tries to approve everything — destroying the autonomy on which agile delivery depends — or the team acts freely with no defined limit, and the board discovers a problem only when it is too large to fix.
The friction: tolerances have to be genuinely set and genuinely honoured. A "tolerance" the board second-guesses at every highlight report is not a tolerance.
Focus on products
Strongly aligned. Agile's core artifacts are product-focused by construction. A backlog lists things to be delivered, not tasks to be performed. User stories describe capability from the user's perspective. Acceptance criteria and the Definition of Done are quality criteria attached to products.
The friction: agile's preference for emergent detail can be mistaken for a licence to leave products undefined. It is not. What is deferred is the detail of low-priority items, not the definition of what the project delivers overall — which is why the project product description, the project canvas and the release map all still exist.
Tailor to suit the project
This is the principle PRINCE2 Agile lives inside. PRINCE2 Agile is a tailoring of PRINCE2 for a particular project context.
The friction, and the hard limit: tailoring adjusts the practices, the processes and the artifacts — how formal, how large, how frequent. It never removes a principle. A team that has abandoned continued business justification, or that operates without defined roles, has not tailored PRINCE2; it has stopped using it. Recognising that boundary is a recurring exam theme.
Summary table
| Principle | How agile supports it | Where the friction is |
|---|---|---|
| Continued business justification | Frequent releases give measured benefit evidence | Emergent scope drifting from the benefit |
| Learn from experience | Retrospectives built into the cadence | Ritual retrospectives that change nothing |
| Define roles, responsibilities, relationships | Adds product owner, coaches, delivery roles | Ambiguity between senior user and product owner |
| Manage by stages | Boundaries reviewed against working product | Confusing a stage with an iteration |
| Manage by exception | Enables genuine team autonomy | Tolerances that are set but not honoured |
| Focus on products | Backlogs, acceptance criteria, Definition of Done | Deferring definition, not just detail |
| Tailor to suit the project | PRINCE2 Agile is itself a tailoring | Tailoring away a principle |
Which principle most directly reconciles a self-managing delivery team's autonomy with the project board's need for control?
Why is 'ensure continued business justification' considered to be strengthened by agile delivery?
Which statement about tailoring PRINCE2 for an agile context is correct?