PRINCE2 Agile Foundation (Version 2) Exam Blueprint

Last revised: July 1, 2026

Practical exam blueprint for PeopleCert PRINCE2 Agile Foundation (Version 2) exam readiness.

How to Use This Exam Blueprint

Use this independent Exam Blueprint as a final-review map for the PeopleCert PRINCE2 Agile Foundation (Version 2) exam, exam code PRINCE2 Agile Foundation. It is designed to help you confirm that you can recognize concepts, connect PRINCE2 governance to agile delivery, and answer foundation-level scenario questions without turning the exam into generic project-management theory.

For each area, ask:

Can I explain the concept in PRINCE2 Agile language?
Can I identify the correct role, artifact, process, or decision point?
Can I distinguish agile flexibility from uncontrolled change?
Can I choose a proportionate response in a scenario?

Because official weights can change, treat the sections below as readiness areas, not as an official weighting model.

Exam identity

Item	Details
Vendor/provider	PeopleCert
Official exam title	PRINCE2 Agile Foundation (Version 2)
Official exam code	PRINCE2 Agile Foundation
Professional area	Project Management
Page purpose	Exam Blueprint for exam preparation and final review

Topic-area readiness map

Readiness area	What to review	You are ready when you can…	Scenario cue to practice
PRINCE2 Agile purpose	Why PRINCE2 governance is combined with agile delivery approaches	Explain how PRINCE2 provides direction, control, and accountability while agile supports iterative delivery and responsiveness	“The team wants to work agile, but executives need governance. What should be retained?”
PRINCE2 principles in agile context	Continued business justification, learning, roles, stages, exception, product focus, tailoring	Apply each principle without making the project heavy or uncontrolled	“Which principle is being used when tolerances allow the team to proceed without escalation?”
People and collaboration	Stakeholders, project board, project manager, team manager, agile delivery roles, customer/user involvement	Identify who should decide, advise, deliver, accept, or escalate	“The product owner is unavailable. What risk does this create?”
Governance and lifecycle	PRINCE2 processes and stage-based control adapted to agile delivery	Recognize where decisions, authorization, delivery control, and closure happen	“A stage is forecast to exceed tolerance. What happens next?”
Tailoring and suitability	How to tailor PRINCE2 controls for agile environments; agile suitability assessment concepts	Choose “minimum sufficient governance,” not no governance	“The team says daily stand-ups replace all reporting. Is that enough?”
Business justification and value	Business Case, benefits, value, outcomes, prioritization, viability	Connect product increments and priorities to continued business justification	“Benefits no longer justify the project. What should be reviewed?”
Requirements and products	Product descriptions, acceptance criteria, user stories, backlog items, prioritization	Separate product focus from task focus and link acceptance to quality	“A feature is requested late. How should it be assessed?”
Planning and timeboxing	Stages, releases, iterations/sprints, work packages, plans, forecasting	Explain different planning horizons and how detail increases as work approaches	“What should be planned in detail now versus later?”
Agile techniques	Scrum-style events, Kanban/flow, backlogs, information radiators, retrospectives, MoSCoW-style prioritization	Recognize common agile tools and when they support transparency, flow, or value	“A team has too much work in progress. Which agile control helps?”
Quality and acceptance	Definition of done, acceptance criteria, quality planning, quality control, customer acceptance	Protect quality while flexing lower-value scope when needed	“The deadline is fixed and quality is at risk. What should flex?”
Risk, issues, and change	Risk responses, issue/change control, escalation, tolerances, transparency	Decide whether to handle, record, escalate, or defer based on impact and authority	“A new requirement threatens tolerance. What artifact or control is involved?”
Progress and reporting	Checkpoints, highlight reporting, boards, burn charts, flow metrics, exceptions	Use agile visibility as evidence for PRINCE2 control, not as a replacement for accountability	“The board needs confidence without daily detail. What reporting level fits?”
Closing and learning	Acceptance, handover, lessons, benefits review planning, unfinished work	Close deliberately and capture learning, even when delivery was iterative	“The product is incrementally delivered. Does the project still need formal closure?”

Core PRINCE2 Agile ideas to know cold

Check these before moving to practice questions:

I can explain that PRINCE2 Agile is about combining project governance with agile ways of working.
I can distinguish project-level management from team-level delivery.
I can explain why agile does not mean “no plan,” “no documentation,” or “no control.”
I can explain why PRINCE2 does not mean “large upfront specification for everything.”
I can describe how iterative and incremental delivery can support earlier feedback and value.
I can explain why collaboration, transparency, and frequent feedback reduce delivery risk.
I can identify when a decision belongs to the project board, project manager, team manager, product owner/customer representative, or delivery team.
I can explain why tolerances and exception management matter in agile contexts.
I can describe how lower-priority scope may be flexed to protect time, cost, quality, and value.
I can explain why quality criteria and acceptance criteria should not be silently weakened.
I can recognize that tailoring means adapting controls to context, not removing accountability.

PRINCE2 principles: foundation readiness

PRINCE2 principle	Agile-context readiness check	Typical exam trap
Continued business justification	You can connect backlog priority, incremental delivery, and benefits to the Business Case	Treating “the team is busy” as proof the project is still justified
Learn from experience	You can identify lessons from retrospectives, reviews, delivery data, and prior stages	Thinking lessons are captured only at the end
Defined roles, responsibilities, and relationships	You can separate governance roles from delivery roles and customer/user roles	Letting a collaborative team blur accountability for key decisions
Manage by stages	You can explain why stage boundaries still matter even if delivery is iterative	Assuming sprints or iterations automatically replace management stages
Manage by exception	You can identify when a tolerance breach or forecast breach requires escalation	Escalating every minor delivery issue to the project board
Focus on products	You can link requirements, user stories, acceptance criteria, and quality to defined products	Managing only tasks and effort without product outcomes
Tailor to suit the project	You can choose proportional governance, reporting, and documentation	Confusing lightweight controls with absence of controls

PRINCE2 processes and agile delivery checkpoints

You do not need to make every process heavy. You do need to know what each process is trying to control and how agile delivery information can support it.

Process area	What to recognize	Agile-readiness prompt
Starting up a project	Initial viability, project mandate or trigger, key roles, early justification, outline approach	Can you identify whether the project is worth initiating before detailed planning starts?
Directing a project	Project board decision-making, authorization, continued direction, exception decisions	Can you identify when the board should authorize, stop, continue, or redirect?
Initiating a project	Baseline understanding of justification, governance, plans, controls, quality, risk, and approach	Can you describe how a project can be initiated with enough certainty while allowing progressive detail?
Controlling a stage	Day-to-day project management within stage tolerances, work package control, issue/risk handling	Can you decide whether the project manager should act, monitor, or escalate?
Managing product delivery	Team-level acceptance, execution, and delivery of work packages/products	Can you connect agile team practices to agreed delivery expectations and quality criteria?
Managing a stage boundary	Review current stage, update plans and Business Case, prepare for the next stage, escalate exceptions if needed	Can you identify what must be reconsidered before authorizing the next stage?
Closing a project	Confirm acceptance, evaluate performance, transfer products, capture lessons, plan benefits review	Can you explain why formal closure still matters after incremental delivery?

Practices, artifacts, and what they prove

Where your study materials use different terminology, focus on the purpose: what is being controlled, who uses it, and what decision it supports.

Practice / control area	Artifacts or evidence to recognize	What the exam may test
Business justification	Business Case, benefits assumptions, value statements, benefit review planning	Whether the project should continue, change direction, or stop
Organization / roles	Role descriptions, stakeholder map, communication approach, team structure	Who owns a decision, who supplies information, who accepts products
Plans	Project plan, stage plan, team plan, release plan, iteration/sprint plan, work package	Which planning level is appropriate for the decision being made
Quality	Quality approach, product descriptions, acceptance criteria, definition of done, test evidence	Whether the product is acceptable and quality is being protected
Risk	Risk register/log, risk responses, risk ownership, agile risk visibility	Whether uncertainty is being identified, assessed, owned, and controlled
Issues and change	Issue register/log, change control, prioritization decisions, exception reports	Whether a request is handled within tolerance or escalated
Progress	Checkpoint information, highlight reports, burn charts, Kanban boards, flow indicators, exception reporting	Whether actual progress is visible enough for governance decisions
Lessons	Lessons log, retrospective outputs, stage reviews, closure learning	Whether learning is captured and applied, not merely discussed
Product definition	Product breakdown, product descriptions, backlog, user stories, acceptance criteria	Whether work is product-focused and testable
Handover and transition	Release evidence, operational readiness, acceptance, support information	Whether delivered increments can be used and supported

Agile concepts and techniques to review

Agile delivery and product thinking

I can explain iterative development.
I can explain incremental delivery.
I can distinguish an increment from an activity.
I can describe how feedback informs future work.
I can explain why product ownership or customer representation is important.
I can connect user needs to product acceptance.
I can explain why not all requested features have equal value.
I can describe how a backlog supports prioritization and transparency.

Scrum-style concepts

Be ready to recognize the purpose of common Scrum-style elements without assuming every PRINCE2 Agile project must use Scrum.

Product backlog: ordered list of potential product work.
Sprint or iteration backlog: selected work for a short delivery period.
Daily coordination: short team-level synchronization.
Review or demonstration: feedback on completed product increments.
Retrospective: improvement of the way of working.
Definition of done: shared quality/completion understanding.
Product owner or equivalent customer role: value and priority input.
Scrum Master/agile coach or equivalent: facilitation and improvement support.

Kanban and flow concepts

I can explain visualizing work.
I can explain limiting work in progress.
I can recognize pull-based flow.
I can distinguish blocked work from completed work.
I can explain how flow information supports transparency.
I can identify when too much work in progress creates risk.

Prioritization and scope flexibility

I can explain why prioritization is central when time or cost is constrained.
I can recognize MoSCoW-style thinking: must-have, should-have, could-have, won’t-have for now.
I can explain why “must-have” should not become a dumping ground for every request.
I can identify when lower-value scope may be deferred to protect quality or deadlines.
I can distinguish scope flexibility from uncontrolled scope creep.
I can connect prioritization decisions to business justification and stakeholder agreement.

Agile planning and estimation

I can distinguish project, stage, release, and iteration planning.
I can explain rolling-wave or progressive planning in plain language.
I can recognize that near-term work is usually planned in more detail than later work.
I can use velocity, burn charts, or flow information as forecasting evidence, without treating them as guarantees.
I can explain why estimates should be revisited as uncertainty reduces.
I can identify when a forecast breach should trigger exception handling.

Scenario and decision-point checks

Use this table to practice exam-style judgment. The best answer is often the one that preserves both agility and PRINCE2 control.

Scenario	Strong PRINCE2 Agile judgment	Avoid this trap
A stakeholder requests a new feature during a fixed delivery window	Assess value, priority, impact, and authority; consider flexing lower-priority scope or using change control if needed	Quietly adding the feature and hoping the team can absorb it
The team says quality criteria cannot be met by the deadline	Protect agreed quality; review scope, risk, and tolerance; escalate if forecast outside authority	Reducing quality without approval
A team wants to remove all documentation because “we are agile”	Tailor documentation to be useful and sufficient; retain evidence needed for governance and acceptance	Equating agile with undocumented work
The project board asks for confidence but not technical detail	Provide concise progress, risk, issue, forecast, and decision information at the right level	Sending raw daily team updates as governance reporting
A sprint review reveals the product is not meeting user needs	Use feedback to reprioritize and adapt plans; assess impact on Business Case and stage objectives	Treating the original backlog as fixed regardless of evidence
The product owner/customer representative is rarely available	Treat this as a collaboration and decision risk; resolve role availability or escalate appropriately	Letting the team guess priorities and acceptance decisions
Work in progress keeps increasing	Use flow visibility, WIP control, prioritization, and impediment removal	Starting more work to appear productive
A stage is forecast to exceed agreed tolerance	Prepare exception information and escalate to the appropriate authority	Continuing because the team still believes it may recover
Benefits assumptions no longer appear valid	Review and update business justification; seek direction if continued viability is in doubt	Focusing only on completing scope
The agile team is self-organizing	Let the team manage how work is done while preserving role accountability, tolerances, and product expectations	Assuming self-organization means no project manager involvement
A release has operational or support risk	Include transition, acceptance, support, risk, and quality considerations in planning	Assuming “done” for the team means “ready for business use”
A conflict arises between a senior stakeholder’s request and agreed product priority	Use agreed roles, prioritization, value, and change control to resolve	Letting the loudest stakeholder override governance

“What should happen next?” decision path

Use this simplified decision path when you face scenario questions about issues, change, risk, or progress.

    flowchart TD
	    A[New information appears] --> B{Is it about value, scope, quality, risk, progress, or acceptance?}
	    B -->|No| C[Clarify and monitor]
	    B -->|Yes| D[Record or make visible in the appropriate artifact or board]
	    D --> E{Within agreed authority and tolerance?}
	    E -->|Yes| F[Project manager/team handles using agreed controls]
	    E -->|No or forecast breach| G[Escalate through exception or governance route]
	    F --> H[Update plan, backlog, risk, issue, or quality evidence]
	    G --> I[Seek decision from appropriate authority]
	    H --> J[Communicate proportionately]
	    I --> J

Can you do this?

Recognition and explanation

Explain the purpose of PRINCE2 Agile without describing it as only PRINCE2 or only agile.
Define the difference between governance, management, and team delivery.
Recognize how agile transparency supports management by exception.
Explain why tailoring must preserve the purpose of PRINCE2 controls.
Identify how agile feedback loops support learning from experience.
Explain why a project can be agile and still have stages, tolerances, reporting, and formal closure.

Roles and responsibilities

Identify when the project board should make a decision.
Identify when the project manager should manage within tolerance.
Identify when the team manager or delivery team should plan and deliver work.
Recognize the importance of customer/user input for backlog priority and acceptance.
Distinguish facilitation or agile coaching from project authority.
Recognize stakeholder engagement issues in agile scenarios.

Artifacts and evidence

Choose the artifact most likely to be updated after a risk changes.
Choose the artifact most likely to be updated after a new issue or change request.
Identify when the Business Case needs review.
Connect acceptance criteria to quality and product acceptance.
Distinguish a backlog item from a formal product description where relevant.
Recognize when a burn chart, board, or flow metric provides progress evidence.
Identify which planning level should be updated: project, stage, release, iteration, team plan, or work package.

Scenario judgment

Decide whether to handle an issue within tolerance or escalate.
Decide what to flex when a deadline is fixed and not everything can be delivered.
Decide how to respond when quality is threatened.
Decide how to respond when a stakeholder requests extra scope.
Decide how to respond when agile team practices conflict with governance needs.
Decide how to respond when delivery data shows the plan is no longer realistic.
Decide what to do when benefits or business justification weaken.
Decide how to preserve collaboration when key decision makers are unavailable.

Common weak areas and traps

Weak area	Why candidates miss it	How to fix it
Treating agile as lack of control	Agile language can sound informal compared with PRINCE2 governance	Always ask: what control is still needed, and how can it be made lightweight?
Confusing stages with sprints	Both divide work, but they serve different governance and delivery purposes	Practice mapping management stages to delivery iterations/releases
Over-escalating	Foundation scenarios often test management by exception	Ask whether the issue is within tolerance before escalating
Under-escalating	Agile teams may be empowered, but not beyond agreed authority	Escalate forecast tolerance breaches or major justification changes
Weak role separation	Agile collaboration can blur decision rights	Memorize who directs, manages, delivers, prioritizes, accepts, and assures
Ignoring the Business Case	Candidates focus on delivery activity rather than justification	Connect every major change or benefit concern back to continued justification
Treating scope as fixed	Agile often uses prioritization to handle uncertainty	Practice flexing lower-priority scope while protecting quality and value
Treating quality as flexible	Deadline pressure can tempt candidates to reduce quality	Remember that quality criteria and acceptance need explicit control
Thinking all documentation is bad	Agile favors useful information, not absence of information	Ask what evidence is needed for decision-making, quality, risk, and acceptance
Misusing agile metrics	Charts and boards show evidence, not certainty	Use metrics to inform forecasts and decisions, not to guarantee outcomes
Forgetting lessons	Agile retrospectives are learning opportunities	Link retrospectives, stage reviews, and closure lessons
Choosing the most technical answer	The exam is project-management focused	Prefer the answer that addresses governance, value, risk, roles, or control

Final-week checklist

Knowledge consolidation

Review the official PeopleCert terminology for PRINCE2 Agile Foundation (Version 2).
Build a one-page map of PRINCE2 principles, processes, roles, and control areas.
List the main agile techniques you must recognize and write one sentence for the purpose of each.
Compare PRINCE2 stage control with agile iteration/release delivery.
Review how tailoring affects artifacts, reporting, planning, and roles.
Review how tolerances and exception handling work in agile scenarios.

Scenario practice

Practice questions where a stakeholder asks for new scope.
Practice questions where delivery is forecast to exceed tolerance.
Practice questions where quality is at risk.
Practice questions where the Business Case is weakened.
Practice questions where a team wants less governance.
Practice questions where the project board needs decision-level information.
Practice questions where a backlog, risk log, issue log, or plan must be updated.
Practice questions where you must identify the next best action.

Exam-readiness self-test

You are close to ready if you can answer “yes” to each:

Can I explain PRINCE2 Agile in two minutes without notes?
Can I identify the likely role responsible for a decision in a short scenario?
Can I distinguish an issue, risk, change request, quality concern, and progress concern?
Can I decide whether to update an artifact, reprioritize, escalate, or continue monitoring?
Can I explain why agile teams still need acceptance criteria and quality controls?
Can I explain why project closure still matters after incremental delivery?
Can I avoid answers that are too rigid, too informal, or outside the role’s authority?

Practical next step

Use this checklist to mark weak areas, then move into focused practice questions for the PeopleCert PRINCE2 Agile Foundation (Version 2) exam. Prioritize questions that ask what should happen next, which role is accountable, what artifact should be updated, and how to balance agile flexibility with PRINCE2 governance.

Study Plan

Scenario Guide