AgilePM Foundation common mistakes
AgilePM Foundation · Understand the traps and how to avoid them.
Treating DSDM/AgilePM as a 'no planning, no documentation' method and answering that plans, governance and defined products are unnecessary.
Candidates carry generic 'agile means lightweight' assumptions from Scrum or the Agile Manifesto's 'working software over documentation' and map them onto AgilePM, which is explicitly a structured, governance-heavy method.
What to do instead
Memorise AgilePM's founding principles: it is a 'pragmatic, scalable, proven' method that keeps fixed-point governance, defined roles and defined products while embracing iterative delivery. When a question offers 'no documentation/planning' as an option, treat it as a distractor.
Confusing the AgilePM lifecycle phases (Pre-Project, Feasibility, Foundations, Evolutionary Development, Deployment, Post-Project) with the DSDM/Scrum concepts of sprints or with PRINCE2 stages.
Multiple methodologies use similar-sounding stage names; candidates blur 'Foundations' with 'initiation' or assume Evolutionary Development is a single iteration.
What to do instead
Learn the phase sequence and the purpose of each: Feasibility (is it worth doing?), Foundations (establish the baseline and team), Evolutionary Development (iterative build and demonstrate), Deployment (assemble, test, release). Remember Evolutionary Development contains multiple timeboxes.
Mixing up the three AgilePM roles sets - project-level roles (Business Sponsor, Business Visionary, Technical Coordinator, Project Manager), solution development roles (Team Leader, Business Ambassador, Solution Developer, Solution Tester, Business Advisor), and supporting roles (Business Analyst, Workshop Facilitator, DSDM Coach) - and assigning responsibilities to the wrong level.
The role model is large and layered; candidates memorise role names without anchoring each to its level or to the products it owns.
What to do instead
Build a role-to-level-to-product map. For each role, learn one signature responsibility (e.g., Business Sponsor owns the Business Case; Business Visionary owns the Vision; Technical Coordinator owns the Solution Architecture Definition; Team Leader owns the team's work). Test yourself by asking 'which level owns this product?'
Treating MoSCoW as a simple priority ranking and answering that 'Could' requirements may be dropped without consequence, or that 'Must' items can be traded between timeboxes.
Candidates apply everyday meaning of 'must/could' rather than AgilePM's specific rules: Musts are non-negotiable for the project's viability, Shoulds are important but workaround-able, Coulds are nice-to-have, and Won'ts are explicitly out of scope for this timebox.
What to do instead
Learn each MoSCoW level's precise definition and the constraint that Musts typically should not exceed ~60% of effort. Remember MoSCoW is applied per timebox and protects the fixed time and fixed quality by flexing scope.
Misidentifying which elements are 'fixed' versus 'flexed' in AgilePM's fixed-point approach - e.g., stating that time and cost can flex while scope is fixed, or that quality is negotiable.
Traditional project thinking fixes scope and flexes time/cost; AgilePM inverts this, and candidates revert to the familiar model under exam pressure.
What to do instead
Memorise the fixed point: time, cost and quality are fixed; scope is flexed via MoSCoW prioritisation. Any option that flexes time, cost or quality while fixing scope is wrong.
Confusing which products are created in which phase or which product is a 'timebox' product versus a 'project' product - e.g., placing the Business Case only in Feasibility, or treating the Prioritised Requirements List as a Foundations-only artefact.
Products are introduced, baselined and evolved across phases, and candidates learn product names without learning their lifecycle.
What to do instead
For each key product (Business Case, Vision, Prioritised Requirements List, Solution Architecture Definition, Delivery Plan, Timebox Plan, Timebox Review Record, Benefits Assessment), note where it is created, where it is baselined, and where it is updated. Use a phase-by-product grid as a revision aid.
Describing a timebox as a single meeting or a fixed-length phase without its internal structure (kick-off, investigation, refinement, consolidation, close-out) and without the daily stand-up and review.
Candidates map 'timebox' onto 'sprint' and assume it is just a development block; the internal ceremony structure is easy to skip when revising.
What to do instead
Learn the timebox structure and what happens in each part, plus the products produced (Timebox Plan at kick-off, Timebox Review Record at close-out). Remember the daily stand-up and the demonstration at the end.
Confusing the roles of the Business Analyst, Workshop Facilitator and DSDM Coach, or assuming they are core delivery roles rather than supporting roles.
These supporting roles have overlapping-sounding names and candidates assign them delivery or management duties they do not hold.
What to do instead
Anchor each: Business Analyst supports requirements and business understanding; Workshop Facilitator runs facilitated workshops; DSDM Coach mentors the team on the method. Learn they are supporting, not decision-making, roles.
Answering that the Project Manager makes business decisions or owns the Business Case, rather than the Business Sponsor (with the Business Visionary owning the Vision).
Candidates import a traditional PM-as-owner model and overlook AgilePM's separation of business, technical and management accountability.
What to do instead
Memorise the accountability split: Business Sponsor owns the Business Case and business decision-making; Business Visionary owns the Vision and business direction; Technical Coordinator owns technical coherence; Project Manager owns delivery management and plans. Match the product to the role that owns it.
Treating the AgilePM principles as optional 'nice-to-haves' or as a checklist to be applied selectively, and failing questions that test whether a practice violates a principle.
Candidates learn the principle names but not how they constrain behaviour, so they cannot spot a scenario that breaches a principle.
What to do instead
Learn the eight principles (e.g., focus on the business need, deliver on time, collaborate, never compromise quality, build incrementally from firm foundations, develop iteratively, communicate continuously and clearly, demonstrate control) and practise scenario questions by asking 'which principle does this behaviour support or violate?'