PRINCE2 Agile Foundation (Version 2) Quick Review
Quick Review for PeopleCert PRINCE2 Agile Foundation (Version 2), exam code PRINCE2 Agile Foundation, covering high-yield concepts, traps, and practice focus.
Quick Review purpose
Use this Quick Review for the PeopleCert PRINCE2 Agile Foundation (Version 2) exam, exam code PRINCE2 Agile Foundation, as a final concept pass before topic drills, mock exams, and detailed explanations.
This page is PM Mastery review support. It is not affiliated with PeopleCert. The focus is practical: know the concepts, recognize scenario wording, and avoid the common distractors that make agile project-management questions harder than simple definition recall.
Exam identity
| Item | Detail |
|---|---|
| Official provider | PeopleCert |
| Official exam title | PRINCE2 Agile Foundation (Version 2) |
| Official exam code | PRINCE2 Agile Foundation |
| Review focus | PRINCE2 governance combined with agile delivery concepts |
| Best use | Read quickly, then use topic drills and original practice questions to test application |
The core idea in one sentence
PRINCE2 Agile combines PRINCE2 project governance with agile ways of working so that the project remains justified, controlled, and accountable while delivery teams learn, adapt, and deliver useful products incrementally.
A strong candidate can explain both sides:
| PRINCE2 asks | Agile asks |
|---|---|
| Is the project still justified? | What have we learned from feedback? |
| Who is accountable for decisions? | How do we empower the people doing the work? |
| What products, outcomes, and benefits are expected? | What is the next most valuable increment? |
| What tolerances and controls apply? | How do we adapt within agreed boundaries? |
| How are risks, issues, and changes escalated? | How do we make work visible and respond quickly? |
| What evidence supports progress? | What working product, feedback, and flow data do we have? |
The exam often rewards answers that tailor governance rather than remove it. “Agile” is not a synonym for no planning, no documentation, no control, or no accountability.
High-yield checklist
Before you move to question-bank practice, make sure you can answer these without notes:
- What does PRINCE2 contribute to an agile project?
- What does agile contribute to a PRINCE2 project?
- Which project variables are usually protected, and which are commonly flexed?
- How do the PRINCE2 principles apply in an agile context?
- How do PRINCE2 processes continue to operate when teams use Scrum, Kanban, Lean, or iterative delivery?
- What is the difference between a project stage, a release, an iteration, and a daily stand-up?
- Why is quality usually not the correct thing to reduce when time is tight?
- How do backlog prioritization, MoSCoW, user stories, acceptance criteria, and Definition of Done support control?
- When should a team handle change within delegated authority, and when should the issue be escalated?
- Which role is accountable for business justification, and which role orders the backlog?
- Why does self-organization not remove the need for project-level governance?
PRINCE2 Agile mental model
PRINCE2 Agile is not “PRINCE2 plus Scrum vocabulary.” It is a decision framework for choosing the right level of control, flexibility, communication, and delivery rhythm.
| Concept | Quick exam meaning |
|---|---|
| Governance | Direction, accountability, justification, tolerances, escalation, and assurance |
| Agile delivery | Iterative and incremental work, empowered teams, fast feedback, collaboration, and adaptation |
| Tailoring | Adjusting PRINCE2 to suit the project environment without abandoning the principles |
| Empiricism | Making decisions from evidence, feedback, demonstrations, and actual progress |
| Product focus | Defining what must be delivered and how quality will be judged |
| Value focus | Prioritizing the work that best supports business outcomes and benefits |
| Control | Managing by exception, using tolerances, and escalating when forecasts breach limits |
A frequent candidate mistake is choosing an answer that sounds “more agile” but weakens project accountability. In PRINCE2 Agile, the better answer usually keeps both: agility inside clear governance boundaries.
PRINCE2 principles in an agile context
The PRINCE2 principles still apply. Agile working changes how they are implemented, not whether they apply.
| Principle | Agile interpretation | Common trap |
|---|---|---|
| Continued business justification | Frequent feedback and incremental delivery can validate whether the project remains worthwhile. | Continuing to iterate after the business case is no longer viable. |
| Learn from experience | Retrospectives, reviews, lessons, experiments, and feedback loops support learning. | Treating lessons as something captured only at project closure. |
| Define roles, responsibilities, and relationships | Project governance roles and delivery roles must be clear, even if some roles are combined. | Assuming self-organizing teams mean no role clarity is needed. |
| Manage by stages | Stages provide project-level control points; iterations or sprints are delivery-level timeboxes. | Confusing a sprint with a PRINCE2 management stage. |
| Manage by exception | Teams can work autonomously within tolerances; forecast breaches are escalated. | Letting the team “handle it” when project or stage tolerance will be exceeded. |
| Focus on products | Product descriptions, acceptance criteria, backlogs, and Definition of Done clarify what is required. | Measuring progress mainly by effort spent or tasks started. |
| Tailor to suit the project | Use appropriate governance, controls, documents, and agile techniques for the context. | Tailoring so heavily that PRINCE2 principles disappear. |
PRINCE2 practices to review
The exact scenario wording may vary, but the exam commonly tests whether you can apply each PRINCE2 practice in an agile environment.
| PRINCE2 practice | What to know for PRINCE2 Agile | Candidate mistake to avoid |
|---|---|---|
| Business case | Agile can test assumptions early, release value sooner, and stop or redirect work if justification weakens. | Treating an active backlog as proof the project is still justified. |
| Organizing | Project Board, Project Manager, Team Manager, assurance, and delivery roles must be understood. | Replacing governance roles with agile delivery roles without considering accountability. |
| Plans | Use project, stage, release, iteration, and team planning at the right level. Detail can increase as uncertainty reduces. | Creating a fully detailed plan too early for uncertain work, or having no plan at all. |
| Quality | Define acceptance criteria, quality criteria, test approaches, and Definition of Done. Build quality in. | Reducing quality to meet a deadline. |
| Risk | Agile may reduce risk through early feedback, but uncertainty, supplier constraints, technical debt, and stakeholder availability still need management. | Assuming agile automatically removes risk. |
| Issues | Requests for change, off-specifications, problems, and concerns need appropriate control and escalation. | Treating backlog reprioritization as a substitute for issue management. |
| Progress | Use tolerances, reporting, information radiators, burn charts, cumulative flow, demos, and forecasts. | Reporting only activity instead of evidence of product progress and forecast impact. |
The PRINCE2 processes with agile delivery
PRINCE2 processes describe project governance and management activity. Agile techniques may be used inside them, especially during product delivery.
| Process | Main purpose | Agile angle | Exam trap |
|---|---|---|---|
| Starting up a Project | Check whether the project is worth initiating. | Consider agile suitability, early product vision, stakeholders, and delivery approach. | Spending too much effort before confirming the project is viable. |
| Directing a Project | Project Board makes key decisions and provides direction. | Governance should empower agile teams within agreed limits. | Thinking agile removes Project Board decision-making. |
| Initiating a Project | Establish solid foundations for the project. | Define controls, delivery approach, roles, collaboration expectations, quality approach, and prioritization method. | Starting iterative delivery without agreed governance boundaries. |
| Controlling a Stage | Project Manager monitors and controls work in the current stage. | Use visual progress data, feedback, demos, and exception forecasts rather than micromanagement. | Confusing team stand-ups with project control. |
| Managing Product Delivery | Teams accept, execute, and deliver work packages. | Teams may use sprints, Kanban, user stories, backlog items, testing, and Definition of Done. | Assuming self-management means no work package agreement or reporting. |
| Managing a Stage Boundary | Review current stage and plan the next one. | Use learning, delivered increments, updated backlog, risks, and forecasts to replan. | Carrying forward the old plan unchanged despite feedback. |
| Closing a Project | Confirm acceptance, handover, lessons, and follow-on actions. | Close based on accepted products and remaining value, not merely on backlog exhaustion. | Keeping the project open just because some lower-priority backlog items remain. |
Fix and flex: the PRINCE2 Agile performance view
A major PRINCE2 Agile idea is that not all project variables should be treated the same. Agile projects often protect deadlines and quality by flexing lower-priority scope.
| Variable | Typical agile treatment | What this means in practice |
|---|---|---|
| Time | Often fixed or strongly protected | Use timeboxes, stage boundaries, release dates, and prioritization. |
| Cost | Often fixed or strongly protected | Stable teams and fixed timeboxes make cost more predictable. |
| Quality | Protected | Acceptance criteria, testing, and Definition of Done should not be weakened casually. |
| Scope | Usually the main area of flexibility | Defer or drop lower-priority items to protect time and quality. |
| Risk | Actively managed | Reduce uncertainty through early delivery, feedback, spikes, and transparent escalation. |
| Benefits | Monitored and refined | Agile feedback may change expected benefits or reveal earlier benefit opportunities. |
The practical decision rule
When a deadline is threatened, the strongest PRINCE2 Agile answer is usually:
- Protect quality.
- Reconfirm priorities.
- Keep the team stable where possible.
- Reduce or defer lower-value scope.
- Escalate if tolerances will be breached.
- Update plans, forecasts, risks, and business justification.
Weak answers often say: skip testing, accept poor quality, add uncontrolled scope, ignore tolerance breaches, or remove governance.
The five PRINCE2 Agile targets
These targets are useful exam filters because they show how PRINCE2 Agile expects candidates to think.
| Target | What it means | Practice implication |
|---|---|---|
| Be on time and hit deadlines | Time is important; delivery should be organized around deadlines and timeboxes. | Use prioritization and forecast early. |
| Protect the level of quality | Quality should be built in and agreed up front. | Use acceptance criteria, testing, and Definition of Done. |
| Embrace change | Change is expected and can add value. | Use controlled backlog reprioritization and issue/change control. |
| Keep teams stable | Stable teams improve collaboration, predictability, and flow. | Avoid casually adding/removing people to force short-term speed. |
| Accept that the customer does not need everything | Not every requested feature is essential. | Use MoSCoW, value analysis, and scope flexibility. |
Agile behaviours to recognize
PRINCE2 Agile expects more than ceremonies. It emphasizes behaviours that make agile working effective.
| Behaviour | Strong signal | Weak signal |
|---|---|---|
| Transparency | Work, risks, blockers, and progress are visible. | Bad news is hidden until a formal report. |
| Collaboration | Business, user, supplier, and delivery people work together. | Requirements are handed over once and rarely discussed. |
| Rich communication | Frequent, direct, high-bandwidth communication is used where useful. | Overreliance on long documents when discussion is needed. |
| Self-organization | Teams decide how best to do the work within boundaries. | Teams wait for detailed task instructions for everything. |
| Exploration | Teams learn through experiments, feedback, and increments. | The project pretends all uncertainty can be removed at the start. |
Remember: rich communication does not mean no documentation. The right answer is usually sufficient documentation plus effective conversation, tailored to risk, complexity, and governance needs.
The Agilometer: suitability and risk
The Agilometer is used to assess how suitable the project environment is for agile working and where tailoring or risk responses are needed. It is not simply a pass/fail test.
| Dimension to consider | Healthy signal | Risk signal | Possible response |
|---|---|---|---|
| Flexibility on what is delivered | Stakeholders can prioritize and accept lower-value scope being deferred. | Everything is treated as mandatory. | Clarify minimum viable scope and MoSCoW rules. |
| Collaboration | Business and delivery people are available and engaged. | Key users are unavailable or decisions are slow. | Secure stakeholder commitment and escalation paths. |
| Ease of communication | Teams can communicate frequently and clearly. | Distributed, siloed, or contract-limited communication. | Improve channels, working agreements, and cadence. |
| Iterative and incremental delivery | Products can be built, reviewed, and improved in increments. | Work can only be validated at the very end. | Use prototypes, spikes, staged validation, or adjust approach. |
| Environmental conditions | Governance, tools, suppliers, and culture support agility. | Heavy constraints block feedback or autonomy. | Tailor controls and address constraints as risks. |
| Acceptance of agile | People understand and support agile behaviours. | Stakeholders expect fixed scope with no trade-offs. | Educate stakeholders and agree decision rules. |
Exam trap: the Agilometer is not used to declare “agile is impossible” and stop thinking. It helps identify the risks of using agile and the tailoring needed.
Requirements, backlog, and prioritization
Agile requirements are often expressed differently from traditional requirement specifications, but they still need clarity and control.
| Term | Quick meaning | Exam note |
|---|---|---|
| Product backlog | Ordered list of work that may be needed. | It is dynamic, but not unmanaged. |
| User story | Short requirement from a user or stakeholder perspective. | It should be backed by acceptance criteria. |
| Epic | Large item that may be split into smaller stories. | Useful when detail is not yet known. |
| Acceptance criteria | Conditions that must be met for acceptance. | Helps avoid vague “done” claims. |
| Definition of Done | Shared standard for when work is complete. | Supports quality and transparency. |
| MoSCoW | Prioritization: Must, Should, Could, Won’t for now. | Must-haves should be limited to what is genuinely essential. |
| MVP | Minimum viable product used to learn or validate assumptions. | Not an excuse for poor quality. |
| Release | Delivery of a product increment to users or an operational environment. | Not every iteration necessarily creates a live release. |
| Velocity | Historical delivery rate for a team. | Useful for forecasting, not as a target to game. |
| WIP limit | Constraint on work in progress. | Helps flow and exposes bottlenecks. |
MoSCoW review
| Priority | Meaning | Candidate warning |
|---|---|---|
| Must have | Essential for viability or acceptance. | If everything is Must, nothing is truly prioritized. |
| Should have | Important but not vital for the immediate deadline. | Often a candidate for deferral if time is constrained. |
| Could have | Desirable if capacity allows. | Should not threaten Must or quality work. |
| Won’t have for now | Explicitly out of current scope or timebox. | May be considered later; not necessarily rejected forever. |
The exam often tests whether you understand that scope flexibility protects deadlines and quality. A good agile project has disciplined prioritization, not uncontrolled change.
Agile frameworks and techniques
You do not need to treat every agile framework as the same. Know the distinguishing features.
| Framework or technique | Core idea | What to watch for |
|---|---|---|
| Scrum | Iterative delivery in timeboxed sprints using roles/accountabilities, events, and artifacts. | A Scrum Master facilitates; they do not replace project governance. |
| Kanban | Visualize work, limit WIP, manage flow, and improve continuously. | Kanban does not require fixed-length iterations. |
| Lean | Maximize value, reduce waste, improve flow, and learn continuously. | Faster is not better if value and quality suffer. |
| Lean Startup | Build-measure-learn, MVPs, experiments, and validated learning. | MVP means enough to learn, not low quality. |
| Timeboxing | Work is constrained by a fixed time period. | Flex scope before flexing quality. |
| Prototyping | Create models or early versions to learn and validate. | A prototype may not be production-ready. |
| Spikes | Short investigations to reduce uncertainty. | Used for learning, not indefinite analysis. |
| Information radiators | Visible boards, charts, or dashboards showing work and progress. | Visibility supports but does not replace escalation. |
Roles: governance versus delivery
Many exam traps confuse PRINCE2 roles with agile delivery roles. Some responsibilities may be combined in real projects, but accountability must remain clear.
| Role | Main responsibility | Common confusion |
|---|---|---|
| Executive | Owns business justification and is accountable for the Business Case. | Not the same as the Product Owner. |
| Senior User | Represents user interests and expected benefits. | May work closely with a Product Owner but is a governance role. |
| Senior Supplier | Represents supplier or delivery capability. | Not simply “the development team.” |
| Project Board | Provides direction and key decisions. | Agile teams do not replace Project Board authority. |
| Project Manager | Manages the project day to day within tolerances. | Does not need to micromanage agile team tasks. |
| Team Manager | Manages or coordinates delivery of products for the team. | May be tailored in self-organizing agile environments. |
| Product Owner | Orders and clarifies the product backlog to maximize value. | Does not automatically own the project Business Case. |
| Scrum Master or agile coach | Facilitates agile working and helps remove impediments. | Not normally the person who authorizes project exceptions. |
| Change Authority | Approves changes within delegated limits. | Backlog changes may still need control if they affect tolerances. |
| Project Assurance | Checks business, user, and supplier interests are protected. | Assurance is not removed because delivery is agile. |
Scenario clue: if the issue is product priority, look for Product Owner or user/business input. If the issue is project viability, tolerance, or direction, look for Project Manager, Project Board, Executive, or Change Authority depending on delegation.
Planning levels: do not confuse them
| Planning level | Typical focus | Agile connection |
|---|---|---|
| Project plan | Overall project products, major controls, stages, and business justification. | May be high-level when uncertainty is high. |
| Stage plan | Detailed control for the next management stage. | Can incorporate releases, timeboxes, and feedback points. |
| Release plan | When increments may be released to users or operations. | Helps align value delivery and stakeholder expectations. |
| Iteration or sprint plan | Work selected for a short timebox. | Managed by the delivery team within agreed boundaries. |
| Team plan | How a team will deliver assigned products or work packages. | May be represented by sprint plans, Kanban boards, or similar. |
| Exception plan | Replaces a plan that is forecast to exceed tolerance, if approved. | Still applies in agile projects when tolerances are threatened. |
A sprint is not automatically a PRINCE2 stage. A stage is a governance control period; a sprint is a delivery timebox. They can align, but they are not the same concept.
Progress, control, and reporting
Agile projects can produce strong progress evidence because work is visible and increments can be inspected. But progress still needs interpretation.
| Evidence | What it tells you | Limitation |
|---|---|---|
| Demonstrated increment | What has actually been built and can be reviewed. | May not show all remaining risk. |
| Burn-down chart | Work remaining over time. | Can be misleading if scope changes are not visible. |
| Burn-up chart | Work completed and total scope trend. | Requires clear scope tracking. |
| Cumulative flow diagram | Flow, queues, WIP, and bottlenecks. | Needs interpretation; it is not a decision by itself. |
| Kanban board | Current status of work items. | “In progress” is not the same as done. |
| Daily stand-up | Team coordination and blocker identification. | Not a full project status meeting. |
| Sprint review/demo | Feedback on completed work. | Should not replace formal acceptance where required. |
| Retrospective | Process learning and improvement. | Does not authorize project-level changes by itself. |
Manage by exception in agile
Use this simple decision rule:
- Is the issue within team-level authority and tolerances?
- If yes, the team can adapt and make work visible.
- Does it affect stage or project tolerances, business justification, agreed quality, major risk, or delegated change limits?
- If yes, escalate through the agreed PRINCE2 route.
- Does the decision change priorities but remain within delegated authority?
- If yes, reprioritize transparently and update relevant plans or backlog information.
- Does the decision exceed authority?
- If yes, raise the issue or exception for the appropriate decision-maker.
Quality: the most tested agile trade-off
Quality is a frequent trap. Agile projects may flex scope, but they should not casually flex quality.
| Quality concept | Why it matters |
|---|---|
| Acceptance criteria | Define how a story or product will be accepted. |
| Quality criteria | Define measurable quality expectations for products. |
| Definition of Done | Provides a shared completion standard. |
| Built-in quality | Testing and review happen throughout delivery, not only at the end. |
| Technical debt | Shortcuts may create future cost, risk, and quality problems. |
| Continuous feedback | Reviews and demos reveal quality and value issues early. |
Weak exam answers often suggest reducing testing, accepting unfinished work as “done,” or hiding defects to meet a deadline. Stronger answers protect quality, reduce lower-priority scope, and escalate if tolerances are at risk.
Risk, issues, and change
Agile welcomes change, but PRINCE2 Agile does not mean uncontrolled change.
| Situation | Better response | Poor response |
|---|---|---|
| Stakeholder requests a new feature | Assess value, priority, impact, and authority; update backlog or raise change if needed. | Add it immediately because agile embraces change. |
| A Must-have item is too large for the timebox | Split it, clarify acceptance criteria, or reassess priority and forecast. | Lower quality so it fits. |
| A technical uncertainty threatens delivery | Use a spike, prototype, expert input, or risk response. | Ignore until the end of the stage. |
| Forecast shows stage tolerance will be exceeded | Escalate as required by manage by exception. | Let the team continue because it self-organizes. |
| External supplier cannot collaborate frequently | Treat as a risk and tailor communication, contracts, and controls. | Assume agile ceremonies will solve the problem. |
| Users are unavailable for feedback | Escalate stakeholder engagement risk and adjust plans. | Continue building assumptions without validation. |
Special focus areas
PRINCE2 Agile commonly emphasizes several practical areas because they strongly affect agile success.
| Focus area | Why it matters | Review cue |
|---|---|---|
| Agilometer | Assesses how suitable the environment is for agile and where risks exist. | Use it to tailor, not to avoid thinking. |
| Requirements | Agile requirements evolve but still need clarity and prioritization. | Backlog plus acceptance criteria. |
| Rich communication | Fast feedback reduces misunderstanding. | Prefer direct communication where useful. |
| Frequent releases | Releasing increments can deliver value and learning earlier. | A release is not the same as every sprint. |
| Contracts | Supplier arrangements can enable or block agility. | Fixed scope plus high uncertainty is risky. |
Common scenario traps
Use these as a quick pre-practice warning list.
“Agile means no plan.” Wrong. Agile planning is adaptive and layered.
“Agile means no documentation.” Wrong. Documentation should be sufficient, useful, and proportionate.
“The Product Owner replaces the Project Board.” Wrong. Product prioritization and project governance are different responsibilities.
“The Scrum Master is the Project Manager.” Not necessarily. The Scrum Master facilitates agile working; project management accountability remains defined.
“If time is fixed, reduce quality.” Usually wrong. Flex lower-priority scope first.
“All backlog items are required.” Wrong. A backlog is prioritized; not everything is essential for the next deadline.
“A sprint is a PRINCE2 stage.” Not automatically. Stages are governance controls; sprints are delivery timeboxes.
“A daily stand-up is a project status meeting.” Wrong. It is mainly for team coordination.
“Self-organizing teams do not need escalation.” Wrong. They work within tolerances and escalate forecast breaches.
“Velocity is a performance target.” Weak. Velocity is mainly a forecasting aid and can be distorted if used as a target.
“MVP means low quality.” Wrong. It means minimum viable scope for learning or value, with appropriate quality.
“Change control is anti-agile.” Wrong. PRINCE2 Agile supports controlled change.
“More detail at the start always means better control.” Not when uncertainty is high. Rolling-wave planning may be more appropriate.
“Information radiators replace governance reports.” They help visibility, but formal controls may still be required.
“The customer needs everything requested.” PRINCE2 Agile expects prioritization and recognition that not everything is needed immediately.
Scenario decision rules
When a question asks for the “best” or “most appropriate” response, use these filters.
| Scenario clue | Likely best direction |
|---|---|
| Business case no longer valid | Escalate and consider whether the project should continue. |
| Deadline fixed, too much scope | Prioritize and defer lower-value scope while protecting quality. |
| Team blocked by stakeholder unavailability | Treat as a risk/issue and improve engagement or escalate. |
| Product unclear | Use collaboration, workshops, prototypes, user stories, or spikes. |
| Quality concerns appearing late | Strengthen built-in quality, acceptance criteria, and Definition of Done. |
| Too much work in progress | Limit WIP and improve flow. |
| Frequent misunderstandings | Improve rich communication and feedback loops. |
| Forecast tolerance breach | Use PRINCE2 exception handling. |
| New requirement within delegated limits | Assess, prioritize, and update backlog transparently. |
| New requirement outside delegated limits | Raise through issue/change control. |
| Team being micromanaged | Empower the team within agreed controls. |
| No visibility of progress | Use information radiators, demos, forecasts, and reporting. |
Fast comparison: PRINCE2 and agile delivery
| Topic | PRINCE2 emphasis | Agile emphasis | Combined PRINCE2 Agile answer |
|---|---|---|---|
| Control | Stages, tolerances, roles, reports | Transparency, feedback, flow | Use both formal controls and visible delivery data. |
| Planning | Product-based and stage-based planning | Rolling wave, release and iteration planning | Plan at the right level and refine as learning increases. |
| Change | Controlled issue/change process | Embrace valuable change | Allow change within governance boundaries. |
| Quality | Quality planning and criteria | Built-in quality and Definition of Done | Define quality early and verify continuously. |
| Progress | Forecasts against plan and tolerances | Working increments and flow metrics | Use evidence-based reporting and exception rules. |
| Roles | Accountable governance structure | Empowered delivery roles | Keep responsibilities clear and tailored. |
| Benefits | Business case and benefits management | Early value and validation | Use feedback to confirm or adjust expected benefits. |
How to use practice questions after this review
A good practice sequence is:
Topic drills first. Start with principles, roles, fix/flex, practices, processes, agile terms, and scenario judgement.
Review every explanation. For each missed question, identify whether the problem was vocabulary, role confusion, governance, agile technique, or scenario reading.
Repeat weak topics. Do not move straight to full mock exams if you are still confusing Project Board, Project Manager, Product Owner, and Scrum Master responsibilities.
Use mixed questions next. Mixed sets force you to recognize which concept is being tested without a topic label.
Use mock exams last. Mock exams are best once your topic accuracy is stable and you can explain why each distractor is wrong.
Topic-drill map
| If you miss questions about… | Drill this area |
|---|---|
| “Best response” scenarios | Decision rules, tolerances, and escalation |
| Role accountability | Project Board, Executive, Senior User, Project Manager, Product Owner, Scrum Master |
| Deadline pressure | Fix/flex, MoSCoW, quality protection |
| Requirements | User stories, acceptance criteria, backlog refinement, Definition of Done |
| Progress reporting | Burn charts, information radiators, demos, manage by exception |
| Agile suitability | Agilometer and tailoring |
| Delivery methods | Scrum, Kanban, Lean, timeboxing, WIP limits |
| Governance | PRINCE2 principles, practices, and processes |
| Change | Issue/change control plus backlog prioritization |
| Quality | Acceptance criteria, testing, technical debt, Definition of Done |
Final quick recap
For PeopleCert PRINCE2 Agile Foundation (Version 2), exam code PRINCE2 Agile Foundation, keep these ideas fresh:
- PRINCE2 Agile is governance plus agile delivery, not one replacing the other.
- PRINCE2 principles still apply and must be tailored appropriately.
- Time and cost are often protected; quality should be protected; scope is commonly flexed.
- Change is welcomed only when it is controlled and value-focused.
- Self-organizing teams still operate within tolerances and agreed governance.
- Backlogs, MoSCoW, user stories, and acceptance criteria support control when used well.
- Project roles and agile delivery roles are not automatically interchangeable.
- Evidence of progress should come from working products, feedback, flow, and forecasts.
- If tolerances or business justification are threatened, escalate through the agreed PRINCE2 route.
Next step: use the PM Mastery question bank to run focused topic drills on your weakest areas, then review the detailed explanations until you can identify both the correct answer and the trap in each distractor.
Continue in PM Mastery
Use this Quick Review as a final concept map, then move into PM Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original PM Mastery practice items; they are not official PeopleCert questions, copied live-exam content, or exam dumps.