PRINCE2 Agile Foundation (Version 2) Cheat Sheet
Cheat sheet: exam-prep reference for PeopleCert PRINCE2 Agile Foundation (Version 2): principles, processes, roles, tolerances, agile tailoring, and common traps.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context
Use this Cheat Sheet 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.
Use this Cheat Sheet 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.
| 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 |
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 |
Notes and examples
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. |
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 |
Notes and examples
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 |
Notes and examples
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. |
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 |
Notes and examples
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. |
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 |
Notes and examples
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 |
Notes and examples
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? |
Notes and examples
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?
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 |
Notes and examples
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.
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 Cheat Sheet 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.
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.
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. |
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. |
Notes and examples
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.
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. |
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. |
Notes and examples
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. |
Notes and examples
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. |
Notes and examples
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. |
Notes and examples
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. |
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. |
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.