Overview
Planning and control explains how an agile project can be both flexible and well governed. AgilePM plans at several levels: a high-level plan for the whole project, created in Foundations and showing increments and their timing; increment-level plans; and detailed plans for each timebox or Sprint, made by the team doing the work. Plans firm up as the project learns, so near-term work is detailed while later work stays deliberately coarse.
Control comes from fixed timeboxes, visible progress measured by delivered products, and management by exception: the team and Project Manager act freely within agreed tolerances and escalate only when a forecast says a tolerance will be breached. Change is expected and handled by reprioritising within the fixed timebox rather than by extending it. In AgilePM v3 this planning is integrated with Scrum: Sprints are the timeboxes, and Scrum events and artefacts supply the detailed planning and inspection.
How it's tested
Questions describe a planning or progress situation and ask what should happen: who plans at which level, how to respond when a timebox is at risk, whether a deviation needs escalation, or how AgilePM planning lines up with a Scrum event. Look for the stated tolerances and whether the timebox end date is under threat.
-
Late work in a timebox
Work will not all be finished by the end of a timebox or Sprint and you choose the AgilePM response, which flexes scope rather than time.
-
Escalate or not
A deviation is described with tolerances, and you decide whether the team handles it or escalates as an exception.
-
Planning levels and Scrum alignment
You identify who plans at a given level, how detailed a plan should be, or which Scrum event or artefact performs an AgilePM planning function.
A question says the team forecasts it can meet an increment's deadline only by dropping some Could Haves, and the agreed tolerances allow this. Escalating to the Business Sponsor is tempting because scope changes. But management by exception means acting within tolerances without escalation, keeping the change visible in the plan. Escalate only when a forecast exceeds tolerance, such as losing Must Haves or missing the date.
Syllabus topics 3
Official syllabus topics from the APMG International outline, in outline order.
8.1 AgilePM planning concepts and planning across the lifecyclePlanning at project, increment and timebox levels, firming up over time.
- What it means
- AgilePM plans at several levels: a high-level delivery plan for the project from Foundations, increment plans, and detailed timebox or Sprint plans. Planning is based on delivering prioritised outcomes within fixed timeboxes, and is refined as knowledge grows.
- What to understand
- Detailed planning is done close to the work by the people doing it, while the Project Manager leads project-level planning. Early plans are deliberately coarse and gain detail over time; that is not a lack of planning but planning matched to what is known.
- How it shows up
- You choose who produces a plan at a given level, or how much detail a plan should hold at a given point in the lifecycle.
- Common confusion
- Believing agile projects plan only one Sprint ahead; AgilePM always has a project-level plan with increments and dates.
8.2 Tracking progress, responding to change and management by exceptionVisible progress, change through reprioritisation, and escalation only beyond tolerances.
- What it means
- Progress is tracked by completed, working products, often on burn-down or burn-up charts and task boards. Change is absorbed by reprioritising requirements within fixed timeboxes. Management by exception means each level works within agreed tolerances on time, cost and scope and escalates only when those tolerances are forecast to be exceeded.
- What to understand
- Tolerances let decisions be taken at the lowest sensible level and keep senior roles focused on real exceptions. Timeboxes are not extended; when work runs short of time, lower-priority items are deferred and the date holds.
- How it shows up
- A deviation is described and you decide whether the team handles it within tolerance or escalates it as an exception.
- Common confusion
- Escalating every change to governance, or extending a timebox to absorb late work.
8.3 Integrating AgilePM planning with Scrum events and artefactsSprints as timeboxes and Scrum events as the detailed planning and inspection points.
- What it means
- In AgilePM v3, delivery teams plan and inspect detailed work through Scrum: Sprints act as the timeboxes, Sprint Planning creates the Sprint Goal and Sprint Backlog, the Daily Scrum adapts the day's plan, and the Sprint Review inspects progress and updates the Product Backlog.
- What to understand
- AgilePM's project and increment plans set the Sprint boundaries, priorities and Must Haves; Scrum handles the detailed planning inside each Sprint. Forecasts from team velocity feed back into the project-level plan.
- How it shows up
- You match an AgilePM planning or control need, such as checking progress against the increment plan, to the Scrum event or artefact that serves it.
- Common confusion
- Assuming Sprint Planning replaces the project-level plan, or that AgilePM adds separate meetings that duplicate Scrum events.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Timeboxing
Work is organised into fixed periods with a fixed end date, and the scope delivered in each varies according to MoSCoW priority.
- Remember
- The end date of a timebox is never moved; scope flexes instead.
- Tested as
- The default answer when work in a timebox runs late.
- Trap
- Extending the timebox by a few days.
-
Planning levels
AgilePM plans at project level (from Foundations), increment level and timebox or Sprint level, with detail increasing as work gets closer.
- Remember
- Coarse long-range plans plus detailed near-term plans.
- Tested as
- Questions on who plans what and in how much detail.
- Trap
- Detailing every Sprint of the project in Foundations.
-
Who plans
The Project Manager leads project-level planning with the team's input, while the delivery team plans the detailed work of each Sprint.
- Remember
- Those who do the work plan the detail.
- Tested as
- Role and planning questions.
- Trap
- Having the Project Manager plan individual tasks.
-
Tolerances
Agreed limits on deviation in time, cost and scope within which a level of the project can act without escalating.
- Remember
- Tolerances define the boundaries of empowerment.
- Tested as
- Escalation questions.
- Trap
- Treating any deviation, even within tolerance, as an exception.
-
Management by exception
Each level manages within its tolerances and escalates only when a forecast shows a tolerance will be exceeded.
- Remember
- Escalate forecasts of breach, not every change.
- Tested as
- Escalate-or-not scenarios.
- Trap
- Escalating dropped Could Haves that are within tolerance.
-
Progress measured by delivered products
Progress is judged by completed, working output, not by effort spent or percentage-complete estimates.
- Remember
- Done is binary; partly done is not progress you can bank.
- Tested as
- Progress-tracking questions.
- Trap
- Reporting partially finished work as progress.
-
Burn-down and burn-up charts
Burn-down charts show remaining work over time; burn-up charts show completed work against total scope, making scope changes visible.
- Remember
- Burn-up shows scope change explicitly; burn-down shows remaining work.
- Tested as
- Tracking questions.
- Trap
- Assuming a burn-down chart reveals added scope clearly.
-
Velocity and forecasting
The amount of work a team typically completes per Sprint, used to forecast how much of the prioritised backlog fits in the remaining timeboxes.
- Remember
- Velocity is a team's planning aid, not a performance target.
- Tested as
- Questions linking Sprint data to project-level plans.
- Trap
- Comparing velocity across teams as a productivity measure.
-
Responding to change through reprioritisation
New or changed requirements are absorbed by reprioritising the backlog with MoSCoW, so higher-value work displaces lower-priority work within the fixed timebox.
- Remember
- Change is welcomed, but it displaces something rather than extending the date.
- Tested as
- Change-handling scenarios.
- Trap
- Adding new work without removing anything.
-
Sprint as timebox
In AgilePM v3 the Scrum Sprint is the timebox in which delivery teams build the solution, with Sprint events providing planning and inspection.
- Remember
- AgilePM plans set Sprint priorities; Scrum plans the detail.
- Tested as
- Integration questions.
- Trap
- Adding AgilePM meetings that duplicate Scrum events.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Within tolerance vs. exception
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Within tolerance | Forecast deviation stays inside agreed limits | The team or Project Manager decides and keeps it visible | Escalating it anyway |
| Exception | Forecast shows a tolerance will be exceeded | Escalated to the next level with options | Hiding it until the deadline is missed |
Burn-down vs. burn-up charts
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Burn-down | Remaining work plotted over time | Simple trend toward zero | Scope added mid-way can mask progress |
| Burn-up | Completed work against a total scope line | Scope changes appear as a moving top line | Thinking it hides scope change |
AgilePM planning vs. Scrum planning
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| AgilePM project and increment plans | Increments, Sprint boundaries, priorities and dates | Project level, led by the Project Manager | Thinking Scrum makes them unnecessary |
| Scrum Sprint Planning | Sprint Goal and Sprint Backlog for one Sprint | Team level, done by the Scrum Team | Expecting the Project Manager to run it |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Extend the timebox
- What candidates pick
- Add a few days to the Sprint so the planned items can be completed.
- Why it looks right
- It appears to protect the scope with a small change.
- Why it's wrong
- Timeboxes have fixed end dates; unfinished lower-priority items are deferred and the next timebox starts on time.
Clue to watch for Late work near the end of a timebox.
-
Escalate everything
- What candidates pick
- Report dropping two Could Haves to the Business Sponsor for approval.
- Why it looks right
- It feels transparent and safe.
- Why it's wrong
- Within tolerances, the team and Project Manager decide; management by exception reserves escalation for forecast breaches.
Clue to watch for The scenario states the change is within agreed tolerances.
-
No long-range plan
- What candidates pick
- Plan one Sprint at a time and avoid any project-level plan.
- Why it looks right
- It sounds maximally adaptive.
- Why it's wrong
- AgilePM produces a high-level project plan in Foundations showing increments and dates, refined over time.
Clue to watch for A question about planning beyond the current Sprint.
-
Manager plans the Sprint
- What candidates pick
- The Project Manager prepares the Sprint Backlog and assigns tasks.
- Why it looks right
- The Project Manager owns the project plan.
- Why it's wrong
- Detailed Sprint planning is done by the team; the Project Manager plans at project level.
Clue to watch for Detailed, task-level planning.
-
Add change without trade-off
- What candidates pick
- Accept an urgent new requirement into the current Sprint on top of existing work.
- Why it looks right
- Agile welcomes change.
- Why it's wrong
- Change is absorbed by reprioritising: something of lower priority is deferred so the timebox still ends on time.
Clue to watch for A new requirement arriving mid-timebox.
-
Percentage complete as progress
- What candidates pick
- Report progress as the average percentage completion of all open items.
- Why it looks right
- It gives a precise-looking number.
- Why it's wrong
- AgilePM measures progress through delivered, working products; partial work hides risk.
Clue to watch for A progress-reporting question.
Answer framework
Use these steps when a scenario involves planning, late work, change or escalation.
- Identify the planning level involved: project, increment or Sprint, and the role that owns planning at that level.
- If work is late inside a timebox, keep the end date fixed and defer the lowest-priority items, protecting Must Haves and agreed quality.
- If a change arrives, reprioritise with MoSCoW so higher-value work displaces lower-value work instead of extending the timebox.
- Compare the forecast deviation with agreed tolerances; act within them, and escalate with options only when a breach is forecast.
- Check that progress is judged on delivered, working products and that the Scrum event or artefact performing each planning step is used, not duplicated.
Practice question
Want more like this? The AgilePM Foundation practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with timeboxing and management by exception, because they settle the typical scenario in this area. Write two rules on a card: timebox end dates never move, and escalate only forecast breaches of tolerance. Then practise with short scenarios such as late items, a new urgent request or a sick developer, and decide in each whether the team acts or escalates.
Next, learn the planning levels. Sketch a project with three increments and several Sprints each, and label who plans what and in how much detail at Foundations, at the start of an increment and at Sprint Planning. This shows clearly that agile projects have long-range plans, just coarse ones.
The underestimated topic is tracking. Know the difference between burn-down and burn-up charts, why velocity is a forecasting aid rather than a target, and why partly done work is not counted.
Then connect to Scrum: map project and increment planning to Sprint Planning, the Daily Scrum and the Sprint Review. Afterwards, study governance, compliance and AgilePM products, which builds on tolerances and reporting, and take a scenario-heavy practice set.
FAQ
Do agile projects have a project plan?
Yes. AgilePM creates a high-level plan in Foundations showing increments and timing, and refines it as the project learns. Detailed planning happens per Sprint.
What happens if work is not finished by the end of a Sprint?
The Sprint ends on time. Unfinished lower-priority items return to the backlog to be reprioritised, protecting the fixed timebox and the agreed quality.
What is management by exception?
Working within agreed tolerances on time, cost and scope and escalating only when a forecast shows a tolerance will be breached. It keeps decisions at the lowest sensible level.
Who plans the detailed work?
The delivery team, during Sprint Planning and the Daily Scrum. The Project Manager leads project-level planning and coordinates across increments.
How is progress measured in AgilePM?
By delivered, working products, often shown on burn charts and demonstrated at Sprint Reviews, rather than by effort spent or percentage complete.
How does AgilePM planning fit with Scrum?
AgilePM project and increment plans set Sprint boundaries, priorities and Must Haves; Scrum events and artefacts handle detailed planning and inspection within each Sprint.
Other Project Management certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- PRINCE2 7 Practitioner Study guide
- PMI Risk Management Professional Study guide
- PMI Scheduling Professional Study guide
- Project Management Professional Study guide
- CompTIA Project+ Study guide
- PRINCE2 7 Foundation Study guide
- Portfolio Management Professional Study guide
- Program Management Professional Study guide
- Certified Associate in Project Management Study guide
- PMI Agile Certified Practitioner Study guide
- Project Management Professional (PMBOK 7) Study guide
- Disciplined Agile Scrum Master Study guide
Test your Domain 8 knowledge
You have covered planning levels, timeboxing, progress tracking, management by exception and Scrum integration. Check that you can decide when to act within tolerance and when to escalate.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the AgilePM Foundation AI tutor Get any concept explained your way