PRINCE2 Agile Foundation (Version 2) Quick Reference

Last revised: July 1, 2026

Compact exam-prep reference for PeopleCert PRINCE2 Agile Foundation (Version 2): principles, processes, roles, tolerances, agile tailoring, and common traps.

Exam identity and core mental model

Use this Quick Reference for the PeopleCert PRINCE2 Agile Foundation (Version 2) exam, official exam code PRINCE2 Agile Foundation. It is independent exam-prep support and is not affiliated with PeopleCert.

PRINCE2 Agile is not “PRINCE2 plus Scrum.” The exam tests how to tailor PRINCE2 project governance so agile delivery can work within controlled project management.

Layer	What it contributes	Exam answer pattern
PRINCE2	Business justification, governance, roles, management stages, tolerances, exception control, product focus	Keep accountability clear; tailor controls, do not remove them
Agile	Iterative and incremental delivery, collaboration, empirical feedback, adaptive scope, self-organizing teams	Deliver value early, inspect and adapt, flex lower-priority scope
PRINCE2 Agile	Governance with agile behaviors and techniques	Fix time/cost where appropriate, protect quality, embrace controlled change

High-yield default: do not extend deadlines or reduce quality first. First, inspect priorities, protect Must-have outcomes, flex lower-priority scope, and escalate only when tolerances are forecast to be exceeded.

PRINCE2 principles through an agile lens

PRINCE2 principle	Agile interpretation	Common exam trap
Ensure continued business justification	Validate value frequently through increments, releases, feedback, and updated forecasts	Continuing because a sprint or stage is already underway
Learn from experience	Use retrospectives, demos, reviews, lessons logs, and empirical data	Saving lessons only for project closure
Define roles, responsibilities, and relationships	Keep business, user, supplier, project management, and delivery responsibilities clear	Assuming self-organization means no accountability
Manage by stages	Use management stages for governance; stages may contain releases, timeboxes, or sprints	Treating every sprint as a PRINCE2 management stage
Manage by exception	Set tolerances for time, cost, quality, scope, benefits, and risk; escalate forecast breaches	PM micromanages daily agile team work
Focus on products	Define outputs, quality criteria, acceptance criteria, and value; use backlogs and product descriptions	Planning only activities and effort
Tailor to suit the project	Adjust processes, practices, roles, documentation, and controls to context	Dropping PRINCE2 controls because “we are agile”

PRINCE2 Agile targets

Target	Practical meaning	Preferred exam response
Be on time and hit deadlines	Timeboxes, releases, and stages protect time commitments	De-scope lower-priority items before extending time
Protect the level of quality	Quality criteria, Definition of Done, tests, reviews, and acceptance criteria remain meaningful	Never “solve” schedule pressure by silently lowering quality
Embrace change	Change is expected and handled through backlog refinement, prioritization, and delegated authority	Change is controlled, not unmanaged
Keep teams stable	Stable teams improve forecasting, collaboration, and throughput	Avoid moving people in and out unless justified
Accept that the customer does not need everything	Focus on value and minimum usable outcomes	Use MoSCoW and product focus to avoid delivering low-value scope

Fix and flex: six project performance aspects

PRINCE2 manages by exception using tolerances. In agile contexts, the exam often expects the following stance.

Aspect	Agile-friendly default	What to watch for
Time	Usually fixed for timeboxes, releases, or external deadlines	Do not extend a timebox automatically
Cost	Often stable because teams are kept stable for a fixed period	Adding people late may reduce effectiveness
Quality	Protected; agreed quality and acceptance criteria should not be weakened	“Drop testing to hit the date” is usually wrong
Scope	Most flexible variable; lower-priority features can move out	Must-have minimum outcomes still matter
Risk	Managed continuously; uncertainty is reduced by feedback and increments	Escalate if risk tolerance is threatened
Benefits	Reviewed frequently; early delivery may enable early benefit validation	If justification fails, escalate or stop

Key lifecycle distinctions

Term	Meaning	Exam distinction
Project	Temporary organization delivering products that create outcomes and benefits	Governed by PRINCE2
Management stage	PRINCE2 control interval authorized by the Project Board	Not automatically the same as a sprint
Release	Deployment or handover of usable capability	A stage may contain one or more releases
Timebox / sprint	Fixed delivery period for a team to create or refine products	Usually managed within delegated tolerances
Iterative	Repeated cycles refine understanding and solution quality	Good for uncertainty and discovery
Incremental	Product is delivered in usable pieces	Supports early value and feedback
Product increment	Potentially usable output from a timebox or release	Must meet agreed quality expectations

    flowchart LR
	    SU[Starting up a Project] --> IP[Initiating a Project]
	    IP --> DS1[Delivery management stage]
	    DS1 --> SB[Managing a Stage Boundary]
	    SB --> DS2[Next delivery stage]
	    DS2 --> CP[Closing a Project]
	
	    subgraph Inside_a_delivery_stage[Inside a delivery stage]
	        RP[Release planning] --> TB1[Timebox / sprint]
	        TB1 --> RV[Review / demo]
	        RV --> RT[Retrospective]
	        RT --> TB2[Next timebox]
	    end
	
	    DS1 -. controlled by tolerances .-> PB[Project Board direction]

PRINCE2 processes tailored for agile

Process	Agile tailoring	Key evidence / outputs	Exam traps
Starting up a Project	Confirm project mandate, outline business justification, assess agile suitability, identify key roles	Project brief, outline Business Case, initial product vision, initial risk view, Agilometer thinking	Starting delivery before viability and role clarity
Directing a Project	Project Board authorizes, sets tolerances, gives strategic direction, supports empowerment	Authorizations, decisions, exception direction	Board manages sprint tasks directly
Initiating a Project	Define governance, delivery approach, quality approach, change approach, communication, controls	PID, Business Case, project plan, stage plan, role descriptions, risk and issue approaches	Heavy PID by default; or no PID because agile
Controlling a Stage	PM monitors stage progress, risks, issues, tolerances; coordinates with agile teams	Highlight reports, issue/risk updates, updated forecasts, work package controls	PM assigns every team task
Managing Product Delivery	Team accepts work, delivers iteratively, demonstrates, tests, and reports progress	Work package agreement, team plans, increments, quality evidence, checkpoint information	Team ignores agreed constraints because self-organizing
Managing a Stage Boundary	Review actuals, update Business Case, plan next stage, seek authorization	End stage report, next stage plan, updated backlog/forecast, lessons	Rolling into the next stage without authorization
Closing a Project	Confirm acceptance, handover, evaluate performance, capture lessons, plan benefits review	End project report, acceptance records, lessons, follow-on actions	Closure skipped because agile delivery is ongoing

PRINCE2 practices in agile projects

Practice	Agile tailoring	High-yield cue
Business Case	Validate value through releases, feedback, MVPs, benefit assumptions, and updated forecasts	Agile does not remove the need for business justification
Organizing	Combine PRINCE2 accountability with agile delivery roles; keep relationships clear	Product Owner is not automatically the Executive
Plans	Use product-based planning, backlog, release plans, stage plans, team plans, and timeboxes	Plan at the right horizon; avoid false precision
Quality	Use quality criteria, acceptance criteria, Definition of Done, reviews, tests, and built-in quality	Quality is protected, scope flexes
Risk	Use transparency, early feedback, prototypes, spikes, and the Agilometer to reduce uncertainty	Agile exposes risk; it does not ignore risk
Issues	Manage requests for change, off-specifications, problems, and concerns through appropriate authority	Backlog reprioritization still needs governance if tolerances are affected
Progress	Use burn charts, cumulative flow, demos, information radiators, checkpoints, and exception reporting	Team metrics inform governance; they do not replace it

Roles and responsibilities

Role	Core accountability	Agile tailoring	Exam cue
Executive	Owns Business Case and overall project accountability	Ensures project remains justified despite changing scope detail	If benefits fail, Executive/Project Board must be involved
Senior User	Represents those who use products and realize benefits	May work closely with Product Owner or customer representatives	User value is not the same as supplier convenience
Senior Supplier	Represents those designing, building, and supporting products	Ensures agile team capability, technical feasibility, and supplier resources	Supplier side still has governance responsibilities
Project Board	Provides direction, authorizes stages, manages by exception	Sets tolerances and enables empowered delivery	Board should not micromanage sprints
Project Manager	Manages project within tolerances on behalf of the board	Coordinates governance, risks, issues, progress, and interfaces	PM is not necessarily Scrum Master or Product Owner
Team Manager	Ensures products are delivered within agreed work package constraints	May be a delivery lead, Scrum Master-like role, or team representative depending on tailoring	Team delivery is agreed, not uncontrolled
Project Assurance	Checks business, user, and supplier interests independently of PM	Assurance may review agile controls, quality evidence, and collaboration	Assurance is not the same as doing the work
Project Support	Provides administration, configuration, tool, reporting, or logistics support	May maintain digital boards, registers, repositories, and reporting data	Support can be lightweight but still useful
Change Authority	Decides changes within delegated limits	Can enable fast backlog decisions without escalating everything	Escalate if outside delegated authority
Product Owner / customer representative	Prioritizes product backlog and clarifies value and acceptance	Works with Senior User and team; may be tailored into PRINCE2 structure	Product backlog authority is not unlimited project authority
Scrum Master / agile coach	Facilitates agile process, removes impediments, coaches team	Supports self-organization and continuous improvement	Not the Project Board and not the team’s task controller
Delivery team	Creates increments and quality evidence	Self-organizes within agreed objectives, constraints, and Definition of Done	Self-organizing does not mean self-governing project authority

Role decision matrix

Decision or problem	Usually owned by	Escalate when
Is the project still justified?	Executive / Project Board	Benefits, cost, risk, or scope tolerance is threatened
Which features are highest value within a release?	Product Owner / Senior User side, within delegated authority	Prioritization affects baselined scope or tolerance
How should the team perform technical work?	Delivery team / Team Manager	Technical decisions affect quality, risk, cost, or time tolerance
Can lower-priority scope move to a later release?	Delegated product/change authority	Must-have outcomes or tolerances are affected
Should a management stage continue?	Project Board	End stage or exception decision required
Is an increment acceptable?	Customer/user acceptance role, with quality evidence	Acceptance criteria or quality criteria are not met

Agile behaviors expected in PRINCE2 Agile

Behavior	What it looks like	Trap
Transparency	Open progress, visible risks, honest forecasts, information radiators	Hiding bad news until the end of a stage
Collaboration	Business, user, supplier, and team work together frequently	Contractual handoff mindset
Rich communication	Workshops, demos, stand-ups, visual boards, direct discussion	Assuming “less documentation” means undocumented decisions
Self-organization	Team decides how to meet agreed objectives	Team ignores project tolerances or quality criteria
Exploration	Prototypes, spikes, experiments, inspect-and-adapt learning	Endless discovery with no governance

PRINCE2 Agile focus areas

Focus area	Purpose	Practical exam use
Agilometer	Assess how suitable the environment is for agile working	Use it to tailor controls and identify risk, not as a simple pass/fail test
Requirements	Manage needs through backlogs, user stories, product descriptions, and priorities	Requirements can evolve, but Must-have outcomes need control
Rich communication	Improve speed, shared understanding, and transparency	Favor direct communication while keeping necessary records
Frequent releases	Deliver value and feedback earlier	Release often when it is valuable and safe to do so
Contracts	Make supplier arrangements compatible with collaboration and change	Rigid fixed-scope behavior can be an agile risk

Agilometer quick scan

Dimension	Agile-positive signal	Risk signal
Flexibility on what is delivered	Scope can be prioritized and flexed	Everything is mandatory and fixed
Level of collaboration	Customer, user, supplier, and team can work closely	Siloed groups and slow decision paths
Ease of communication	Direct access, co-location or effective digital collaboration	Many handoffs, unclear channels
Ability to work iteratively and deliver incrementally	Product can be built and validated in slices	Product can only be validated at the very end
Advantageous environmental conditions	Tools, culture, governance, and procurement support agile	Controls block feedback and adaptation
Acceptance of agile	Stakeholders understand and support agile behaviors	Stakeholders expect detailed upfront certainty for everything

Requirements, prioritization, and quality terms

Term	Meaning	Exam distinction
Requirement	Need or capability expected from the product	May be high level early and refined later
User story	Short requirement expression from a user/value perspective	A conversation placeholder, not a full specification by itself
Epic	Large story or requirement needing breakdown	Too large for a single timebox without refinement
Acceptance criteria	Conditions a specific item must meet to be accepted	Item-specific
Definition of Done	Shared quality checklist for completed work	Applies broadly to increments/items
Quality criteria	PRINCE2 product-specific quality expectations	Often captured in product descriptions
Product backlog	Ordered set of work or requirements	Dynamic and prioritized
Product Description	PRINCE2 description of a product’s purpose, composition, derivation, quality criteria, and method	More formal than a story when needed
MVP	Minimum viable product used to test value or learning assumptions	Minimum does not mean low quality
MMF / marketable feature	Small feature that provides user or market value	Value-oriented release slice

User story pattern:

As a [role], I want [capability], so that [benefit].

MoSCoW prioritization

Priority	Meaning	Exam guidance
Must have	Essential for the solution to be viable or acceptable	If a Must is not delivered, the timebox/release may fail
Should have	Important but a workaround or delay is acceptable	Candidate for deferral if needed
Could have	Desirable if time and capacity permit	First to drop under pressure
Won’t have for now	Explicitly out of current scope/timebox/release	Does not necessarily mean “never”

Common trap: “Must” does not mean “the stakeholder really wants it.” It means the minimum viable outcome cannot succeed without it.

Planning and artifact selection matrix

Artifact / product	Use it when	Agile-friendly form	Exam cue
Project mandate	Trigger for considering a project	Brief statement, request, strategic need	Do not start full delivery from mandate alone
Project Brief	Summarizes why and what before initiation	Lightweight vision, outline Business Case, approach	Used in Starting up a Project
Project Product Description	Defines the overall project product and acceptance expectations	Product vision plus acceptance criteria	Anchors scope and acceptance
Business Case	Justifies investment and continued viability	Updated with feedback, cost, risk, benefit assumptions	Must remain valid throughout
PID	Defines how the project will be managed	Tailored, concise, may reference agile tools	Agile still needs agreed governance
Product backlog	Ordered work to deliver value	Digital board or backlog tool	Dynamic delivery detail
Product Description	Defines a product and quality criteria	May be complemented by stories and acceptance criteria	Needed where clarity/control is important
Stage Plan	Plan for a PRINCE2 management stage	May include releases, timeboxes, tolerances	Board authorizes stages
Release Plan	Forecast of increments to be released	Roadmap or release backlog	Supports value and feedback
Team Plan / sprint backlog	Team-level delivery plan	Sprint board, Kanban board, task board	Owned close to delivery team
Work Package	Agreement between PM and Team Manager/team	Set of backlog items plus constraints, quality, reporting	Links governance to delivery
Highlight Report	PM progress report to Project Board	Summary with agile metrics and tolerance forecast	Not a task-by-task sprint report
Checkpoint information	Team progress to PM	Stand-up summary, board data, checkpoint report	Should be useful and low burden
Risk / issue records	Track threats, opportunities, problems, changes, concerns	Lightweight register or tool entries	Transparency matters
Quality evidence	Shows products meet criteria	Test results, review records, Definition of Done evidence	Quality cannot be assumed
End Stage Report	Review stage performance and readiness for next stage	Includes learning, actuals, backlog/progress evidence	Supports board decision
End Project Report	Evaluate project performance and closure	Acceptance, lessons, follow-on actions	Closure still matters in agile

Agile methods and techniques: exam-level distinctions

Method / technique	Key idea	Use when	Trap
Scrum	Fixed-length sprints, Product Owner, Scrum Master, development team, reviews, retrospectives	Product development with iterative delivery	Assuming Scrum alone provides project governance
Kanban	Visualize work, limit WIP, manage flow	Continuous flow, support, operations, variable demand	Treating Kanban as no planning
Lean	Maximize value, reduce waste, optimize flow, build quality in	Process improvement and efficient delivery	Cutting essential governance as “waste”
Lean Startup	Build-measure-learn, MVP, validated learning	High uncertainty about product or market value	MVP as low-quality shortcut
Timeboxing	Fixed duration for work and learning	Protect deadlines and force prioritization	Extending timebox instead of flexing scope
Daily stand-up	Short coordination event for the team	Identify progress, plan day, expose blockers	Status meeting for the PM
Review / demo	Inspect increment with stakeholders	Get feedback and acceptance evidence	Demo of unfinished work presented as done
Retrospective	Improve team process	Learn and adapt frequently	Blame session
Spike / prototype	Timeboxed exploration or learning	Reduce uncertainty before committing	Permanent solution without quality control

Progress and flow measures

Measure / visual	Shows	Governance use	Trap
Burn-down chart	Remaining work over time	Forecast whether timebox/release is on track	Remaining effort is not the same as value
Burn-up chart	Completed work and total scope	Shows progress plus scope change	Ignoring changing scope baseline
Velocity	Amount of accepted work completed per iteration	Forecast capacity for the same team	Comparing different teams as productivity ranking
Cumulative flow diagram	Work across workflow states	Reveals bottlenecks and WIP problems	Using it without acting on flow issues
Kanban board	Work status and flow	Transparency and coordination	Board exists but is not kept current
Information radiator	Visible project/team information	Fast shared understanding	Replaces necessary governance records
Defect trend / quality data	Quality direction	Supports acceptance and risk decisions	Hiding defects to appear faster
Lead time / cycle time	Flow speed from request to delivery or start to finish	Helps improve predictability	Treating averages as guarantees

Change and issue control in agile contexts

Situation	Good PRINCE2 Agile response	Poor response
New feature requested mid-timebox	Capture it, assess value/impact, prioritize for appropriate backlog or future timebox	Interrupt team immediately without considering impact
Change is within delegated tolerance	Product Owner/change authority may reprioritize according to agreed rules	Escalate every small change to Project Board
Change threatens stage or project tolerance	Raise issue/exception according to PRINCE2 controls	Hide impact until sprint review
User discovers a better solution	Embrace learning; update backlog and product descriptions as needed	Reject change because baseline was written earlier
Supplier says fixed scope prevents reprioritization	Treat as commercial/governance risk; seek agreed change mechanism	Ignore contract constraints
Off-specification found	Record/assess issue, decide correction or concession through authority	Quietly accept lower quality

Issue types commonly tested:

Issue type	Meaning	Agile example
Request for change	Proposal to change a baseline	Add a new feature to current release
Off-specification	Something should be provided but is missing or forecast to be missing	Must-have acceptance criterion not met
Problem / concern	Any other issue requiring management attention	Environment unavailable, team dependency blocked

“What should the manager do next?” decision table

Scenario	Best next action	Why
Timebox is behind schedule	Reassess priorities, protect Musts and quality, remove Could/Should items if needed	Time is fixed; scope is the flex point
Team forecasts stage tolerance breach	Confirm forecast, assess options, raise exception if breach remains likely	Manage by exception
Product Owner wants to drop testing to hit date	Reject lowering agreed quality; consider scope trade-off	Quality is protected
Stakeholder requests new high-value feature	Capture, assess, prioritize, and route through delegated change control	Agile embraces controlled change
Board asks for detailed task assignments	Provide product progress, forecasts, risks, and tolerance status; avoid micromanaging team tasks	Governance needs information, not task control
Team wants no documentation	Tailor documentation to minimum useful level, but retain agreed records and evidence	Agile is not absence of control
Daily stand-up exposes blocker	Team/Scrum Master handles if local; PM helps if project-level impediment	Respect self-organization while removing impediments
Business Case weakens after feedback	Update Business Case and escalate to board for decision	Continued business justification
End of stage approaching	Review actuals, lessons, risks, backlog, Business Case, and next stage plan	Board needs evidence to authorize
Customer says “everything is Must”	Challenge prioritization and define minimum viable outcome	If everything is Must, scope cannot flex

Business case, value, and benefits distinctions

Concept	Definition	Exam use
Output	Product delivered by the project	Software release, process change, service capability
Outcome	Change resulting from using outputs	Users can complete a task faster
Benefit	Measurable improvement from an outcome	Lower cost, higher revenue, reduced errors
Disbenefit	Measurable negative consequence	Increased support workload
Value	Usefulness or benefit relative to cost/risk	Guides prioritization
Continued business justification	Project remains worth doing	Must be checked throughout, not only at start

Agile strengthens Business Case control by creating earlier evidence. Feedback may confirm, change, or invalidate assumptions.

Quality control quick reference

Quality concept	Agile expression	Key point
Quality planning	Quality criteria, acceptance criteria, Definition of Done, test strategy	Agree before claiming completion
Quality control	Reviews, demos, testing, inspection, automated checks	Evidence-based, not opinion-based
Quality assurance	Independent check that processes and controls are appropriate	Not the same as testing a feature
Acceptance	User/customer confirms product meets acceptance expectations	Acceptance may happen incrementally
Built-in quality	Quality practices embedded in daily work	Avoid late “quality phase” thinking

High-yield trap: “We can fix it later” may be acceptable for consciously deferred low-priority scope, but not for claiming incomplete or poor-quality work as done.

Tailoring checklist for PRINCE2 Agile

Tailoring should be deliberate and visible in project controls.

Tailoring area	Questions to answer
Lifecycle	Predictive, iterative, incremental, agile, or hybrid?
Stages	Where should Project Board control points occur?
Releases	How often can value be safely released?
Timeboxes	What cadence supports learning and delivery?
Roles	Who owns value, governance, delivery, quality, assurance, and change decisions?
Tolerances	What are limits for time, cost, quality, scope, benefits, and risk?
Change control	What can be reprioritized locally, and what needs escalation?
Documentation	What is the minimum useful evidence for control, auditability, and communication?
Quality	What does Done mean, and who accepts products?
Communication	Which conversations, ceremonies, boards, and reports are needed?
Supplier arrangements	Do contracts support collaboration, incremental delivery, and controlled change?

Common exam traps

Trap	Better answer
Agile means no project manager	PRINCE2 still has project management accountability
Agile means no documentation	Documentation is tailored to what is useful and sufficient
Self-organizing teams can ignore governance	Teams self-organize within agreed constraints
Product Owner controls the whole project	Product Owner prioritizes product work within delegated authority
Sprint equals PRINCE2 stage	A stage is a governance period; a sprint is a delivery timebox
Change is always accepted immediately	Change is welcomed but prioritized and controlled
Quality can flex to meet deadline	Quality is protected; scope usually flexes
Velocity proves productivity across teams	Velocity is mainly for forecasting one stable team
MVP means incomplete or poor quality	MVP is minimum for learning/value and still meets agreed quality
Retrospectives replace lessons management	Retrospectives feed continuous improvement and lessons

Final cram checklist

Before practice questions, confirm you can answer:

Which PRINCE2 principle is being tested?
Is this a governance decision, delivery decision, or prioritization decision?
Are tolerances threatened?
Should the PM manage, delegate, or escalate?
Is the issue about time, cost, quality, scope, benefits, or risk?
Is the best response to flex scope, protect quality, update the Business Case, or raise an exception?
Which artifact gives the right level of control: PID, Business Case, Stage Plan, Work Package, backlog, Product Description, or report?
Is the scenario confusing a management stage with a sprint?
Is the scenario treating agile as uncontrolled change or no documentation?

Next step: use this Quick Reference to run scenario drills, then complete mixed practice questions focused on roles, tolerances, tailoring, change control, and process decisions for the PeopleCert PRINCE2 Agile Foundation (Version 2) exam.

Scenario Guide

Agile Mindset and Project Management