PMI-ACP — PMI Agile Certified Practitioner Quick Reference

Last revised: June 29, 2026

Compact PMI-ACP reference for agile roles, frameworks, planning, metrics, risks, quality, and scenario decisions.

Exam Identity and Study Lens

Item	Reference
Vendor/provider	PMI
Official title	PMI Agile Certified Practitioner (PMI-ACP)
Official code	PMI-ACP
Page purpose	Independent Quick Reference for real-exam preparation and original practice support
Best study posture	Think like an agile practitioner: servant leadership, value delivery, empirical adaptation, collaboration, transparency, and continuous improvement

PMI-ACP questions are usually scenario-based. The best answer is often the one that preserves agile values while solving the immediate problem with the least unnecessary process.

Agile Mindset: High-Yield Exam Rules

If the scenario says…	Prefer this response	Avoid this trap
Requirements are changing	Welcome change; re-prioritize backlog with the product owner/customer	Freeze scope or route every change through heavyweight approval
Team is blocked	Make impediments visible; help remove organizational blockers	Personally assign tasks or solve all technical details for the team
Stakeholder wants status	Use working product, demos, burn charts, information radiators, and transparent metrics	Long narrative status reports as the primary evidence
Quality is declining	Strengthen Definition of Done, automated tests, refactoring, pairing, root-cause analysis	Delay quality work until the end
Customer is unavailable	Re-engage, use proxy carefully, set collaboration expectations	Let the team guess business priorities
Team conflict appears	Facilitate collaboration and shared understanding	Escalate immediately unless safety, ethics, or authority boundaries require it
Product value is unclear	Clarify vision, value, personas, outcomes, and acceptance criteria	Start detailed task planning before value is understood
Estimates are unreliable	Use relative estimation, historical velocity, ranges, and inspect/adapt	Demand exact long-range predictions
Work is started but not finished	Limit WIP, swarm, remove bottlenecks	Start more work to keep everyone busy
A process is not working	Retrospect, experiment, measure, and adapt	Keep following a process because it was planned

Agile Values and Principles in Exam Language

Agile concept	What it means in scenarios	Strong answer pattern
Individuals and interactions	Collaboration beats excessive process	Facilitate direct conversation, co-location/virtual collaboration, team ownership
Working product	Real increments are the best progress measure	Demonstrate completed, accepted work
Customer collaboration	Customer feedback guides value	Involve product owner/users frequently
Responding to change	Plans are useful but adaptable	Re-prioritize backlog and update forecasts
Empiricism	Decisions use transparency, inspection, adaptation	Make work visible, inspect outcomes, adapt process/product
Servant leadership	Leader enables the team	Remove impediments, coach, protect focus, foster self-organization
Sustainable pace	Long-term delivery requires healthy flow	Avoid heroic overtime as a default solution
Simplicity	Maximize work not done	Deliver minimum viable/marketable value first
Continuous improvement	Process improves through feedback loops	Use retrospectives, experiments, metrics, root-cause analysis

Agile Roles and Accountability

Role	Primary accountability	Exam reminders
Product owner / customer representative	Value, priority, acceptance, product direction	Owns backlog ordering; clarifies acceptance criteria; accepts or rejects work
Agile team / development team	Delivering the increment; estimating work; deciding how to build	Self-organizing; cross-functional; pulls work rather than being assigned work
Scrum Master / agile coach / servant leader	Process facilitation, impediment removal, coaching, team health	Does not command the team; does not own product priority
Stakeholders	Provide feedback, constraints, domain knowledge, acceptance input	Should be engaged early and regularly
Sponsor / business owner	Strategic funding, business alignment, major constraints	Should receive outcome-focused transparency, not hidden problems
Functional manager	People management, organizational support, specialist availability	Should not override team commitments or product owner priority without collaboration

Role Decision Traps

Question asks who should…	Best answer
Prioritize backlog items	Product owner/customer representative
Estimate technical effort	Team doing the work
Decide how work is implemented	Team
Remove organizational impediments	Servant leader/agile practitioner facilitates removal, often with management support
Accept completed stories	Product owner/customer representative using acceptance criteria
Change sprint/iteration goal mid-iteration	Product owner and team collaborate; avoid disruption unless value/risk justifies it
Define Definition of Done	Team, with organizational/product quality standards considered
Facilitate retrospective	Scrum Master/agile coach/servant leader
Resolve conflict inside the team	Team first, facilitated by servant leader if needed

Framework Selection Matrix

Framework / approach	Use when…	Key practices	Exam traps
Scrum	Product work benefits from timeboxed iterations and frequent inspect/adapt cycles	Sprint/iteration planning, daily coordination, review, retrospective, product backlog	Treating Scrum Master as project boss; changing sprint scope casually
Kanban	Work arrives continuously or flow needs optimization	Visual board, WIP limits, explicit policies, flow metrics	Starting more work to increase utilization; ignoring bottlenecks
Lean	Waste reduction and value stream optimization are central	Eliminate waste, build quality in, optimize whole, deliver fast	Local optimization that harms total flow
XP	Technical quality and engineering discipline are critical	TDD, pair programming, refactoring, CI, collective ownership	Deferring technical debt or testing until the end
Hybrid agile	Some constraints require predictive elements	Tailored governance, incremental delivery, adaptive planning where possible	Calling a predictive plan “agile” without feedback, reprioritization, or increments
DSDM / feature-driven / other agile methods	Organization uses a specific agile delivery model	Timeboxing, MoSCoW, active user involvement, feature focus	Memorizing method labels without understanding value and feedback principles

Scrum-Oriented Reference

Element	Purpose	Exam focus
Product backlog	Ordered list of product work	Emergent, refined continuously, ordered by value/risk/dependency
Sprint/iteration backlog	Work selected for current timebox	Owned by team; supports sprint/iteration goal
Increment	Completed, usable product output	Must meet Definition of Done
Product goal / vision	Direction for product decisions	Helps prioritize and avoid low-value work
Sprint/iteration goal	Coherent objective for the timebox	Protects focus; not just a task list
Definition of Ready	Optional readiness guideline before pulling work	Should not become a gate that blocks collaboration
Definition of Done	Shared quality/completion standard	Prevents hidden unfinished work and technical debt
Daily standup / daily coordination	Inspect progress and adapt plan	Not a status meeting for the manager
Review / demo	Inspect product with stakeholders	Get feedback on working product
Retrospective	Inspect and improve process/team interactions	Produces improvement experiments/action items
Backlog refinement	Clarify, split, estimate, and reorder future work	Ongoing; not a one-time planning phase

Kanban and Flow Reference

Concept	Meaning	Exam use
Visual workflow	Board shows work states	Creates transparency
WIP limit	Cap on work in progress	Exposes bottlenecks and improves flow
Pull system	Team pulls work when capacity exists	Avoids overload and push scheduling
Cycle time	Time from work start to completion	Measures delivery speed for started work
Lead time	Time from request to delivery	Measures customer wait time
Throughput	Items completed per time period	Used for forecasting flow
Cumulative flow diagram	Shows work across states over time	Identifies bottlenecks, WIP growth, flow imbalance
Explicit policies	Clear rules for moving work	Reduces ambiguity and conflict
Classes of service	Different handling for work types	Useful for expedite, fixed date, standard, intangible work

Kanban Scenario Responses

Symptom	Likely issue	Best response
Many items started, few finished	Excess WIP	Enforce WIP limits; swarm to finish
One column grows rapidly	Bottleneck	Investigate constraint; rebalance skills/capacity
Urgent work disrupts flow	Poor intake/class-of-service policy	Make expedite policy explicit
Cycle time is unpredictable	Inconsistent work size or hidden blockers	Split work, visualize blockers, improve policies
Team members idle because WIP limit reached	Flow discipline is working	Help finish existing work rather than start new work

XP and Technical Quality Practices

Practice	Purpose	Exam cue
Test-driven development	Write tests before code/design implementation	Builds quality in early
Automated testing	Fast regression feedback	Supports frequent delivery
Continuous integration	Integrate often and detect defects early	Avoids late integration risk
Refactoring	Improve design without changing behavior	Controls technical debt
Pair programming	Two people collaborate on one work item	Quality, knowledge sharing, mentoring
Collective code ownership	Team owns codebase collectively	Reduces bottlenecks and silos
Simple design	Build what is needed now	Avoid overengineering
Sustainable pace	Maintain productivity and quality over time	Overtime is not a default fix
Coding standards	Shared quality conventions	Reduces variability and rework
Spikes	Timeboxed research/experiment	Reduces uncertainty before committing to solution

Value-Driven Delivery

Concept	Quick definition	Exam application
Business value	Benefit delivered to customer/organization	Prioritize high-value outcomes
MVP	Smallest viable product to test assumptions and learn	Use when uncertainty is high
MMF	Minimum marketable feature	Small releasable slice of value
MBI	Minimum business increment	Smallest increment that delivers business outcome
Value stream	Steps from idea to value delivery	Optimize whole system, not one function
Waste	Work that does not add value	Remove handoffs, waiting, overprocessing, defects, unused features
Opportunity cost	Value of the option not chosen	Consider when prioritizing scarce capacity
Cost of delay	Economic impact of waiting	Use to prioritize time-sensitive work
Incremental delivery	Deliver in usable slices	Reduces risk and gets feedback
Iterative delivery	Refine through repeated cycles	Improves fit and learning

Prioritization Methods

Method	Use when…	How it works	Trap
MoSCoW	Need simple stakeholder priority categories	Must, Should, Could, Won’t for now	Too many “Must” items
Kano	Need customer satisfaction insight	Basic, performance, excitement features	Building delight features while basics fail
WSJF	Need economic sequencing	WSJF = Cost of Delay / Job Size	Ignoring risk reduction or time criticality
Relative weighting	Need compare value/risk/cost	Score options against weighted criteria	False precision from weak data
Value vs. risk matrix	Need sequence learning	High value/high risk often early to reduce uncertainty	Saving major risks until late
Buy-a-feature	Need stakeholder tradeoff discussion	Stakeholders allocate limited budget to features	Dominant stakeholder bias
Story mapping	Need release slicing	Map user journey, then slice releases	Treating map as fixed scope

Adaptive Planning and Estimation

Planning level	Horizon	Output	Exam focus
Vision	Long range	Product direction and outcomes	Align work to strategic value
Roadmap	Medium range	Feature/release themes	Flexible forecast, not fixed promise
Release planning	Multiple iterations	Candidate scope/date forecast	Use velocity/range; update as data emerges
Iteration planning	Current timebox	Iteration goal and selected backlog items	Team commits/forecasts based on capacity
Daily planning	Current day	Coordination and adaptation	Inspect progress; surface blockers
Continuous planning	Ongoing	Backlog refinement and reordering	Respond to feedback and change

Estimation Reference

Technique	Best use	Key point
Story points	Relative size/complexity/uncertainty	Not hours; team-specific
Planning poker	Collaborative relative estimation	Discuss outliers to uncover assumptions
Affinity estimating	Quickly group many items by relative size	Useful for early backlog sizing
T-shirt sizing	Rough sizing	Good for early uncertainty
Ideal days	Effort estimate excluding interruptions	Less preferred than relative points in many agile scenarios
Wideband Delphi	Expert consensus estimate	Useful when multiple experts estimate independently then discuss
Three-point estimate	Estimate uncertainty with optimistic/most likely/pessimistic	Useful for risk-aware forecasting
Velocity	Completed points per iteration	Use historical average/range, not target imposed by management

Forecasting Formulas

Use ranges when possible. A single deterministic forecast is weaker than a transparent forecast with uncertainty.

\[ \text{Iterations Needed} = \frac{\text{Remaining Backlog Size}}{\text{Average Velocity}} \]\[ \text{Release Forecast} = \text{Current Date} + (\text{Iterations Needed} \times \text{Iteration Length}) \]\[ \text{Velocity} = \frac{\text{Completed Story Points}}{\text{Iteration}} \]

High-yield caution: velocity is a planning measure, not a productivity quota for comparing teams.

Metrics and Information Radiators

Metric / artifact	Shows	Use it to…	Common trap
Burn-down chart	Work remaining over time	Spot risk to iteration/release forecast	Treating trend as a guarantee
Burn-up chart	Work completed and total scope	Show scope changes clearly	Ignoring rising scope line
Velocity chart	Completed points by iteration	Forecast future capacity	Forcing velocity increases
Cumulative flow diagram	WIP and flow by state	Detect bottlenecks and growing queues	Looking only at total completed
Control chart	Cycle time variation	Understand predictability	Ignoring outliers/root causes
Defect trend	Defects found/fixed over time	Assess quality direction	Counting defects without root cause
Escaped defects	Defects found after release	Measure quality reaching users	Rewarding low internal reporting
Test coverage	Extent of automated/manual test coverage	Identify quality gaps	Confusing coverage with quality
Team happiness / health	Morale and sustainability	Detect burnout and dysfunction	Treating it as irrelevant “soft” data
Information radiator	Visible, current project information	Support transparency and self-management	Creating outdated display-only artifacts

Agile EVM and Core Formulas

PMI-ACP scenarios may include earned value terms. Use them only when the question gives PV, EV, AC, BAC, or similar data. Otherwise, agile-native measures such as burn charts, velocity, flow, and working product are usually more relevant.

Measure	Plain formula	Interpretation
Cost variance	CV = EV - AC	Positive is under budget; negative is over budget
Schedule variance	SV = EV - PV	Positive is ahead; negative is behind planned value
Cost performance index	CPI = EV / AC	Greater than 1 is favorable
Schedule performance index	SPI = EV / PV	Greater than 1 is favorable
Estimate at completion	EAC = BAC / CPI	Simplified cost forecast if current CPI continues
Estimate to complete	ETC = EAC - AC	Expected remaining cost
Variance at completion	VAC = BAC - EAC	Positive is favorable

\[ \text{CPI} = \frac{\text{EV}}{\text{AC}} \]\[ \text{SPI} = \frac{\text{EV}}{\text{PV}} \]

Risk, Uncertainty, and Problem Detection

Concept	Meaning	Exam response
Risk	Uncertain event that may affect objectives	Identify, analyze, respond, monitor
Issue	Current problem	Make visible, assign ownership, resolve
Impediment	Blocker reducing team progress	Servant leader helps remove it
Assumption	Belief treated as true	Validate through experiments/spikes
Spike	Timeboxed learning activity	Use for technical/product uncertainty
Risk-adjusted backlog	Backlog ordered considering risk and value	Address high-risk/high-value items early
Risk burndown	Risk exposure trend over time	Show whether uncertainty is decreasing
Root-cause analysis	Find underlying cause	Prevent recurrence, not blame
Five whys	Ask why repeatedly to find cause	Avoid stopping at symptoms
Fishbone diagram	Cause-and-effect analysis	Use for complex quality/process problems

Risk Formulas

\[ \text{Risk Exposure} = \text{Probability} \times \text{Impact} \]\[ \text{Expected Monetary Value} = \text{Probability} \times \text{Monetary Impact} \]

Response type	When appropriate	Example
Avoid	Eliminate threat	Choose simpler architecture to remove risk
Mitigate	Reduce probability or impact	Build prototype; add automated tests
Transfer	Shift impact/ownership	Contract/vendor insurance approach where suitable
Accept	Monitor without active response	Low exposure risk within tolerance
Exploit	Ensure opportunity occurs	Assign best team to high-value opportunity
Enhance	Increase probability/impact of opportunity	Add experiment to improve chance of benefit
Share	Partner to capture opportunity	Joint venture or specialist collaboration

Stakeholder Engagement and Communication

Situation	Best communication approach
Need product feedback	Demo working increment; ask targeted questions
Need priority decision	Product owner/customer conversation using value, risk, cost of delay
Stakeholder is resistant	Understand concerns; involve early; show benefits and evidence
Stakeholders disagree	Facilitate tradeoff discussion; use product vision and value criteria
Distributed team confusion	Increase communication richness: video, shared boards, working agreements
Executive wants confidence	Show trends, risks, delivered value, forecast range, and impediments
User needs are unclear	Use personas, user stories, interviews, observation, prototypes
Regulatory/constraint concern	Make constraint explicit; incorporate into acceptance criteria/Definition of Done

Communication Richness

Communication type	Richness	Best use
Face-to-face / live video	High	Ambiguity, conflict, collaboration, complex design
Workshop	High	Alignment, backlog discovery, planning
Chat / team channel	Medium	Fast coordination, simple questions
Visual board / dashboard	Medium	Shared state and transparency
Email / document	Lower	Formal record, broad distribution, non-urgent detail

Exam trap: agile favors direct, frequent, high-bandwidth communication, but it does not eliminate documentation. Documentation should be useful, sufficient, and value-adding.

User Stories and Acceptance Criteria

Item	Reference
User story format	As a [user/persona], I want [capability], so that [benefit]
Good story traits	Independent, Negotiable, Valuable, Estimable, Small, Testable
Acceptance criteria	Conditions that must be satisfied for acceptance
Story splitting	Divide by workflow step, business rule, data type, interface, persona, happy path/exception
Bad story smell	Too large, technical-only, no user value, vague acceptance, hidden dependencies

Story Examples

Weak	Better
“Build reporting module”	“As a sales manager, I want to filter pipeline by region so that I can identify underperforming territories.”
“Improve performance”	“As a mobile user, I want search results to load within the agreed threshold so that I can compare options without delay.”
“Create database table”	Usually a task, not a user story; connect it to user-visible value or technical enabler criteria

Definition of Done vs. Acceptance Criteria

Concept	Applies to	Defines	Example
Acceptance criteria	Specific backlog item/story	Product behavior or conditions for that item	User can reset password using verified email
Definition of Done	All completed work/increments	Shared quality/completion standard	Code reviewed, tests pass, documentation updated, no critical defects
Definition of Ready	Candidate backlog item before planning/pull	Readiness for team to work effectively	Clear value, acceptance criteria, dependencies understood

High-yield distinction: a story can meet its acceptance criteria but still not be “done” if it fails the team’s Definition of Done.

Agile Quality Reference

Quality practice	Prevents	Exam preference
Built-in quality	Late defect discovery	Quality is everyone’s responsibility
Automated regression testing	Repeated manual verification delays	Automate where valuable
Continuous integration	Integration surprises	Integrate frequently
TDD / test-first	Ambiguous behavior and defects	Clarifies expected behavior early
Pairing / reviews	Knowledge silos and defects	Collaborate before defects escape
Refactoring	Technical debt accumulation	Improve design continuously
Definition of Done	Hidden incomplete work	Make quality explicit
Root-cause analysis	Recurring problems	Fix system causes, not blame people
Retrospectives	Stagnant process	Inspect and adapt regularly

Servant Leadership and Team Performance

Servant leader behavior	Exam meaning
Shields team from unnecessary interruption	Protects focus and flow
Removes impediments	Helps team deliver, especially with organizational blockers
Coaches agile practices	Improves capability without command-and-control
Facilitates events	Enables participation and shared ownership
Encourages self-organization	Team decides how to do work
Promotes psychological safety	Problems surface early
Supports conflict resolution	Guides team toward collaboration
Develops team capability	Mentoring, learning, cross-functionality
Makes work visible	Transparency enables better decisions

Team Development

Stage	Symptoms	Best leadership response
Forming	Polite, uncertain, needs direction	Clarify goals, roles, working agreements
Storming	Conflict, competing views	Facilitate collaboration and norms
Norming	Shared practices emerging	Reinforce agreements and ownership
Performing	High trust and autonomy	Remove external blockers; avoid micromanagement
Adjourning	Closure or transition	Capture learning; support transition

Conflict and Collaboration

Approach	When useful	Exam caution
Collaborate / problem solve	Best default for important conflicts	Seeks win-win and root cause
Compromise	Time-limited solution when both sides can give up something	May not solve root cause
Smooth / accommodate	Preserve harmony for low-stakes issue	Can hide real disagreement
Force / direct	Emergency, safety, compliance, or authority boundary	Usually not agile default
Withdraw / avoid	Cooling-off or low-value conflict	Bad if issue is important
Facilitate	Team needs help discussing	Strong servant-leader action
Escalate	Team cannot resolve or authority is outside team	Do after reasonable collaboration, unless urgent

Change Control: Agile vs. Predictive Distinctions

Scenario	Agile response	Predictive trap
New high-value requirement appears	Product owner reorders backlog; team forecasts impact	Treat as scope failure by default
Change requested during iteration	Product owner and team discuss impact on goal; often defer to backlog	Interrupt team automatically
Stakeholder wants fixed scope/date/cost	Explain tradeoffs; use prioritization and incremental delivery	Promise all constraints without adjustment
Discovery invalidates original plan	Inspect learning and adapt roadmap/backlog	Continue plan because it was approved
External constraint changes	Make visible; re-plan with team and stakeholders	Hide impact until next formal report
Defect found in current increment	Prioritize based on severity; fix within quality policy/DoD	Ship known critical defects to preserve schedule

“What Should the Agile Practitioner Do Next?” Decision Table

Problem pattern	Best next action
Lack of shared understanding	Facilitate conversation/workshop; clarify vision, goals, acceptance criteria
Team is missing commitments	Inspect causes with team; review capacity, WIP, impediments, estimation, scope size
Product owner unavailable	Raise impact; work to restore product owner engagement or identify empowered proxy
Stakeholders bypass team with requests	Route through product owner/backlog; maintain transparency
Requirements too large	Split stories into smaller value slices
Too many defects late	Strengthen Definition of Done, automated testing, CI, root-cause analysis
Team is overallocated	Make capacity visible; reduce WIP/scope; protect sustainable pace
Estimates vary widely	Discuss assumptions; use planning poker/Delphi; resolve uncertainty
Team avoids retrospective actions	Make actions small, owned, visible, and measured
Metrics are being gamed	Reframe metrics for learning; avoid using them as individual performance weapons
Dependency blocks delivery	Visualize dependency, coordinate early, consider architectural/team changes
Customer rejects completed work	Review acceptance criteria, feedback loop, Definition of Done, and stakeholder involvement
Velocity drops	Investigate causes; do not pressure team to inflate estimates
Management demands exact long-term plan	Provide forecast range, assumptions, risks, and update cadence
Work queue grows	Limit WIP, prioritize intake, address bottleneck

Artifact Selection Quick Reference

Need	Use
Show ordered future work	Product backlog
Show current iteration work	Sprint/iteration backlog or task board
Show done vs. remaining work	Burn-down or burn-up chart
Show scope change	Burn-up chart with total scope line
Show bottlenecks	Cumulative flow diagram
Show customer journey and release slices	Story map
Show product direction	Vision statement, product roadmap
Show completion quality	Definition of Done
Show story-specific behavior	Acceptance criteria
Show risk trend	Risk burndown or risk register/radiator
Show team improvement actions	Retrospective action board
Show stakeholder influence/interest	Stakeholder map
Show decision tradeoffs	Prioritization matrix

Agile Planning Workflow

    flowchart TD
	    A[Product vision and goals] --> B[Identify users, needs, and outcomes]
	    B --> C[Create and order product backlog]
	    C --> D[Refine stories and acceptance criteria]
	    D --> E[Estimate relatively]
	    E --> F[Plan release forecast using velocity/range]
	    F --> G[Plan iteration goal and selected work]
	    G --> H[Deliver done increment]
	    H --> I[Review with stakeholders]
	    H --> J[Retrospect process]
	    I --> C
	    J --> D

Common PMI-ACP Scenario Traps

Trap answer	Why it is weak	Better agile answer
“Escalate to senior management” as first move	Skips team ownership and collaboration	Facilitate resolution; escalate only when needed
“Update the project plan and continue”	Ignores adaptation	Inspect impact and re-prioritize
“Assign tasks to team members”	Undermines self-organization	Let team pull/plan work
“Add more people immediately”	May reduce productivity and increase coordination cost	Remove blockers, reduce scope/WIP, inspect capacity
“Work overtime to meet commitment”	Unsustainable	Re-plan, prioritize, remove impediments
“Defer testing to a later phase”	Violates built-in quality	Test continuously; meet DoD
“Measure individual velocity”	Misuses metric	Use team-level metrics for forecasting and improvement
“Product owner decides technical solution”	Confuses value and implementation accountability	Product owner sets priority; team decides how
“Team decides business priority alone”	Confuses implementation and value accountability	Product owner orders backlog with stakeholder input
“Document everything in detail before starting”	Delays learning and delivery	Document enough; deliver increments and adapt
“Ignore new requirements after baseline”	Not agile	Welcome change through backlog prioritization
“Optimize one specialist’s utilization”	Can harm flow	Optimize whole-team delivery and WIP

Agile vs. Waterfall Answer Clues

Question clue	Likely agile interpretation
High uncertainty	Use adaptive planning, experiments, iterative delivery
Need early feedback	Deliver thin slices; demo often
Stable, regulated, known work	May need more upfront definition or hybrid governance
Customer can collaborate frequently	Strong fit for agile
Customer unavailable	Major agile risk; address engagement
Fixed date with flexible scope	Prioritize highest value first
Fixed scope with uncertain work	Discuss tradeoffs; use incremental risk reduction
Many handoffs	Lean waste; improve flow and cross-functionality
Frequent production defects	Quality practices and DoD need improvement
Team waiting for approvals	Bottleneck; streamline policies and empowerment

Lean Waste Reference

Waste	Agile example	Response
Partially done work	Unfinished stories, unmerged code	Limit WIP; finish before starting
Extra features	Building low-value scope	Prioritize value; validate need
Relearning	Lost knowledge, poor documentation where needed	Pairing, shared knowledge, lightweight records
Handoffs	Analyst-dev-test silos	Cross-functional teams
Delays	Waiting for approvals/environments	Remove bottlenecks
Task switching	Too many parallel efforts	WIP limits; focus
Defects	Rework from poor quality	Built-in quality, testing, root cause
Underused talent	Team not empowered	Self-organization, servant leadership

Quick Review Checklist Before Practice Questions

Can you identify who owns priority, estimation, acceptance, and process facilitation?
Can you distinguish acceptance criteria, Definition of Done, and Definition of Ready?
Can you choose between Scrum, Kanban, Lean, and XP based on scenario clues?
Can you interpret velocity, burn-down, burn-up, CFD, cycle time, and lead time?
Can you apply WIP limits when work is started but not finished?
Can you choose collaborative responses before escalation?
Can you prioritize using value, risk, dependencies, cost of delay, and learning?
Can you spot metric misuse, especially individual velocity or imposed velocity targets?
Can you explain why quality is built in rather than inspected at the end?
Can you respond to change without abandoning transparency, focus, or product ownership?

Practical Next Step

Use this Quick Reference to drill scenario questions by category: roles, prioritization, planning, metrics, risk, quality, stakeholder engagement, and team facilitation. After each missed question, identify the agile principle you violated, the role accountability you confused, or the metric/decision rule you overlooked.

Scenario Guide

Mindset