6.2 The Purpose of the Seven PRINCE2 Agile Practices
Key Takeaways
- The seven practices are business case, organization, plans, quality, risk, issues and progress — all seven addressed continually throughout the project.
- Practices are the Version 7 term for what earlier editions called themes, and the old Change theme is now the Issues practice.
- The business case practice judges whether the project is desirable, viable and achievable; the organization practice defines the project's responsibilities.
- The plans practice estimates how much work is to be delivered and when; the progress practice compares what has been delivered with what was planned.
- The issues practice controls changes to the project's baseline, and a purpose of the progress practice is to control deviations causing an exception.
6.2 The Purpose of the Seven PRINCE2 Agile Practices
Quick summary: Seven practices, each addressed continually throughout the project rather than completed once: business case, organization, plans, quality, risk, issues, progress. Their purpose statements are directly examinable — expect both standard questions ("which practice has the purpose of…") and missing-word questions ("a purpose of the [ ? ] practice is to…").
Practices, not themes
PRINCE2 Version 7 renamed themes to practices, and PRINCE2 Agile Version 2 follows. This is not merely cosmetic: practice carries the sense of something you do continually, which is precisely the point. You do not "complete" the risk practice in week three; you attend to risk from before the project starts until after it closes.
The list also changed. The old Change theme is now the Issues practice. If your notes list Business Case, Organization, Quality, Plans, Risk, Change, Progress, they describe the pre-Version-7 structure.
| Old term (Version 1 / PRINCE2 6) | Current term (Version 2 / PRINCE2 7) |
|---|---|
| Themes | Practices |
| Change theme | Issues practice |
| Management products | Artifacts |
The seven purposes
| Practice | Purpose | The question it answers |
|---|---|---|
| Business case | To support decision making by judging whether the project is, and remains, desirable, viable and achievable | Is this worth doing, and is it still worth doing? |
| Organization | To define the project's responsibilities and establish its structure of accountability | Who is accountable for what, and how do the roles relate? |
| Plans | To facilitate communication and control by estimating how much work is to be delivered and when, and by what means | What will be delivered, by whom, by when, and at what cost? |
| Quality | To ensure that the users' requirements and expectations for the project's products are met | Will the product be fit for purpose, and how will we know? |
| Risk | To identify, assess and control uncertainty — threats and opportunities — during the project | What might happen, and what will we do about it? |
| Issues | To address issues and control changes to the project's baseline | Something has happened or been requested — what do we do? |
| Progress | To monitor and compare what has been delivered with what was planned, forecast, and control any deviations causing an exception | Where are we, where will we end up, and do we need to escalate? |
Getting the distinctions right
Purpose questions are usually testing whether you can separate two practices that overlap in ordinary language.
Business case vs plans
The business case asks whether the project should happen: is it desirable, viable and achievable? Plans ask how much and when: estimating the work and scheduling it. If the option mentions desirable, viable and achievable, it is the business case. If it mentions estimating how much work is to be delivered and when, it is plans.
Progress vs plans
Plans set the baseline; progress compares reality to it. If the option mentions comparing what has been delivered with what was planned, it is progress. If it mentions estimating and scheduling, it is plans. Progress also owns controlling deviations that cause an exception — that phrasing is the giveaway in a missing-word question.
Issues vs risk
Risk is about uncertainty — something that has not happened. A risk is a possible future event, and it is either a threat or an opportunity. Issues concern things that have happened or been requested now — a problem, a concern, an off-specification, or a request for change. The moment a risk materialises, it becomes an issue.
The other half of the issues practice is change control: controlling changes to the project's baseline. That is the phrase that identifies it.
Quality vs organization
Quality concerns whether the product meets the users' requirements and expectations. Organization concerns who is accountable for what. If a question asks which practice has the purpose of defining the project's responsibilities, the answer is organization.
Practices in an agile context
Each practice is tailored rather than dropped. Chapters 7 and 8 cover them in detail; in outline:
- Business case — right-sized, potentially held on the project canvas, re-tested against evidence from each release; benefits realized progressively.
- Organization — PRINCE2 project roles integrated with agile delivery roles, with a chief product owner where multiple teams are involved.
- Plans — planned in layers: a release map for the project, plans for stages, and the delivery team planning its own iterations. Estimation is relative.
- Quality — expressed through acceptance criteria, the Definition of Ready, the Definition of Done and continuous testing rather than a single late test phase.
- Risk — reduced structurally by short feedback loops; risks surfaced in iterations, stages, retrospectives and progress reviews.
- Issues — change embraced at the delivery level by re-prioritizing the backlog inside a fixed timebox, with formal change control reserved for changes to the baseline itself.
- Progress — tracked with burn charts, dashboards and working increments, rather than percentage-complete estimates.
The constant across all seven is that what is tailored is the form and formality, never the purpose. The business case may be a page rather than a document, but the project still has to be desirable, viable and achievable.
Which practice has the purpose of defining the project's responsibilities?
How is the progress practice used?
A supplier notifies the project that a component delivered last week does not meet its agreed specification. Which practice governs the response?