🏃 PMP Agile Mastery Guide
Comprehensive PMP Exam Prep — Agile Domain | Keywords · Examples · Scenarios · Exam Tips · Cheat Sheets
1. What is Agile?
Agile is an iterative, incremental approach to delivering projects and products. Instead of planning everything upfront (waterfall), Agile breaks work into short cycles called iterations or sprints, delivering working product frequently and adapting to change.
On the PMP exam, ~50% of questions are Agile or hybrid. Agile is about delivering VALUE early and continuously, NOT just following a process.
Agile vs. Waterfall (Predictive)
| Dimension | Agile | Waterfall (Predictive) |
|---|---|---|
| Scope | Flexible, evolving | Fixed upfront |
| Planning | Rolling-wave, iterative | Detailed upfront plan |
| Delivery | Incremental (each sprint) | Single delivery at end |
| Change | Embraced and welcomed | Controlled, minimized |
| Customer | Continuously involved | Involved at start & end |
| Team | Self-organizing, cross-functional | Specialized, hierarchical |
| Risk | Addressed early via iteration | Managed via change control |
| Documentation | Just enough | Comprehensive |
PMP prefers Agile when requirements are uncertain/changing, innovation is needed, and early delivery of value matters. Use predictive when requirements are stable and well understood.
The Agile Manifesto (2001)
The Agile Manifesto has 4 core values:
4 Agile Values — Left side is VALUED MORE
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Note: The right side still has value — but left is valued MORE.
A construction software firm was delivering bridge inspection software. Mid-project, the client realized they needed mobile-first features. An Agile team welcomed this change and re-prioritized the backlog, delivering mobile features in the next sprint without a formal change request process.
Memorize all 4 values exactly. PMP questions often flip them — remember LEFT side is preferred, but right side is NOT ignored.
12 Agile Principles
12 Principles (grouped by theme)
- Customer Value: Highest priority = satisfy customer through early & continuous delivery
- Embrace Change: Welcome changing requirements even late in development
- Frequent Delivery: Deliver working software frequently (weeks, not months)
- Collaboration: Business people & developers must work together daily
- Motivated Teams: Build projects around motivated individuals; trust them
- Face-to-Face: Most efficient = face-to-face conversation
- Working Software: Primary measure of progress
- Sustainable Pace: Agile promotes sustainable development — indefinitely
- Technical Excellence: Continuous attention to good design enhances agility
- Simplicity: Maximizing work NOT done is essential
- Self-Organizing Teams: Best architectures, requirements emerge from self-organizing teams
- Reflection & Adaptation: Team regularly reflects on how to become more effective
For the PMP exam — when asked "what does an Agile team do when?", the answer almost always involves: collaborate, reflect, adapt, or deliver incremental value. Don't pick options that involve heavy documentation or rigid process.
2. Agile Frameworks
Multiple frameworks implement Agile values. The PMP exam primarily tests Scrum, Kanban, and understanding of scaled frameworks.
Scrum
Most widely used Agile framework. Based on empiricism (transparency, inspection, adaptation). Delivers in fixed-length sprints (usually 1–4 weeks).
Kanban
Kanban is a flow-based system. Work items are pulled as capacity allows. No fixed sprints. Uses a Kanban board with columns (To Do → In Progress → Done) and enforces WIP limits.
Kanban Core Practices
- Visualize workflow (Kanban board)
- Limit WIP (Work In Progress)
- Manage flow
- Make policies explicit
- Implement feedback loops
- Improve collaboratively
An IT support team uses Kanban. Tickets flow from "Received" → "In Progress" → "Testing" → "Done." WIP limit of 3 in "In Progress" prevents overload. New tickets are pulled only when capacity opens.
Extreme Programming (XP)
XP focuses on technical practices and software quality. Key practices:
Pair ProgrammingTwo devs, one keyboard — real-time code review
TDDTest-Driven Development — write tests BEFORE code
Continuous IntegrationIntegrate and test code multiple times/day
RefactoringContinuously improve code structure
Collective OwnershipAnyone can improve any code
40-Hour WeekSustainable pace; no overtime
SAFe / LeSS (Scaled Frameworks)
| Framework | Full Name | Key Feature |
|---|---|---|
| SAFe | Scaled Agile Framework | Program Increment (PI) Planning, Agile Release Trains (ARTs) |
| LeSS | Large-Scale Scrum | One Product Owner, multiple Scrum teams, one Product Backlog |
| Nexus | Nexus Integration | Nexus Integration Team manages cross-team dependencies |
| Disciplined Agile | DA (PMI's own) | Choose your own way of working (WoW), context-driven |
PMP exam focuses most on Scrum and Kanban mechanics. For scaled frameworks, know that SAFe uses PI Planning and ARTs. Disciplined Agile (DA) is PMI's framework — "Choose Your WoW."
3. Scrum Deep Dive
Scrum Roles
Product Owner (PO)
Represents the customer. Owns & prioritizes the Product Backlog. Maximizes product value. Says YES/NO to features. One person, not a committee.
Scrum Master (SM)
Servant-leader. Coaches Agile practices. Removes impediments. Facilitates events. Protects team from outside interference. NOT a project manager.
Development Team
Self-organizing, cross-functional. 3–9 members. Decides HOW work is done. Owns the sprint. No sub-teams or titles.
A stakeholder directly assigns work to a developer during a sprint. The Scrum Master should: SHIELD the team, redirect the stakeholder to the Product Owner, and address the issue at the next Sprint Retrospective. The team self-organizes — no one outside assigns tasks.
In PMP exams: if a question describes a PM behaving like a traditional boss in an Agile team — that's WRONG. An Agile PM (or SM) serves the team, removes blockers, and coaches. They do NOT command.
Scrum Events (Ceremonies)
| Event | Who | When | Duration (2-wk sprint) | Purpose |
|---|---|---|---|---|
| Sprint Planning | Whole Scrum Team | Start of sprint | ≤4 hours | Select backlog items; define Sprint Goal |
| Daily Scrum | Dev Team | Daily, same time | 15 min | Sync, plan next 24 hrs, identify blockers |
| Sprint Review | Team + Stakeholders | End of sprint | ≤2 hours | Demo working product; gather feedback |
| Sprint Retrospective | Scrum Team | After Review | ≤1.5 hours | Inspect process; improve HOW team works |
| Backlog Refinement | PO + Dev Team | During sprint | ≤10% sprint time | Detail, estimate, re-order backlog items |
Remember: Sprint Review = WHAT was built (product). Sprint Retrospective = HOW the team worked (process). Many exam questions confuse these two!
During a Sprint Review, the team discovers a critical bug. What should the Scrum Master do? → Add it to the Product Backlog and let the PO prioritize it for the next sprint. Do NOT stop the current sprint — bugs are backlog items unless they block the sprint goal entirely.
Scrum Artifacts
Product Backlog
Ordered list of all features, fixes, requirements. Owned by PO. Never complete — evolves. Each item = User Story.
Sprint Backlog
Subset of Product Backlog selected for the sprint + plan to deliver increment. Owned by Dev Team. Changes during sprint only by team.
Increment
Sum of all completed backlog items — must meet Definition of Done. Potentially shippable product.
Artifact Commitments (Scrum 2020)
- Product Backlog → Product Goal (long-term objective)
- Sprint Backlog → Sprint Goal (objective of this sprint)
- Increment → Definition of Done (quality standard)
Sprint Lifecycle
Sprint Lifecycle Flow:
Product Backlog → [Sprint Planning] → Sprint Backlog → [Daily Scrums during sprint] → [Sprint Review] → Increment → [Sprint Retrospective] → Next Sprint Planning
Product Backlog → [Sprint Planning] → Sprint Backlog → [Daily Scrums during sprint] → [Sprint Review] → Increment → [Sprint Retrospective] → Next Sprint Planning
A sprint should NEVER be extended or cancelled due to incomplete work — incomplete items return to the Product Backlog. Only the PO can cancel a sprint (rare — if Sprint Goal becomes obsolete).
4. Agile Planning
Agile uses rolling-wave planning — planning in detail only for the near term, with rough estimates for the future.
Release Planning & Iteration Planning
| Level | Horizon | Detail Level | Owner |
|---|---|---|---|
| Portfolio / Product Vision | Years | Very high-level | Executives / PO |
| Release Plan | Months (3–6) | Features, milestones | PO + Team |
| Iteration Plan (Sprint) | 1–4 weeks | Stories, tasks | Dev Team |
| Daily Plan | 24 hours | Task-level | Dev Team |
Story Points & Velocity
Story Points are a relative measure of effort, complexity, and risk — NOT hours. Velocity = average story points completed per sprint.
Team A completed 20, 24, 18 story points in the last 3 sprints. Velocity = (20+24+18)/3 = 20.7 ≈ 21 points/sprint. If 200 story points remain in the backlog, estimated sprints remaining = 200/21 ≈ 10 sprints.
Never promise exact story point completion — velocity is an average, not a commitment. Use it for forecasting, not performance measurement.
Backlog Refinement (Grooming)
An ongoing activity (not a formal Scrum event) where the PO and team review, clarify, estimate, and re-order backlog items. Should consume no more than 10% of sprint time.
INVEST Criteria for Good User Stories
- Independent — can be developed separately
- Negotiable — not a fixed contract
- Valuable — delivers value to user/customer
- Estimable — team can estimate effort
- Small — fits in a single sprint
- Testable — has clear acceptance criteria
If a PMP question asks about a user story that's "too large to complete in one sprint," the answer is to SPLIT it (decompose into smaller stories). A story too large is called an EPIC.
5. Agile Estimation Techniques
Planning Poker
Team members simultaneously reveal estimate cards (Fibonacci: 1, 2, 3, 5, 8, 13, 21…). Outliers explain reasoning. Repeat until consensus.
PM Ahmad's team is estimating a new bridge inspection reporting module. Dev A says 5 points, Dev B says 13. They discuss — Dev B reveals the module requires API integration they hadn't considered. After discussion, team agrees on 8 points.
Planning Poker leverages the wisdom of crowds and reduces anchoring bias. It's a form of Wideband Delphi.
T-Shirt Sizing
Quick estimation using sizes: XS, S, M, L, XL, XXL. Good for initial backlog sizing when detail is limited.
Affinity Estimation
Team quickly groups stories by relative size (small, medium, large) without discussion first, then reviews outliers. Very fast for large backlogs.
Fibonacci Sequence in Estimation
1, 2, 3, 5, 8, 13, 21, 34, 55, 89… The increasing gaps force teams to acknowledge uncertainty in larger items. Items estimated at 21+ should likely be broken down.
6. Agile Metrics & Reporting
Burndown Chart
Shows remaining work over time. Ideal line goes from total story points at sprint start to zero at end. Actual line shows real progress.
Sprint starts with 40 points. After 5 days, ideal remaining = 20. Actual = 28. Team is BEHIND. Scrum Master facilitates discussion at next Daily Scrum to address impediments.
A Burnup Chart shows completed work and scope over time — better for showing scope changes.
Velocity
Story points completed per sprint. Used for release forecasting. Never use velocity to compare teams — each team's points are relative to themselves.
If velocity drops unexpectedly → investigate impediments, team stability, or scope creep. If velocity spikes → check if team is gaming metrics or reducing quality.
Lead Time & Cycle Time
| Metric | Definition | Starts When | Ends When |
|---|---|---|---|
| Lead Time | Total time from request to delivery | Request created | Work delivered |
| Cycle Time | Time from start of work to delivery | Work begins | Work delivered |
A user story enters the backlog Monday. Work starts Thursday. Delivered the following Tuesday. Lead Time = 9 days. Cycle Time = 6 days.
Cumulative Flow Diagram (CFD)
Shows number of items in each workflow state over time. Bands widening = bottleneck. Used in Kanban to identify flow problems.
For PMP: If a Kanban CFD shows the "In Progress" band widening → WIP limit is likely being violated or there's a bottleneck. Solution: reduce WIP, investigate the constraint.
7. Servant Leadership in Agile
In Agile, the PM or Scrum Master acts as a servant-leader — serving the team's needs, NOT commanding them.
PM Role in Agile
CoachDevelops team capabilities; teaches Agile practices
FacilitatorEnables ceremonies; promotes collaboration
ServantRemoves obstacles; serves team needs first
ProtectorShields team from distractions and interference
A senior manager tells you to reassign two developers mid-sprint to work on another project. As Agile PM, you should: 1) Explain impact on sprint goal, 2) Involve PO and stakeholders, 3) If unavoidable, consider closing the sprint early (only PO can do this). Never silently comply — protecting the sprint is your duty.
Coaching & Facilitation
Agile leaders use coaching (asking questions to develop capability) vs. mentoring (sharing expert knowledge). Both are valuable at different times.
Removing Impediments
Scrum Master's #1 job. Impediments are anything blocking the team from progress. Tracked on an impediment board.
Team is blocked because the testing environment is down. Scrum Master escalates to IT immediately, tracks it on the impediment board, and daily monitors resolution. Does not wait for next sprint.
Scrum Master raises impediments quickly — time matters in 2-week sprints. They don't solve all problems themselves, but ensure the right people do.
8. Hybrid Approaches
Most real-world projects use a hybrid approach — combining predictive and Agile practices based on context.
When to Use Hybrid
| Situation | Approach |
|---|---|
| Core infrastructure (stable) + UI features (evolving) | Predictive for infrastructure, Agile for features |
| Regulatory requirements (fixed) + innovation needs | Predictive compliance, Agile delivery |
| Large teams with multiple vendors + internal dev team | Predictive contracts + internal Agile sprints |
Predictive + Agile Mix
A bridge rehabilitation project (Ahmad's domain): The structural analysis phase follows predictive (fixed scope, regulatory approvals needed). The inspection reporting software deliverable uses Agile sprints. Combined = Hybrid.
PMP exam loves hybrid. When asked "what approach?" look for: stable vs. uncertain requirements, regulatory constraints, team expertise, customer involvement levels. Match the approach to the CONTEXT.
9. Agile Mindset
Growth Mindset
Agile teams embrace failure as learning. A growth mindset means believing skills and intelligence develop through effort, feedback, and persistence. Opposite = fixed mindset (talent is innate).
Empiricism
Scrum is founded on empiricism — decisions based on observation and experience, not theory. Three pillars:
TransparencyAll work visible to everyone; no hidden information
InspectionRegularly check progress toward the Sprint/Product Goal
AdaptationAdjust process or product when inspection reveals problems
Continuous Improvement (Kaizen)
Kaizen = Japanese for "change for better." In Agile, the Sprint Retrospective is the primary vehicle for continuous improvement. Teams commit to at least one actionable improvement per retrospective.
If a PMP question asks "how does Agile improve quality?" → the answer involves inspect-and-adapt cycles, retrospectives, and continuous feedback — NOT a quality audit by an external team.
10. Stakeholder Engagement in Agile
Customer Collaboration
Agile teams keep the customer continuously involved. The Product Owner is the primary customer voice. The team delivers value every sprint and gathers continuous feedback.
A client says "I'll know what I want when I see it." Agile is PERFECT for this — build a small piece, show it in Sprint Review, get feedback, adjust. This is exactly why working software beats comprehensive specifications.
Demos and Sprint Reviews
Sprint Review is NOT a status meeting — it's a working product demo. Stakeholders see real software, give feedback, and the PO updates the backlog accordingly.
Sprint Review vs Sprint Retrospective
- Sprint Review: WHAT was built — product demo, stakeholder feedback, backlog update
- Sprint Retrospective: HOW team worked — process improvement, team dynamics
The PO ACCEPTS or REJECTS completed items at the Sprint Review based on Definition of Done and acceptance criteria — NOT personal preference.
11. Risk Management in Agile
Risk-Based Spikes
A spike is a time-boxed research sprint dedicated to answering a specific technical or business question — reducing uncertainty (risk). Result = knowledge, not product increment.
Team unsure if a new API can handle real-time bridge sensor data. They run a 2-day technical spike. Result: confirmed feasibility with performance benchmark. Spike is then closed; user stories are written based on the finding.
Risk Burndown Chart
Similar to a work burndown — tracks reduction in risk exposure over time. Each sprint should reduce total risk. If risk goes up unexpectedly → investigate and respond.
Agile Risk Response Strategies
- Avoid: Remove the risk condition (descope risky feature)
- Mitigate: Run a spike to understand and reduce probability
- Transfer: Use a vendor or cloud service to shift risk
- Accept: Note it, monitor it, address when triggered
- Escalate: Risk beyond team control → raise to PO / sponsor
Agile inherently reduces risk through short cycles — you discover problems EARLY when they're cheap to fix. This is a key advantage over waterfall (where risk surfaces late).
12. PMP Agile Cheat Sheets
Key Numbers & Formulas
Must-Memorize Agile Numbers
| Item | Value |
|---|---|
| Scrum Team size | 3–9 developers + PO + SM |
| Sprint length | 1–4 weeks (most common: 2 weeks) |
| Daily Scrum duration | 15 minutes |
| Sprint Planning (4-wk sprint) | ≤8 hours |
| Sprint Review (4-wk sprint) | ≤4 hours |
| Sprint Retrospective (4-wk sprint) | ≤3 hours |
| Backlog Refinement time | ≤10% of sprint capacity |
| Agile Manifesto Values | 4 values |
| Agile Principles | 12 principles |
| Fibonacci sequence (planning) | 1,2,3,5,8,13,21,34,55,89 |
| Velocity formula | Avg story points/sprint (last 3 sprints) |
| Release forecast | Remaining points ÷ Velocity = sprints left |
Quick Reference: All Key Concepts
| Concept | One-Line Definition | Exam Trap |
|---|---|---|
| Sprint Goal | Why the sprint exists — the objective | Sprint Goal ≠ Sprint Backlog (list of tasks) |
| Definition of Done | Quality standard for a "complete" increment | DoD is set by the team, not PO alone |
| Acceptance Criteria | Conditions a story must meet to be accepted | Set by PO/stakeholders for EACH story |
| Epic | Large user story that must be split | Epics don't fit in one sprint |
| Theme | Group of related epics/stories | Themes are strategic, not sprint-level |
| Velocity | Avg points per sprint | Never compare velocities across teams |
| WIP Limit | Max items in any workflow state (Kanban) | WIP limits improve flow, reduce multitasking |
| Spike | Time-boxed research task | Spike result = knowledge, not shippable product |
| Pair Programming | Two devs, one code (XP) | Reduces defects, not a waste of resources |
| Continuous Integration | Merge/test code multiple times/day | Reduces integration risk |
13. Practice Quiz — Agile PMP
Q1. During a Sprint Review, stakeholders request a major new feature. What should happen?
A. Add it to the current Sprint Backlog immediately
B. Add it to the Product Backlog and let the PO prioritize it
C. Reject it because the sprint has already started
D. Document it in the project change log and submit a change request
Q2. Your Agile team's velocity has been 25 points/sprint. The product backlog has 200 remaining points. How many sprints are needed?
A. 6 sprints
B. 7 sprints
C. 8 sprints
D. 10 sprints
Q3. A developer approaches the Scrum Master saying they don't know which task to work on. What should the SM do?
A. Assign the highest priority task from the Sprint Backlog
B. Coach the developer to self-organize and choose from the Sprint Backlog
C. Escalate to the Product Owner to assign tasks
D. Create a task assignment matrix for the team
Q4. The Agile Manifesto values "Working software over ___?"
A. Customer collaboration
B. Responding to change
C. Comprehensive documentation
D. Contract negotiation
Q5. Which Scrum event is used to inspect the PROCESS (not the product)?
A. Sprint Review
B. Daily Scrum
C. Sprint Retrospective
D. Sprint Planning
Q6. A Kanban team notices the "In Progress" column keeps growing beyond its WIP limit. What should they do?
A. Increase the WIP limit to accommodate more work
B. Add more team members immediately
C. Investigate the bottleneck and stop starting new work until items are completed
D. Split tasks into smaller pieces to clear the column
Q7. Which Agile estimation technique uses Fibonacci numbers and consensus-based discussion?
A. T-Shirt Sizing
B. Planning Poker
C. Affinity Estimation
D. Three-Point Estimating
Q8. What is a "Spike" in Agile?
A. An unexpected increase in team velocity
B. A type of retrospective technique
C. A time-boxed research task to reduce uncertainty
D. A bug that blocks the sprint
14. My Study Notes (Auto-Save)
Use the space below to write your personal notes. They save automatically to your browser.
General Agile Notes
Scrum Notes
Exam Day Reminders
15. Team Dynamics & Motivation
PMP exam heavily tests motivation theories and team development. Agile teams are most productive when they are self-organizing, trusted, motivated, and psychologically safe.
Tuckman's Team Development Model
Tuckman's model describes the stages every team goes through:
| Stage | What Happens | PM/SM Action |
|---|---|---|
| Forming | Team meets; polite, uncertain, dependent on leader | Direct — give clear goals and structure |
| Storming | Conflict emerges; personalities clash; resistance | Coach — facilitate conflict resolution; build trust |
| Norming | Team finds rhythm; collaboration improves; norms set | Support — encourage; step back |
| Performing | High performance; self-organizing; focus on goals | Delegate — minimal intervention |
| Adjourning | Project ends; team disbands; celebrate success | Recognize contributions; lessons learned |
PMP questions describe team behaviors — identify the Tuckman stage and choose the correct PM response. Storming = conflict → don't avoid it, facilitate it. Performing = step back and let them work.
Mid-project, two developers constantly argue about technical approaches and meetings are tense. This team is in the STORMING stage. The Agile PM should facilitate open discussion, establish ground rules, and help the team find compromise — not reassign members or escalate to management immediately.
Maslow's Hierarchy of Needs
Maslow's 5 Levels (bottom to top)
- Physiological — Salary, safe work environment, basic needs
- Safety — Job security, health insurance, stable environment
- Social/Belonging — Team belonging, friendships, collaboration
- Esteem — Recognition, achievement, respect from peers
- Self-Actualization — Growth, creative work, reaching full potential
If a PMP question says "no one recognizes their work" → Esteem need is unmet. Solution: recognition programs, shout-outs in retrospectives, visible team achievements. Lower needs must be met first before higher ones matter.
Herzberg's Two-Factor Theory & McGregor's X/Y
Herzberg — Hygiene FactorsSalary, working conditions, policies. Absence = dissatisfied. Presence does NOT motivate. Pay alone won't motivate a team.
Herzberg — MotivatorsAchievement, recognition, responsibility, growth. These ACTIVELY motivate. Agile job design targets these.
McGregor Theory XAssumes workers are lazy, avoid responsibility, need control. Traditional command-and-control style.
McGregor Theory YAssumes workers are self-motivated, seek responsibility. Foundation of Agile servant leadership. Agile = Theory Y.
McClelland's TheoryNeed for Achievement (nAch), Affiliation (nAff), Power (nPow). High achievers take moderate risks — typical Agile developer profile.
Expectancy Theory (Vroom)Motivation = Expectancy × Instrumentality × Valence. People are motivated when effort → performance → valued reward.
Agile = Theory Y. A PM micromanaging an Agile team is applying Theory X — wrong. When PMP asks about motivation: emphasize autonomy, mastery, and purpose (intrinsic motivation over external rewards).
16. Agile Contracts
Traditional fixed-price contracts conflict with Agile's embrace of change. PMP exam tests understanding of contract types that support Agile delivery.
Agile-Friendly Contract Types
| Contract Type | Description | Best For | Risk Holder |
|---|---|---|---|
| Time & Materials (T&M) | Pay for actual time + materials. No fixed scope. | Evolving scope, innovation | Buyer |
| Fixed-Price Iterative | Fixed price per sprint; overall product evolves | Agile with budget certainty | Shared |
| Not-to-Exceed (NTE) | T&M with a cap on maximum spend | Budget-limited Agile | Seller (above cap) |
| Firm Fixed Price (FFP) | Fixed scope, schedule, price — least flexible | Stable, well-defined requirements | Seller |
| CPFF | Actual costs + fixed fee. Minimal seller risk. | R&D, exploratory work | Buyer |
Contract Scenarios
Company wants AI-powered inspection tool but isn't sure of all features. Best contract? → Time & Materials — allows scope to evolve sprint by sprint. Fixed-price forces premature scope definition.
Government agency needs Agile delivery but requires a fixed budget. → NTE (Not-to-Exceed T&M) or Fixed-Price Iterative. Each sprint has defined deliverables at fixed cost; overall roadmap can flex.
Agile Contract Principles
- Favor collaboration over adversarial relationships
- Include customer in the team where possible
- Build in flexibility (change budgets, iteration-by-iteration pricing)
- Define acceptance criteria at sprint level
- "Money for nothing, change for free" — allow scope swaps of equal size without penalty
PMP contract + Agile questions: favor answers emphasizing collaboration, flexibility, and value. Avoid rigid enforcement, penalties for change, or adversarial posturing.
17. MoSCoW Prioritization
MoSCoW is a prioritization technique used by Product Owners to categorize backlog items by necessity.
The Four MoSCoW Categories
M — Must HaveNon-negotiable. Without these, the product FAILS. Core MVP features. If not delivered, release is cancelled.
S — Should HaveImportant but not critical. Painful to omit. High priority for next release if not in MVP.
C — Could HaveNice to have. Include if time/budget allows. First to drop under pressure.
W — Won't HaveOut of scope THIS release. Not never — just not now. Prevents scope creep by making exclusions visible.
Bridge Inspection App: Must Have = login, inspection form, photo upload. Should Have = GPS tagging, offline mode. Could Have = dark mode. Won't Have = AI auto-analysis (future version).
Won't Have items still go to backlog for future releases — they are NOT deleted. MoSCoW is for RELEASE planning; "Won't Have" is a scheduling decision, not a rejection.
Other Prioritization Methods
| Method | How It Works | Best Use |
|---|---|---|
| WSJF | (Cost of Delay) ÷ (Job Duration). Prioritize highest ratio. | SAFe — maximize flow efficiency |
| Kano Model | Basic / Performance / Excitement features (see Section 24) | Customer satisfaction focus |
| 100-Point Method | Stakeholders distribute 100 points across items | Stakeholder-driven prioritization |
| Risk-Value Matrix | High-value, high-risk items go first | Hybrid / uncertain projects |
| Dot Voting | Sticker dots on priority items | Quick group consensus |
18. Definition of Ready (DoR) vs. Definition of Done (DoD)
Two critical quality gates — one at the ENTRY of work, one at the EXIT.
Definition of Ready (DoR)
Definition of Ready is a checklist a User Story must satisfy BEFORE being pulled into a sprint. Prevents mid-sprint blockers.
Typical DoR Checklist
- ✅ Story written in proper format (As a… I want… So that…)
- ✅ Acceptance criteria defined and agreed upon
- ✅ Story estimated in story points
- ✅ Dependencies identified and resolved
- ✅ Story fits within one sprint
- ✅ Team understands the story (no open questions)
- ✅ UI/UX designs available if applicable
- ✅ Technical approach agreed upon
DoR vs. DoD Comparison
| Dimension | Definition of Ready (DoR) | Definition of Done (DoD) |
|---|---|---|
| Purpose | Entry gate — story ready to START | Exit gate — story COMPLETE |
| Timing | Before Sprint Planning | End of sprint |
| Owner | Product Owner (with team input) | Scrum Team (Dev Team + SM) |
| Risk if ignored | Team gets blocked mid-sprint | Technical debt accumulates |
| Analogy | Runway before takeoff | Landing gear down before landing |
During Sprint Planning, the team selects a story but acceptance criteria haven't been written. Per DoR — this story is NOT ready. Send it back to the PO for refinement before the next sprint.
DoR prevents mid-sprint blockers. DoD prevents technical debt. BOTH are team agreements — never imposed externally on a self-organizing team.
19. Retrospective Techniques
The Sprint Retrospective is the engine of continuous improvement. PMP exam tests these techniques by name.
Start / Stop / Continue
STARTNew practices to begin (e.g., "start doing code reviews before merging")
STOPPractices hurting the team (e.g., "stop accepting stories without acceptance criteria")
CONTINUEThings working well (e.g., "continue daily standups at 9 AM")
Mad / Sad / Glad & 4Ls
Mad / Sad / GladTeam shares feelings about the sprint. Mad = frustrations. Sad = disappointments. Glad = celebrations. Builds emotional safety and surfaces hidden issues.
4Ls Retrospective
- Liked — what went well
- Learned — new insights
- Lacked — what was missing
- Longed For — what team wishes they had
Sailboat / Fishbone & More
Sailboat / SpeedboatWind = things propelling forward. Anchors = things slowing down. Rocks = upcoming risks. Island = goal/vision.
Fishbone (Ishikawa)Root cause analysis. Categories: People, Process, Technology, Environment. Used when a specific problem needs deep investigation.
5 WhysAsk "Why?" 5 times to reach root cause. Simple and powerful for recurring problems.
KALMKeep / Add / Less / More. More nuanced than Start/Stop/Continue.
Retrospective Prime Directive (Norm Kerth)
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time..."
Creates psychological safety — no blame, only learning.
Every retrospective must produce at least ONE actionable improvement committed to by the team. SM facilitates; TEAM owns the improvements. If no improvements are committed — the retro failed.
20. Information Radiators & Agile Communication
Information radiators are large, visible displays of project status that anyone can see without asking — promoting transparency.
Common Information Radiators
Task Board (Kanban Board)Columns: To Do / In Progress / Done. Each card = one story or task. Updated daily. Complete sprint visible at a glance.
Burndown ChartPosted on team wall. Shows sprint progress daily. Anyone can see if team is on track.
Velocity ChartBar chart of story points per sprint. Shows trend over time. Used for release forecasting.
Release BurndownTracks remaining backlog across sprints toward release. Big-picture progress view.
Impediment BoardLists current blockers, owner, status. Makes problems visible. Drives accountability.
Team Capacity CalendarSprint capacity, vacations, holidays. Enables realistic sprint planning.
Osmotic Communication
Osmotic communication is the natural absorption of information through proximity — team members overhear and absorb relevant context without formal meetings. Best with co-located teams; requires deliberate effort for distributed teams.
Agile Communication Preference Order
- Face-to-face (best — osmotic, highest bandwidth)
- Video call
- Phone / voice
- Instant messaging (Slack, Teams)
- Written documents (least preferred for daily comm)
Agile Manifesto: "Most efficient method = face-to-face conversation." On PMP exam, always prefer face-to-face over email or formal status reports when communicating with the Agile team.
21. Agile Quality Practices
In Agile, quality is built in — not inspected at the end. The entire team owns quality.
Built-in Quality Practices
Continuous Integration (CI)Developers merge code multiple times/day. Automated tests run on every merge. Catches integration errors immediately.
Continuous Delivery (CD)Code always in deployable state. Every build passes automated tests and can be released anytime.
Code ReviewsEvery change reviewed by at least one developer before merging. Catches bugs, shares knowledge, enforces standards.
Automated TestingUnit, integration, regression tests run automatically. Enables safe refactoring and fast feedback.
RefactoringContinuously improve code structure without changing behavior. Prevents technical debt accumulation.
Definition of DoneQuality gate ensuring every increment meets team standard before considered complete.
TDD (Test-Driven Development) Cycle
Red → Green → Refactor
- RED — Write a FAILING test first (before any code)
- GREEN — Write minimum code to make test pass
- REFACTOR — Clean up code while all tests stay green
- Repeat for every new feature or behavior
Developer builds bridge data validation. TDD: writes test "validateBridgeID('BR-001') returns true." Test FAILS (no function yet = RED). Writes function, test passes = GREEN. Refactors for edge cases, tests still pass = REFACTOR. ✅
Acceptance Criteria vs. DoD
| Dimension | Acceptance Criteria | Definition of Done |
|---|---|---|
| Scope | Story-specific | All stories / increment-wide |
| Owner | Product Owner | Scrum Team |
| Purpose | What THIS story must do | Quality standard for ALL work |
Story meets acceptance criteria BUT fails DoD → NOT done. Both must be satisfied. PO verifies acceptance criteria; team enforces DoD. No exceptions.
22. User Story Mapping
User Story Mapping (Jeff Patton) organizes stories into a 2D map that tells the user journey and guides release planning.
Story Map Structure
Two-Dimensional Layout
Horizontal (X-axis): User activities in sequential order — the narrative flow / user journey
Vertical (Y-axis): Priority — stories higher up = earlier releases
| → Backbone: User Activities (left to right) | |||
|---|---|---|---|
| Release 1 — Walking Skeleton (minimum working system) | |||
| Login | Create Record | Save Data | View Records |
| Release 2 — Enhanced features | |||
| OAuth Login | Photo Attach | GPS Tag | Filter/Search |
| Release 3 — Advanced features | |||
| SSO | AI Suggestions | Offline Mode | Analytics |
Walking Skeleton
A walking skeleton is the thinnest possible end-to-end working slice of the system. Validates architecture before building full features.
Bridge inspection app walking skeleton: User can log in → create basic inspection record → save → view saved records. No photos, no GPS, no reports — just the core flow working end-to-end. Proves the system works before investing more.
Story mapping prevents building isolated stories without coherent user experience. It aligns the team on product narrative and surfaces gaps in the backlog that might otherwise be discovered too late.
23. Working Agreements & Team Charter
Agile teams establish shared norms and expectations early — created BY the team, not imposed on them.
Team Charter
A Team Charter defines team purpose, values, agreements, and working norms. Created collaboratively. Living document — updated as team evolves.
Team Charter Contents
- Team Purpose — Why does this team exist?
- Team Values — Transparency, quality, respect
- Working Hours — Core overlap hours, time zones
- Communication Norms — Response times, preferred channels
- Decision-Making — Consensus, vote, or SM decides?
- Conflict Resolution — How are disagreements handled?
- Definition of Done — Shared quality standard
- Celebration Rituals — How do we recognize success?
Ground Rules & Consensus Tools
Fist of FiveConsensus check: 1-5 fingers. 5=fully support, 3=can live with it, 1=strong objection. Quickly identifies concerns without long debate.
Team NormsHow to handle late attendees, how to give feedback, pull request standards, code ownership expectations.
Ahmad's team ground rules: "Standups at 9:00 AM sharp. Slack for daily comm — respond within 2 hours. No blame in retros. Flag blockers immediately — not at sprint end."
Working agreements reduce time in Storming. If PMP asks how to resolve ongoing team conflict → revisit and update working agreements first. Don't escalate to management unless team-level resolution fails.
24. Kano Model — Feature Prioritization
The Kano Model (Noriaki Kano) classifies product features by their relationship to customer satisfaction. POs use it to maximize customer delight.
Feature Categories
Basic (Must-Be)Expected features. Absence = very dissatisfied. Presence = neutral (not exciting). Example: brakes on a car, login on a web app.
Performance (Linear)More = more satisfied; less = less satisfied. Customers explicitly request these. Example: battery life, app speed, storage.
Excitement (Delighter)Unexpected. Customers didn't ask but love when present. Absence = neutral. Example: first trackpad gestures, first phone camera.
IndifferentCustomers don't care either way. Drop from backlog — no value added.
ReverseSome customers are UNHAPPY when present. Only wanted by a segment.
PO Usage of Kano
| Category | If Present | If Absent | Backlog Priority |
|---|---|---|---|
| Basic | Neutral | Dissatisfied | First — MVP requirement |
| Performance | More satisfied | Less satisfied | High — directly improves value |
| Excitement | Delighted | Neutral | Medium — differentiation |
| Indifferent | Neutral | Neutral | Low / drop |
Bridge inspection app: Basic = login, save. Performance = faster sync, better search. Excitement = AI-suggested findings, predictive maintenance alerts. PO delivers Basics first (MVP), then Performance, then Exciters.
Excitement features BECOME Performance over time (today's delight = tomorrow's expectation). This is why Agile teams continuously innovate — the PO must constantly discover new exciters to stay ahead of competition.
25. PMBOK 7 + Agile — Performance Domains
The PMP exam (post-2021) is based on PMBOK 7th Edition which shifted from process groups to 8 Performance Domains — intentionally framework-agnostic, supporting Agile, hybrid, and predictive.
8 Performance Domains
| # | Domain | What It Covers | Agile Connection |
|---|---|---|---|
| 1 | Stakeholders | Engaging and managing stakeholder expectations | Continuous collaboration, Sprint Reviews, PO |
| 2 | Team | Building effective project teams | Self-organizing teams, servant leadership, Tuckman |
| 3 | Development Approach & Life Cycle | Selecting predictive, adaptive, or hybrid | Tailoring: when to use Agile vs waterfall |
| 4 | Planning | Estimating, scheduling, resource planning | Rolling-wave, velocity, iteration planning |
| 5 | Project Work | Executing work, managing procurement | Sprint execution, standups, impediment removal |
| 6 | Delivery | Delivering scope and quality | Incremental delivery, DoD, value-first |
| 7 | Measurement | Metrics, KPIs, forecasting | Velocity, burndown, cycle time, CFD |
| 8 | Uncertainty | Risk, ambiguity, complexity | Spikes, risk burndown, iterative risk reduction |
Value Delivery System
PMBOK 7 introduces the Value Delivery System: portfolios → programs → projects → products — all aligned to deliver organizational value. Agile teams focus on value at the product level.
12 PMBOK 7 Principles — Agile Alignment
- Be a diligent, respectful, and caring steward
- Create a collaborative project team environment (Agile self-organizing teams)
- Effectively engage with stakeholders (continuous collaboration)
- Focus on value (deliver value early and often)
- Recognize, evaluate, and respond to system interactions
- Demonstrate leadership behaviors (servant leadership)
- Tailor based on context (choose your WoW)
- Build quality into processes and deliverables (built-in quality)
- Navigate complexity
- Optimize risk responses (spikes, risk burndown)
- Embrace adaptability and resiliency (Agile mindset)
- Enable change to achieve the envisioned future state (welcome change)
Tailoring
Tailoring = intentionally adapting approach, processes, and practices to the specific project context. No one-size-fits-all.
PMP 2021+ expects you to TAILOR. When asked "what approach is best?" — consider: requirements stability, team size, stakeholder involvement, regulatory constraints, team experience, and organizational culture. Match approach to CONTEXT.
26. Earned Value Management (EVM) in Agile
Traditional EVM adapted for Agile: story points = currency for measuring progress instead of dollars.
Agile EVM Concepts
| EVM Metric | Traditional | Agile Equivalent |
|---|---|---|
| Planned Value (PV) | Budgeted cost of work scheduled | Story points planned to this date |
| Earned Value (EV) | Budgeted cost of work performed | Story points actually completed (100% DoD) |
| Actual Cost (AC) | Actual cost incurred | Actual hours/cost spent by team |
| Schedule Variance (SV) | EV − PV | Points completed − Points planned (neg = behind) |
| Cost Variance (CV) | EV − AC | Value delivered vs. cost to deliver |
| SPI | EV ÷ PV | <1 = behind; >1 = ahead of schedule |
| CPI | EV ÷ AC | <1 = over budget; >1 = under budget |
Key EVM Formulas
Must-Know EVM Formulas for PMP
- SV = EV − PV (negative = behind schedule)
- CV = EV − AC (negative = over budget)
- SPI = EV ÷ PV (<1 = behind, >1 = ahead)
- CPI = EV ÷ AC (<1 = over budget, >1 = under budget)
- EAC = BAC ÷ CPI (estimated total cost at completion)
- ETC = EAC − AC (estimate to complete remaining work)
- TCPI = (BAC − EV) ÷ (BAC − AC) (efficiency needed to finish on budget)
- VAC = BAC − EAC (variance at completion)
Sprint: Planned 30 points (PV=30). Completed 24 (EV=24). Effort spent = equivalent of 27 points (AC=27). SV = 24−30 = −6 (behind by 6). SPI = 24÷30 = 0.80 (80% schedule efficient). CPI = 24÷27 = 0.89 (spending more than earning). Alert PO.
In Agile, EVM tracks at RELEASE level — not sprint level. Sprint level uses burndown/velocity. EVM gives the broader picture. PMP may give you numbers — always know: SV/CV negative = problem. SPI/CPI below 1.0 = problem.
27. Agile Procurement & Vendor Management
Agile procurement emphasizes collaboration over adversarial contracting. Vendors are partners, not just suppliers.
Vendor Management in Agile
Collaborative RelationshipTreat vendors as partners. Include them in planning events. Share product roadmap for better alignment.
Incremental DeliveryVendors deliver in sprints. Payment tied to sprint deliverables rather than milestone-based lump sums.
Vendor as Team MemberEmbed vendor developers in Agile team where possible. They attend standups, reviews, retros.
Performance-BasedPay for delivered value, not activity. Measure vendor velocity and quality. Address issues in retrospectives.
Agile vs. Traditional Procurement
| Traditional Procurement | Agile Procurement |
|---|---|
| Detailed RFP with fixed scope | High-level RFP with room for collaboration |
| Evaluated on price alone | Evaluated on team quality, Agile experience, culture fit |
| Fixed-price with penalties for change | T&M or iterative contracts with value-based incentives |
| Vendor managed separately | Vendor integrated into Agile team, attends ceremonies |
| Formal change control for every change | PO re-prioritizes with vendor input — flexible scope |
Ahmad's organization issues a "Request for Agile Proposal" — asking vendors to propose iterative delivery structure, team velocity, and how they handle changing requirements. Selected vendor delivers in 2-week sprints, demos each sprint, adjusts scope based on feedback.
PMP procurement + Agile: favor answers showing collaboration, shared risk, and flexibility. Avoid rigid contract enforcement, formal change requests, or adversarial posturing between buyer and vendor.
28. Remote & Distributed Agile Teams
Most modern teams are distributed. PMP includes scenarios about virtual teams and applying Agile remotely.
Virtual Agile Ceremonies
Virtual Daily Standup15 min video call, same time daily. Shared digital board (Jira, Miro). Camera on builds presence. Record for async teammates.
Virtual Sprint Planning2–4 hours via video. Virtual planning poker tools. Break into shorter sessions across time zones if needed.
Virtual Sprint ReviewDemo via screen share. Record for absent stakeholders. Real-time feedback via Miro or Jamboard.
Virtual RetrospectiveFunRetro, EasyRetro, or Miro for digital sticky notes. Consider async submissions before meeting to ensure psychological safety.
Remote Agile Tools & Challenges
| Category | Tools | Key Consideration |
|---|---|---|
| Project Tracking | Jira, Azure DevOps, Linear, Trello | All members update daily |
| Communication | Slack, Microsoft Teams, Discord | Response time norms required |
| Video | Zoom, Teams, Google Meet | Camera-on policy builds connection |
| Collaboration | Miro, Mural, Jamboard | Replace physical information radiators |
| Documentation | Confluence, Notion, SharePoint | Single source of truth |
Distributed Team Challenges & Solutions
- Time zone overlap: Establish core overlap hours (2–4 hrs/day). Record all ceremonies.
- Communication gaps: Over-communicate. Use async updates (Loom videos, written standups).
- Team cohesion: Virtual team-building, informal channels, celebrate wins visibly.
- Osmotic communication loss: Create virtual "water cooler" channels. Increase written transparency.
- Technical issues: Test AV before meetings. Have backup communication channel ready.
Agile team in Chicago, London, Dubai. Reviews at 10 AM Chicago time (8 PM Dubai). Dubai team misses reviews consistently. Solution: Rotate meeting times quarterly — each location shares the off-hours burden fairly. Record all reviews within 2 hours.
PMP remote team questions: always favor communication, transparency, and inclusion. No team member should feel like a "second-class" participant. Rotate meeting times; never permanently burden one location.
29. Practice Quiz — Part 2 (Advanced Agile)
Q9. A new Agile team has frequent arguments about technical approaches and members missing standups. Which Tuckman stage?
A. Forming
B. Storming
C. Norming
D. Performing
Q10. A company requires Agile delivery but has a fixed total budget. Which contract type is BEST?
A. Time & Materials with no ceiling
B. Not-to-Exceed T&M (NTE)
C. Firm Fixed Price (FFP)
D. Cost Plus Percentage Fee (CPPC)
Q11. Using MoSCoW, a "dark mode" feature is nice but won't delay the release if missing. Which category?
A. Must Have
B. Should Have
C. Could Have
D. Won't Have
Q12. A story passes all acceptance criteria but code review is not complete. Is the story done?
A. Yes — acceptance criteria are the only requirement
B. No — it must also meet the Definition of Done
C. Yes — code review is optional in Agile
D. Only the Product Owner can decide
Q13. Which retrospective technique uses Liked, Learned, Lacked, and Longed For?
A. Mad/Sad/Glad
B. Start/Stop/Continue
C. 4Ls
D. Sailboat
Q14. The Cumulative Flow Diagram shows the "In Testing" band growing wider over time. What does this mean?
A. Team velocity is increasing
B. There is a bottleneck in Testing
C. Team is accepting too many stories per sprint
D. WIP limits should be removed
Q15. A developer added a feature customers will "love" — it wasn't requested. In Kano terms, this is:
A. Basic feature
B. Performance feature
C. Excitement (Delighter) feature
D. Indifferent feature
Q16. PMBOK 7 replaced the 5 process groups with:
A. 10 Knowledge Areas
B. 8 Performance Domains
C. 4 Agile Values
D. 12 Agile Principles
Q17. EV = 400, PV = 500, AC = 450. What is the Schedule Performance Index (SPI)?
A. 1.25
B. 0.89
C. 0.80
D. 1.12
Q18. The THINNEST working end-to-end slice used to validate architecture is called:
A. MVP (Minimum Viable Product)
B. Walking Skeleton
C. Spike
D. Story Map Backbone
Q19. Dubai team always gets the worst meeting times in a 3-timezone Agile team. What is the BEST approach?
A. Move all meetings to Dubai time permanently
B. Require Dubai team to adjust their work hours
C. Rotate meeting times quarterly so all locations share inconvenience fairly
D. Replace Dubai team with a local resource
Q20. A story "can't be tested" when completed. Per INVEST, which criterion is violated?
A. Independent
B. Small
C. Valuable
D. Testable
Q21. Per Agile Manifesto principles, the primary measure of progress is:
A. Number of features completed
B. Working software
C. Customer satisfaction score
D. Sprint velocity achieved
Q22. Which BEST describes Herzberg's "motivators" in Agile context?
A. Competitive salary and benefits
B. Good working conditions and job security
C. Meaningful work, recognition, and growth opportunities
D. Clear management policies and supervision
Q23. In TDD, what is the correct order?
A. Write code → Write test → Refactor
B. Write failing test → Write code to pass → Refactor
C. Refactor → Write test → Write code
D. Write test → Refactor → Write code
Q24. The WSJF (Weighted Shortest Job First) formula is:
A. Job Duration ÷ Cost of Delay
B. Cost of Delay ÷ Job Duration
C. Business Value × Risk Reduction
D. Story Points × Priority Weight
Q25. Team working agreement says "cameras on during standups." One member consistently joins with camera off. SM should FIRST:
A. Escalate to the team member's manager
B. Remove the camera-on rule from working agreements
C. Have a private conversation, understand the reason, address in next retrospective if needed
D. Publicly call it out in the next standup