Exam identity and focus
| Item | Detail |
|---|
| Official vendor/provider | PeopleCert |
| Official exam title | PRINCE2 Agile Practitioner (Version 2) |
| Official exam code | PRINCE2 Agile Practitioner |
| Quick Reference purpose | Independent review support for applying PRINCE2 governance in agile delivery scenarios |
PRINCE2 Agile Practitioner questions are usually about judgement in context: what to tailor, what to protect, what to escalate, and how PRINCE2 roles, practices, and processes work with agile delivery techniques.
High-yield exam stance:
- PRINCE2 governs the project. Agile helps deliver products iteratively and incrementally.
- Do not replace PRINCE2 with Scrum, Kanban, or another agile method. Tailor PRINCE2 so governance remains effective.
- Protect business justification, quality, and transparency.
- Use scope flexibility and prioritization to meet time and cost constraints.
- Escalate only when tolerances are forecast to be exceeded. Do not escalate every agile discovery.
Core PRINCE2 Agile integration model
| Dimension | PRINCE2 contribution | Agile contribution | Practitioner decision point |
|---|
| Governance | Business justification, roles, tolerances, stages, controls | Transparency through frequent feedback | Keep governance proportionate but visible |
| Delivery | Defines products, acceptance, accountability | Iterative/incremental build, inspect/adapt | Let teams self-organize within agreed controls |
| Planning | Project Plan, Stage Plans, Product Descriptions | Backlogs, release plans, sprint/iteration plans | Use rolling-wave detail; avoid false certainty |
| Change | Issue/change control, impact assessment, authority | Welcomes learning and reprioritization | Embrace change within tolerance; escalate exceptions |
| Quality | Quality criteria, acceptance, assurance | Definition of Done, automated testing, reviews | Never cut quality to meet a timebox |
| Progress | Manage by exception, reports, stage boundaries | Boards, burn charts, demos, flow metrics | Combine agile information radiators with PRINCE2 controls |
PRINCE2 principles tailored for agile
| PRINCE2 principle | Agile application | Common exam trap |
|---|
| Continued business justification | Validate assumptions through increments, demos, releases, experiments, and benefits evidence | Continuing just because a sprint or release is underway |
| Learn from experience | Use retrospectives, lessons log, reviews, spikes, and feedback loops | Treating lessons as only an end-project activity |
| Define roles, responsibilities, and relationships | Map PRINCE2 governance roles to agile delivery roles clearly | Assuming Product Owner automatically replaces Senior User or Project Board |
| Manage by stages | Use stages for governance decisions; stages may contain multiple sprints/releases | Treating every sprint as a PRINCE2 management stage by default |
| Manage by exception | Set tolerances for time, cost, scope, quality, benefits, and risk; team works within delegated limits | Escalating normal backlog changes that remain within tolerance |
| Focus on products | Use Product Descriptions, user stories, acceptance criteria, and Definition of Done | Planning around activities instead of products/outcomes |
| Tailor to suit the project | Adjust controls, reports, roles, and planning depth to agile context | Removing governance because the team is “agile” |
PRINCE2 Agile commonly expects candidates to understand how agile changes the treatment of the six PRINCE2 performance targets.
| Performance target | Typical agile treatment | Practical implication | Wrong exam answer pattern |
|---|
| Time | Often fixed through timeboxes, stages, or release dates | Hit deadlines by prioritizing scope | Extending the timebox whenever work is unfinished |
| Cost | Often fixed because team size and duration drive cost | Keep teams stable where possible | Adding people late without considering disruption |
| Quality | Protected; not a normal trade-off | Use quality criteria, acceptance criteria, Definition of Done, testing, reviews | Reducing quality to meet a deadline |
| Scope | Main area of flexibility | Use MoSCoW, backlog ordering, MVP/MMP thinking, and descoping | Treating all requirements as mandatory |
| Risk | Managed explicitly; agile makes risk visible earlier | Use experiments, spikes, prototypes, early delivery, risk responses | Assuming agile removes the need for risk management |
| Benefits | Protected and validated | Reassess Business Case as learning emerges | Delivering features that no longer support benefits |
High-yield PRINCE2 Agile targets:
| Target | Meaning in exam scenarios |
|---|
| Be on time and hit deadlines | Timeboxes and release dates matter; use scope flexibility first |
| Protect the level of quality | Quality criteria are not reduced just to finish more scope |
| Embrace change | Change is expected, but still controlled through prioritization and tolerances |
| Keep teams stable | Avoid unnecessary churn; stable teams improve flow, velocity, and knowledge |
| Accept that the customer does not need everything | Prioritize essential value; not every requested feature is required for success |
Agilometer quick reference
The Agilometer is used to assess how suitable the project environment is for agile ways of working and to guide tailoring. It is not a simple pass/fail score.
| Agilometer area | Strong agile signs | If weak, consider |
|---|
| Flexibility on what is delivered | Stakeholders accept prioritization and variable scope | Education on MoSCoW, explicit scope tolerance, staged delivery |
| Level of collaboration | Business, supplier, and user representatives are available and engaged | Secure Senior User/Product Owner involvement; set collaboration expectations |
| Ease of communication | Co-located or well-connected teams; fast decisions | Digital boards, communication plan, agreed response times, workshops |
| Ability to work iteratively and deliver incrementally | Product can be built/tested in slices | Architecture spikes, modular design, integration planning |
| Advantage of iterative and incremental delivery | Early feedback, early value, risk reduction possible | Use hybrid/predictive controls where agile adds limited value |
| Level of uncertainty | Uncertainty can be reduced through experiments and feedback | Discovery work, prototypes, risk responses, tighter governance |
Exam use: when a scenario shows low collaboration, fixed scope, poor communication, or limited incremental delivery, the best answer is usually to tailor the approach and manage the risk, not to declare agile impossible without analysis.
Agile behaviours expected in PRINCE2 Agile
| Behaviour | What it looks like | Exam clue |
|---|
| Transparency | Visible work, honest progress, clear tolerances, accessible information radiators | Prefer open reporting over optimistic status |
| Collaboration | Business and supplier work together frequently | Lack of user availability is a project risk |
| Rich communication | Face-to-face or high-bandwidth communication where practical | Do not rely only on formal documents when rapid feedback is needed |
| Self-organization | Delivery team plans and manages detailed work within boundaries | Project Manager should not assign every task in the sprint |
| Exploration | Use spikes, prototypes, experiments, and incremental learning | Uncertainty should trigger learning loops, not premature detailed plans |
Role alignment matrix
| Role or interest | PRINCE2 Agile responsibility | Agile interaction | Watch for this trap |
|---|
| Executive | Owns Business Case and overall business accountability | Uses agile evidence to validate continued justification | Delegating business justification to the delivery team |
| Senior User | Represents user needs and benefits | May work closely with or sponsor Product Owner-type role | Assuming all user feedback equals formal acceptance |
| Senior Supplier | Represents supplier capability/resources | Ensures agile delivery approach is feasible | Ignoring supplier constraints because team is agile |
| Project Board | Directs by exception, authorizes stages, sets tolerances | Uses demos, metrics, and reports for decisions | Getting involved in daily delivery detail |
| Project Manager | Manages project controls, plans, risks, issues, reporting, and stakeholder alignment | Creates environment for agile delivery; coordinates with agile roles | Acting as Scrum Master or task manager by default |
| Team Manager | Accepts Work Packages and manages delivery of assigned products | May be an agile delivery lead, Scrum Master, or team representative depending on tailoring | Confusing team-level coordination with project governance |
| Product Owner / product representative | Prioritizes backlog and clarifies product needs where used | Works with team and user/business representatives | Treating Product Owner as automatically equivalent to Senior User |
| Scrum Master / agile coach | Facilitates agile events, removes impediments, supports team improvement | Helps team self-organize | Giving Scrum Master Project Board authority |
| Delivery team | Builds, tests, and demonstrates increments | Estimates, plans sprint/iteration work, maintains quality | PM micromanaging technical tasks |
| Change Authority | Makes delegated change decisions within limits | May approve significant backlog or baseline changes | Letting any backlog change bypass agreed change control |
| Project Assurance | Checks business, user, and supplier interests independently | Can use agile evidence such as reviews, metrics, and quality results | Assuming agile transparency removes assurance need |
| Project Support | Maintains information, configuration, tools, logs, and admin support | May support boards, repositories, registers, and reporting | Losing configuration control in fast-moving delivery |
PRINCE2 process reference for agile scenarios
| Process | Main purpose | Agile tailoring focus | Practitioner “best next action” cues |
|---|
| Starting up a Project | Confirm the project is worthwhile to initiate | Assess agile suitability, capture lessons, outline product vision, identify agile roles/stakeholders | If the project context is unclear, assess suitability and governance needs before committing |
| Directing a Project | Project Board decision-making and authorization | Set tolerances, authorize stages, make exception decisions using agile evidence | If tolerance will be exceeded, board direction is required |
| Initiating a Project | Create firm foundations and PID | Define agile approach, controls, communication, quality, risk, change, backlog/release planning approach | If governance is missing, establish PID-level controls rather than start delivery blindly |
| Controlling a Stage | PM manages stage within tolerances | Use checkpoint data, boards, demos, burn/flow metrics, risk and issue updates | If work is off track but within tolerance, take corrective action without escalation |
| Managing Product Delivery | Team accepts, executes, and delivers Work Packages | Use timeboxes, Definition of Done, team planning, reviews, quality checks | If team cannot meet a Work Package agreement, forecast impact and inform PM |
| Managing a Stage Boundary | Review stage and seek authorization for next stage | Update Business Case, plans, backlog, risks, Agilometer view, lessons | If learning changes viability, revise Business Case before asking for next stage |
| Closing a Project | Confirm acceptance and close in controlled way | Ensure final/partial product acceptance, handover, support, benefits review planning, lessons | Do not skip closure just because delivery was iterative |
PRINCE2 practices quick reference
Current PRINCE2 materials use practices; some candidates may also see older references to themes. The exam logic is the same: apply the management discipline in an agile context.
| Practice | Agile application | Key artefacts/evidence | Common trap |
|---|
| Business Case | Validate value continuously; use early releases and feedback to test assumptions | Business Case, benefits measures, MVP/MMP evidence, reviews | Continuing with low-value features because they are in the original scope |
| Organizing | Clarify governance vs delivery roles | Role descriptions, stakeholder map, communication approach, working agreements | Role confusion between PM, Product Owner, Scrum Master, Senior User |
| Plans | Use product-based planning plus rolling-wave detail | Project Plan, Stage Plan, release plan, iteration plan, backlog | Creating a detailed sprint-level plan for the whole project too early |
| Quality | Define “done” and acceptance clearly | Product Descriptions, quality criteria, acceptance criteria, Definition of Done, test results | Trading quality for extra scope |
| Risk | Use agile feedback to expose and reduce uncertainty | Risk register, spikes, prototypes, risk burndown, experiments | Believing agile means risk documentation is unnecessary |
| Issues | Control changes, off-specifications, problems, and requests | Issue register, backlog changes, impact assessments, Change Authority decisions | Treating all backlog changes as informal team decisions |
| Progress | Use PRINCE2 tolerances plus agile metrics | Highlight Reports, Checkpoint Reports, boards, burn charts, cumulative flow | Reporting only sprint velocity as project health |
Planning horizons and controls
| Horizon | Typical owner | Content | Agile control point |
|---|
| Project | Project Manager with Project Board direction | Overall justification, major products, stages, costs, tolerances | Business Case and project tolerances |
| Stage | Project Manager | Products and controls for next management stage | Authorization at stage boundaries |
| Release | PM, Product Owner/product representative, team | Candidate features, release goals, dependencies, target date | Scope negotiation and benefit delivery |
| Iteration/sprint | Delivery team with product representative | Selected backlog items, tasks, quality work | Team commitment/forecast within timebox |
| Daily flow | Delivery team | Work in progress, blockers, immediate coordination | Stand-ups, boards, WIP limits, impediment removal |
Forecasting aid:
\[
\text{Forecast iterations} = \frac{\text{remaining estimated work}}{\text{average completed work per iteration}}
\]
Use velocity or throughput as planning evidence, not as a guarantee. Practitioner answers should avoid treating estimates as commitments when uncertainty remains.
Work package, backlog, and product baseline distinctions
| Item | Purpose | Agile equivalent or supplement | Exam distinction |
|---|
| Project Product Description | Defines the final project product and acceptance | Product vision, high-level acceptance | Used for overall acceptance, not sprint task detail |
| Product Description | Defines a product’s quality criteria and acceptance method | Epic/story acceptance criteria may support it | More formal baseline than a casual backlog note |
| Work Package | Agreement between PM and team for product delivery | Sprint/release scope may form part of it | Team must know constraints, quality, reporting, and tolerances |
| Product backlog | Ordered list of desired work | User stories, defects, enablers, technical work | Dynamic; not every item is committed scope |
| Sprint/iteration backlog | Work selected for a timebox | Tasks/stories for current iteration | Managed by delivery team, not Project Board |
| Definition of Done | Shared quality completion standard | Testing, review, documentation, integration criteria | Applies broadly to completed work |
| Acceptance criteria | Conditions for accepting a specific story/product | Given/when/then examples, test cases | Specific to item/product; not the same as Definition of Done |
| Configuration item record | Tracks controlled product versions/status | Repository metadata, tool records | Agile tooling does not remove configuration management |
Change and prioritization decision table
| Scenario | Best PRINCE2 Agile response |
|---|
| New requirement appears during delivery | Capture it, assess impact, prioritize against existing backlog, decide within delegated authority |
| New item can fit by dropping lower-priority scope within tolerance | Reprioritize backlog and update plans; no exception needed |
| New item threatens stage/project tolerance | Raise issue/Exception Report according to controls |
| Stakeholder says everything is “Must have” | Challenge prioritization; identify minimum viable/acceptable outcome |
| User feedback changes understanding of value | Update backlog and Business Case assumptions; do not treat learning as failure |
| Regulatory/safety/mandatory quality criterion appears | Treat as constraint/quality requirement; do not trade it away casually |
| Supplier proposes cutting tests to meet date | Reject as quality compromise; consider descoping lower-value features |
| Product Owner wants to add work mid-sprint | Apply team’s agreed change approach; protect focus unless urgent and authorized |
MoSCoW prioritization reference
| Priority | Meaning | Exam caution |
|---|
| Must have | Essential for viable/acceptable delivery | Too many Musts remove agility |
| Should have | Important but a workaround or delay is acceptable | Good candidate for trade-off if time is tight |
| Could have | Desirable if capacity remains | Often descoped first |
| Won’t have this time | Explicitly excluded from current scope/timeframe | Does not always mean “never” |
MoSCoW is most useful when tied to timeboxes, releases, benefits, and tolerances. It is weak if used only as a label without real trade-off decisions.
Quality: high-yield distinctions
| Concept | Meaning | Agile use | Trap |
|---|
| Quality criteria | Measurable attributes a product must meet | Included in Product Descriptions and acceptance | Vague criteria cause disputes |
| Quality tolerance | Permitted variation in quality criteria | Defines acceptable range, not permission for poor quality | Expanding tolerance just to pass unfinished work |
| Acceptance criteria | Conditions for accepting a story/product | Clarify expected behaviour and tests | Confusing with broad Definition of Done |
| Definition of Done | Common completion standard | Applies to increments/stories across the team | Changing it secretly to meet a deadline |
| Quality control | Testing/reviewing products | Automated tests, peer review, demo evidence | Leaving testing until project end |
| Quality assurance | Independent check that process is suitable | Project Assurance, audits, standards checks | Assuming self-organizing teams need no assurance |
| Technical debt | Future cost from suboptimal technical choices | Make visible, prioritize, manage risk | Hiding debt to show artificial progress |
Reporting and progress evidence
| Evidence | Shows | Use carefully because |
|---|
| Highlight Report | Stage/project status for Project Board | Should summarize, not duplicate team boards |
| Checkpoint Report | Team progress to Project Manager | Can reference agile metrics and blockers |
| Burn-down chart | Work remaining over time | Can hide scope changes if not interpreted carefully |
| Burn-up chart | Work completed and total scope | Better for showing changing scope |
| Cumulative flow diagram | Flow, WIP, bottlenecks | Needs stable workflow states to be meaningful |
| Velocity | Average completed work per iteration | Not comparable across teams; not a productivity target |
| Lead time | Time from request to delivery | Useful for flow-based/Kanban contexts |
| Cycle time | Time from work start to completion | Useful for process improvement |
| Escaped defects | Defects found after release/acceptance | Strong quality and risk signal |
| Demo/review feedback | Product fitness and stakeholder alignment | Feedback must be translated into controlled decisions |
Agile method selection cues
PRINCE2 Agile is method-neutral. It can work with several agile approaches.
| Agile approach | Key features | When it fits | Practitioner caution |
|---|
| Scrum | Sprints, Product Backlog, Sprint Review, Retrospective, Scrum Master, Product Owner | Product development with regular inspect/adapt cycles | Scrum events do not replace PRINCE2 governance |
| Kanban | Visual workflow, WIP limits, pull system, flow metrics | Support, service, continuous flow, variable work arrival | A board alone is not Kanban discipline |
| Lean Startup | Build-measure-learn, MVP, validated learning | High uncertainty, product discovery, hypothesis testing | MVP must still meet agreed quality constraints |
| XP/engineering practices | TDD, CI, refactoring, pair/mob work | Technical quality, software delivery, fast feedback | Technical practices support quality but do not define project governance |
| Hybrid delivery | Mix of predictive and agile elements | Fixed external constraints plus areas of uncertainty | Tailoring must be deliberate, not accidental inconsistency |
“What should the manager do next?” reference
| Situation | Usually do next | Do not jump to |
|---|
| Team reports blocker within Work Package tolerance | Help remove impediment or agree corrective action | Project Board escalation |
| Forecast shows stage tolerance will be exceeded | Prepare Exception Report and seek Project Board decision | Quietly absorb the variance |
| Sprint goal at risk but stage tolerance unaffected | Reprioritize, descope lower-value work, communicate | Extend sprint automatically |
| User unavailable for reviews | Treat as collaboration risk/issue; involve Senior User | Let team guess requirements indefinitely |
| Backlog is growing rapidly | Reassess prioritization, scope tolerance, Business Case impact | Add all items to committed scope |
| Quality checks failing | Fix quality issue, reassess plan/scope | Accept lower quality to protect velocity |
| Agile team wants less reporting | Tailor reports to be lightweight and useful | Remove progress controls completely |
| Board wants daily task detail | Provide appropriate summary and evidence | Undermine team self-organization |
| Benefits assumptions invalidated | Update Business Case and options | Continue because sunk cost is high |
| Supplier says agile means no fixed plan | Use rolling-wave planning with agreed tolerances | Accept absence of plan or controls |
Exception and escalation logic
| Condition | Within tolerance? | Proper response |
|---|
| Team swaps Could-have item for another Could-have item | Usually yes | Update backlog/release plan; communicate as agreed |
| Must-have item cannot be delivered in current release | Maybe no | Assess impact on viability, benefits, stage tolerance |
| Quality criterion cannot be met | Often no | Raise issue; assess options; do not hide |
| Cost/time forecast exceeds stage tolerance | No | Exception Report to Project Board |
| Product Owner reprioritizes within delegated authority | Yes | Record/update backlog; no board escalation |
| Change affects Business Case materially | No or likely no | Escalate through issue/change control |
| Risk exposure exceeds tolerance | No | Escalate per risk management approach |
Common Practitioner exam traps
| Trap | Better answer |
|---|
| “Agile means no documentation.” | Documentation is tailored to be sufficient and useful. |
| “The Project Manager controls sprint tasks.” | The team self-organizes within agreed Work Package/tolerances. |
| “The Product Owner is the Project Board.” | Agile delivery roles may support PRINCE2 roles but do not automatically replace them. |
| “Velocity proves the project is healthy.” | Use velocity with quality, scope, risk, benefits, and tolerance data. |
| “All change is good.” | Change is welcomed but assessed, prioritized, and controlled. |
| “Quality can flex if time is fixed.” | Scope flexes first; quality is protected. |
| “Every sprint needs a PRINCE2 stage boundary.” | Stage boundaries are governance points and should be tailored. |
| “A demo equals formal acceptance.” | Demo feedback may support acceptance, but acceptance must follow agreed criteria and authority. |
| “Agile removes need for Business Case.” | Agile gives earlier evidence to validate or challenge the Business Case. |
| “Information radiators replace reports.” | They can supply evidence, but reporting must meet governance needs. |
Last-minute review checklist
Before practice questions, confirm you can:
- Explain how PRINCE2 governance and agile delivery coexist.
- Identify which PRINCE2 role should make a decision.
- Distinguish Project Board direction from delivery-team self-organization.
- Apply manage by exception using tolerances.
- Choose scope trade-offs before time, cost, or quality compromises.
- Recognize when a backlog change is routine and when it is an issue/exception.
- Use the Agilometer to guide tailoring and risk responses.
- Match Product Descriptions, Work Packages, backlogs, and Definition of Done to the right purpose.
- Interpret agile metrics without overclaiming certainty.
- Protect continued business justification throughout iterative delivery.
Practical next step
Use this Quick Reference to drill scenario questions: for each question, identify the PRINCE2 process, the relevant practice, the tolerance position, the role with authority, and the agile tailoring decision before choosing an answer.