PRINCE2 Agile Practitioner common mistakes
PRINCE2 Agile Practitioner · Understand the traps and how to avoid them.
Treating PRINCE2 Agile as a choice between 'doing PRINCE2' or 'doing agile', and answering scenario questions by recommending one instead of the other.
Candidates learn the two bodies of knowledge separately and never internalise that PRINCE2 Agile is a single integrated method where agile behaviours and techniques are embedded into the themes and processes.
What to do instead
For every scenario, ask 'which PRINCE2 management product or theme does this agile activity serve?' and practise mapping each technique (e.g. timeboxing, retrospectives, Kanban) to the theme or process it supports, so answers describe integration rather than substitution.
Assuming PRINCE2 Agile means agile can only be used at delivery level while the project stays fully predictive above it.
Candidates over-apply the 'PRINCE2 for governance, agile for delivery' shorthand and miss that agile behaviours are expected across the whole project, including the board's style and the project manager's approach.
What to do instead
Learn the distinction between where agile is applied (the delivery and its surrounding behaviours) and where PRINCE2 controls remain, and practise identifying agile behaviours expected of the project board and project manager, not just the delivery team.
Answering 'agile behaviour' questions with process steps, e.g. recommending a retrospective or a daily stand-up when the question asks how the project manager should behave.
Candidates conflate the techniques that embody agile with the behaviours themselves, so they pick a ceremony instead of describing transparency, collaboration, willingness to adapt, or servant leadership.
What to do instead
Read the question stem for behaviour verbs ('should the project manager do', 'how should the team respond') and select the option describing a mindset or interpersonal action; reserve ceremony-based answers for questions explicitly about techniques or events.
Choosing autocratic or directive options in scenarios involving self-organising teams, or escalating to the board decisions the team is empowered to make.
Candidates import habits from predictive project management where the project manager assigns work and controls detail, and they underweight the principle that teams self-organise within agreed tolerances.
What to do instead
Apply the test 'is this within the team's agreed boundaries and tolerances?' If yes, the correct answer usually has the project manager enabling, removing impediments, or asking the team to decide, and escalating only when tolerances are threatened.
Treating PRINCE2 principles as things that can be tailored away or traded off when agile is used.
Candidates see tailoring as 'adapt everything' and do not register that principles are the non-negotiable foundation; only the themes, processes, roles and management products are tailored.
What to do instead
Memorise the principle that principles are applied but never tailored, and in tailoring questions check whether the proposed change alters a principle (wrong) or merely changes how a theme or process is implemented (acceptable).
Tailoring by deleting themes or processes rather than scaling how they are applied.
Candidates equate a small or agile project with 'we don't need that theme', forgetting that all seven themes must still be applied and each process still needs its activities addressed.
What to do instead
For any tailoring scenario, state how each theme is still addressed (often more lightly or using agile artefacts) and how each process activity is satisfied, rather than which ones are dropped.
Confusing the management products and their agile equivalents, e.g. treating a product backlog as a replacement for the product description, or a sprint backlog as the stage plan.
Candidates learn both vocabularies but not the mapping, so they misidentify which PRINCE2 product an agile artefact informs or updates.
What to do instead
Build a mapping table linking each agile artefact to the PRINCE2 product it feeds (e.g. backlog items to product descriptions, team plan to sprint/iteration plan, daily progress to checkpoint reporting) and test yourself on 'which PRINCE2 product does this update?'
Applying AgileSHAPE (or agile health-check concepts) as if they were the PRINCE2 Agile delivery method, or using AgileSHAPE terminology in a PRINCE2 project scenario.
Candidates blur the distinct products in the syllabus and answer with the wrong framework's vocabulary when a question is scoped to one of them.
What to do instead
Anchor each framework to its purpose and scope: identify from the question stem which framework is in play, then use only that framework's terms and structures in the answer.
Misapplying the focus areas, e.g. treating 'flexibility' as licence to change scope freely, or 'rich communication' as more documentation.
Candidates remember the names of the focus areas but not their precise intent, so they pick plausible-sounding but incorrect interpretations.
What to do instead
Learn each focus area with a one-line definition and a concrete example of correct and incorrect application, and in scenario questions check whether the option genuinely reflects that focus area's intent rather than a loose association.
Using health checks as a pass/fail audit or as a substitute for the end-stage assessment, and ignoring the actions that should follow a health check.
Candidates treat health checks like a gate review and miss that they are lightweight, ongoing assessments intended to prompt improvement actions rather than approve or reject a stage.
What to do instead
Frame health checks as continuous self-assessment feeding improvement actions, distinguish them from stage boundary and end-project activities, and in questions look for the option that uses the results to adapt behaviour rather than to grant or withhold approval.