AgilePM Practices
AgilePM's practices are the techniques that make the principles work in daily delivery. Foundation questions test the mechanics of each practice and the vocabulary around it.
MoSCoW prioritisation
Requirements are ranked Must Have, Should Have, Could Have, and Won't Have this time. The rule that examiners love: Must Haves should not exceed 60% of the effort in a timebox, and contingency should be at least 20%. Should and Could Haves are the contingency. A trap is being told that "Won't Have" means the requirement will never be built - it means not in this timeframe.
Timeboxing
A timebox is a fixed period with a fixed end date. The three types are Daily Timebox, Iteration (typically 2–4 weeks), and Deployment (a timebox that delivers into operational use). The Timebox Plan is agreed at the start; scope flexes, not the date.
Modelling, Iterative Development, and Workshops
Modelling keeps artefacts just sufficient and fit for purpose. Iterative Development builds the solution incrementally, informed by feedback. Facilitated Workshops are the preferred collaborative technique and are run by the Workshop Facilitator.
Testing and estimating
Testing is integrated throughout, not bolted on at the end. Estimating can use techniques like Planning Poker, but AgilePM stresses that estimates are refined iteratively.
Worked example
A timebox has 100 effort-days. How much may be Must Have? 60 days, with 20 days contingency and 20 days for Should/Could. If a question offers 70% Must Have, it breaches the guidance.
Rule of thumb: if it isn't a Must Have, it's contingency - and contingency protects the fixed date.
Phases, Processes and the AgilePM Lifecycle
This domain ties the phases to the processes and the products they create, and questions here often test sequencing and decision points.
The phases in order
Pre-Project confirms the project is worth starting and produces the Project Mandate and Terms of Reference. Feasibility tests whether the project is feasible and produces a Feasibility Assessment and outline Business Case; the key decision is whether to proceed to Foundations. Foundations establishes a firm, stable base: the Business Case is refined, the Project Plan and Solution Foundations are produced, and the Management Approach is agreed. Evolutionary Development is the only repeating phase, containing Deployment (delivering increments into use) and Engineering (building and testing). Post-Project confirms benefits and closes the project.
Processes
The high-level processes include Project Planning, Control, and the timebox processes (Planning, Review, Retrospective). The Timebox Review demonstrates the increment to stakeholders; the Retrospective captures lessons learned at the end of a timebox.
Traps
A very common trap is thinking Evolutionary Development happens once - it repeats. Another is confusing the Feasibility decision point with the Foundations decision point; Foundations ends with the project being formally confirmed. Also, Post-Project is about confirming benefits, not building more solution.
Worked example
Question: "In which phase is the Business Case refined to include the detailed costs and benefits?" Feasibility produces only an outline; refinement happens in Foundations. Answer: Foundations.
Rule of thumb: Feasibility asks "can we?", Foundations asks "how, and are we sure?", Evolutionary Development asks "build and deliver it".