AgilePM Practitioner common mistakes
AgilePM Practitioner · Understand the traps and how to avoid them.
Answering Practitioner-level scenario questions by picking the option that restates the definition of a concept (e.g. 'a timebox is a fixed period') rather than the option that applies the concept to the given situation.
Candidates revise Foundation-style definitions and then treat every question as a recall test, even though the Practitioner paper presents a scenario and asks what the practitioner should do or which product/action fits.
What to do instead
Before selecting, identify what the question is actually asking (define, apply, evaluate). If the stem contains a scenario, eliminate any option that is merely a textbook definition and choose the one that changes the outcome in that scenario.
Assigning responsibilities to the wrong role, e.g. giving the Project Manager ownership of the Business Case or letting the Team Leader set priorities, instead of mapping each product and decision to its single accountable role.
AgilePM deliberately splits accountabilities across business, management and technical roles (and across the three levels), and candidates conflate them with generic agile or PRINCE2 role models they already know.
What to do instead
Build a role-to-product matrix from memory (Business Sponsor owns the Business Case, Business Visionary owns the Vision, Project Manager owns the Project Plan and manages the timeboxes, Team Leader leads the DSDM team, Solution Development Team self-organises on detail) and test each option against 'who is accountable for this product/decision?'.
Choosing an option that has the team work out high-level scope and architecture in detail during Foundations, or that pushes detailed requirements into Feasibility, rather than keeping each phase at its intended level of detail.
Candidates remember 'enough design up front' but not how much is enough at each phase, and the options are written so that over-elaboration looks thorough and therefore correct.
What to do instead
Memorise the phase purpose and exit products: Feasibility produces the Business Case and outline solution; Foundations produces the Foundations Summary (business, solution and management foundations) at a sufficient level; detail is deliberately deferred to Evolutionary Development. Reject options that add detail earlier than its phase.
Treating the products as a flat checklist and misplacing which are created in which phase or which are baselined/configuration-controlled versus working documents, so questions about 'which product is produced in Foundations' or 'what is baselined' are answered by guesswork.
There are many products with similar names (e.g. Business Case vs Benefits Realisation Plan, Prioritised Requirements List vs Solution Definition) and candidates learn names without learning phase, owner and purpose.
What to do instead
For each product learn three attributes: phase produced, owning role, and purpose. Group them by phase in a table and rehearse 'produced in Feasibility / Foundations / Evolutionary Development / Deployment'. This lets you eliminate options on phase alone.
Answering timebox questions with a generic 'iterate until done' answer instead of applying the fixed-length, fixed-team, variable-scope principle, e.g. accepting an option that extends the timebox to finish planned scope.
Candidates carry over habits from other agile frameworks where scope is fixed per sprint and time can flex, and the AgilePM inversion (fix time and resources, flex scope via MoSCoW) is easy to state but hard to apply under exam pressure.
What to do instead
Anchor every timebox answer on: length is fixed, team size is fixed, MoSCoW protects the Musts, and if work will not fit the lowest-priority Coulds are dropped first. Any option that moves the end date or adds people to finish scope is wrong.
Applying MoSCoW incorrectly: making everything a Must, treating Should as optional, or failing to recognise that Musts must be deliverable within the timebox and that Coulds are the contingency.
MoSCoW looks simple, so candidates answer from everyday English usage ('should' sounds optional) rather than the AgilePM definition where Shoulds are important but can be traded if the Musts are at risk, and Coulds are the first to go.
What to do instead
Learn the definitions precisely: Must = must be delivered for the timebox to be acceptable and must be achievable; Should = important, painful to leave out but the solution is still viable; Could = desirable, dropped first; Won't = explicitly out of scope this time. Reject any option that makes all requirements Musts or that sacrifices a Must.
Confusing the three facilitator/workshop techniques (facilitated workshops, modelling, iterative development) and the supporting practices, or picking 'facilitated workshop' as the answer whenever collaboration is mentioned rather than when a structured, facilitated group session is genuinely needed.
The techniques are taught together and all sound collaborative, so candidates pattern-match on words like 'workshop' or 'collaboration' instead of matching the technique to the stated purpose.
What to do instead
Learn each technique's distinct purpose: facilitated workshops bring stakeholders together to reach a defined outcome quickly; modelling builds a shared, testable representation; iterative development refines through repeated cycles. Match the technique to the outcome described in the stem, not to a keyword.
Ignoring the 'tailoring' instruction embedded in Practitioner scenarios and answering as if the full AgilePM framework must always be applied, e.g. insisting on all products and both Project Manager and Team Leader roles in a small, co-located project.
Candidates learn the full framework and treat deviation as non-compliance, missing that AgilePM explicitly expects the framework to be scaled and that some products/roles can be combined or lightened with justification.
What to do instead
When a stem describes project size, culture, distribution or risk, look for the option that scales the framework proportionately and keeps the principles intact. Prefer options that combine roles or simplify products with a stated rationale over options that add ceremony.
Selecting answers that violate an AgilePM principle (e.g. 'never compromise on quality', 'demonstrate control', 'collaborate', 'focus on the business need') in order to satisfy a stated constraint, such as agreeing to cut testing to hit a date.
Scenario stems are written so that one option looks pragmatic and decisive, and candidates reward pragmatism over principle, forgetting that principles are non-negotiable and override convenient options.
What to do instead
Use the eight principles as a filter: any option that compromises quality, removes stakeholder collaboration, or delivers without demonstrating control is wrong regardless of how practical it sounds. Check the surviving options against the business need and the fixed timebox.
Misreading questions about control points and governance (e.g. what happens at the end of a timebox, when the Project Manager escalates, or the role of the Business Sponsor at gates) and answering with a generic 'review progress' response.
Governance questions are worded abstractly and candidates answer at the level of 'the PM monitors' instead of naming the specific control action, product or decision point involved.
What to do instead
Learn the control cycle concretely: each timebox ends with a review of what was delivered and a decision on the next timebox; tolerances are set by the Business Sponsor and the Project Manager escalates only when they are forecast to be breached; gates confirm continued business justification. Choose the option that names the specific control action and accountable role.