🏆 Agile Project Management & Scrum
Complete PMP Exam Interactive Study Guide — Based on Agile Project Management: Scrum for Beginners by Markus Heimrath
📖 Glossary — Key Terms
Click any keyword badge below for a quick explanation. These terms are frequently tested on the PMP exam.
Agile Scrum Sprint Product Backlog Sprint Backlog Increment Product Owner Scrum Master Daily Scrum Definition of Done Definition of Ready User Story Burndown Chart Story Points Velocity Epic Planning Poker Timeboxed Sprint Review Sprint Retrospective Stakeholder Artefact Waterfall Kanban Conditions of Satisfaction T-Shaped Skills CPI Earned Value Test-Driven Design
| Term | Quick Definition |
|---|---|
| Agile | Product-oriented, incremental approach to development; flexible and team-driven |
| Scrum | A specific Agile framework using sprints, roles (PO, SM, Dev Team), and ceremonies |
| Sprint | Fixed 2–4 week development cycle producing a potentially shippable increment |
| Product Backlog | Prioritized master list of all desired features/requirements; owned by Product Owner |
| Sprint Backlog | Subset of product backlog items committed to during a specific sprint |
| Burndown Chart | Visual showing remaining work (Y) vs. time (X) — tracks sprint/project progress |
| Velocity | Developers × Hours × Working Days; measures team output per sprint |
| Story Points | Relative measure of effort, complexity, and risk (not hours); uses Fibonacci: 1,2,3,5,8,13… |
| DoD | Definition of Done: checklist of criteria an item must meet to be considered complete |
| DoR | Definition of Ready: criteria an item must meet before a team can start working on it |
| User Story | "As [role] I want [feature] so that [benefit]" — describes features from user perspective |
| Epic | Large, overarching user story broken into smaller stories for sprint-level work |
| Timeboxed | Fixed, non-negotiable time limit for meetings or sprints |
The PMP exam tests whether you know WHO owns each artifact. Product Owner owns the Product Backlog. The Development Team owns the Sprint Backlog. No one else can change sprint goals mid-sprint.
1. Introduction — What is Agile?
The traditional approach to project management — the Waterfall method — divides a project into sequential phases that build on each other. Each phase must be completed before the next begins, and changes are costly once a phase is locked in.
Agile was born from the recognition that this rigidity creates waste, delays, and poor products. Inspired by lean manufacturing (Toyota's production system), Agile introduces continuous testing, incremental delivery, and team autonomy.
Agile vs. Waterfall — Side-by-Side
| Dimension | 🌊 Waterfall | ⚡ Agile / Scrum |
|---|---|---|
| Planning | Detailed upfront plan (Gantt chart) | Adaptive, sprint-by-sprint planning |
| Requirements | Fixed at start; changes are expensive | Evolve continuously via backlog |
| Delivery | Single delivery at project end | Working product after every sprint |
| Testing | At the end (QA phase) | Continuous; test-driven design |
| Customer Role | Sign-off at milestones | Continuous collaboration |
| Team Structure | Hierarchical; PM-driven | Self-organizing; flat |
| Risk Management | Risk identified upfront | Risks emerge and resolved each sprint |
| Documentation | Extensive upfront docs | Just enough, just in time |
| Change Response | Change control board; formal process | Embraced; backlog re-prioritized |
| Success Metric | On-time, on-budget delivery | Business value delivered |
Example — Toyota Lean Manufacturing: Toyota noticed that catching defects late in production was enormously wasteful. They introduced continuous checking during production — the same philosophy Agile brings to software: catch problems early in each sprint rather than discovering them at the end.
Mountain Bike Analogy (from the book): You stand at the top of a forested hill. You can't plan every turn before you start — the plan would be useless (even dangerous). You ride, seeing 30–50m ahead, constantly adapting to fallen trees and deer. Scrum works the same way: clear destination, flexible path.
The PMP exam heavily tests your knowledge of when to use Agile vs. Waterfall. Agile is preferred when requirements are unclear or likely to change. Waterfall when requirements are fixed, compliance is strict, or the customer wants fixed-price contracts.
✅ Agile = Product-oriented, team-driven, incremental
✅ Waterfall = Plan-driven, phase-gated, document-heavy
✅ Scrum = The most popular Agile framework
✅ Lean = Eliminate waste; origin is manufacturing (Toyota)
✅ "Potentially shippable product" = goal after EVERY sprint
2. Scrum/Waterfall Hybrids
Real-world projects often cannot use pure Scrum. Large organizations have existing reporting structures, compliance requirements, and contractual obligations. A hybrid approach combines elements of both.
When is a Hybrid Acceptable?
✅ Acceptable Hybrid
You are in a large organization that requires monthly management reports. The Product Owner writes the report — it doesn't affect the sprint work or team decisions. The Scrum values are intact.
❌ Unacceptable Hybrid
A division manager wants to approve all products at the end of each sprint. This violates the DoD and undermines the team's personal responsibility — a fundamental Scrum value.
The Pig and Chicken Story: A pig and chicken discuss opening a restaurant called "Ham & Eggs." The pig refuses because the chicken is involved (contributes eggs) but not committed (like the pig, who gives its life). In Scrum: Developers are pigs (fully committed), Stakeholders are chickens (contributing but not responsible for delivery). This is why only the Scrum Team decides what goes into a sprint.
On the PMP exam: If a stakeholder demands to approve each sprint's output before the team can call it "done," this is a violation of Scrum principles. The Product Owner has sole authority to accept or reject completed work.
✅ Hybrids are OK when: external reporting doesn't affect sprint work
✅ Treat each cascade/phase as its own Scrum project
❌ Never allow: stakeholders to direct developers directly
❌ Never allow: mid-sprint goal changes
3. A Brief History of Scrum
The term Scrum comes from rugby — a tightly coordinated team effort to advance the ball, appearing chaotic to outsiders but actually highly structured.
- 1986: Takeuchi & Nonaka publish "The New New Product Development Game" — first use of "scrum" as a business metaphor
- Early 1990s: Jeff Sutherland and Ken Schwaber begin using Scrum in software development
- 1995: Sutherland & Schwaber present at a conference in Austin, Texas — "Scrum Software Development Process"
- February 2001: 17 developers sign the Agile Manifesto
- 2001: Schwaber co-authors "Agile Software Development with Scrum"
Key Insight from Nonaka & Takeuchi: "Teams require autonomy to achieve excellence." The best teams know where they are going but are free to find their own way to get there. Organizations that give goals (not task lists) to small, independent teams achieve the best outcomes. This became the philosophical foundation of Scrum.
Know the key names: Sutherland + Schwaber = founders of Scrum. Takeuchi + Nonaka = inspiration. The Agile Manifesto was signed in 2001 by 17 developers.
3.1 Manifesto for Agile Software Development
The Agile Manifesto states four core value comparisons. The right column has value, but the left column is valued MORE:
| We value MORE → | Over → |
|---|---|
| Individuals and interactions | Processes and tools |
| Working software | Comprehensive documentation |
| Customer collaboration | Contract negotiation |
| Responding to change | Following a plan |
The 12 Agile Principles
The PMP exam may ask you to identify which Agile principle applies to a given scenario. Key ones to memorize:
• Welcome change even late = Principle 2 (major differentiator from Waterfall)
• Working software = measure of progress = Principle 7
• Sustainable pace = Principle 8
• Self-organizing teams = Principle 11
• Reflect and adjust = Principle 12 (this is the Retrospective)
Memory trick for the 4 manifesto values:
Individuals > processes | Working software > documentation
Customer collaboration > contracts | Responding to change > plans
→ I W C R — "I Will Collaborate and Respond"
4. The Principles of Scrum
Scrum is not a detailed step-by-step project plan. The only things fixed are goals — the team decides how to achieve them. Scrum has three core components:
- Artefacts — Product Backlog, Sprint Backlog, Increments
- Roles — Product Owner, Scrum Master, Development Team, Stakeholders
- Sprints — Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective
The PMP exam often presents scenarios where a traditional PM tries to impose top-down task assignments on a Scrum team. The correct answer is always that the Development Team self-organizes and selects its own work from the sprint backlog.
⭐ The 5 Scrum Core Values
The official Scrum Guide defines five core values that all Scrum Team members must embody. These are directly tested on the PMP exam and are the foundation of Scrum's culture. Without these values, the roles, ceremonies, and artefacts are just empty processes.
💪 1. COMMITMENT
What it means: Every team member commits fully to achieving the sprint goal and to each other. This is not just about tasks — it's about personal accountability to the team.
In practice: A developer commits to completing their sprint tasks. The SM commits to removing impediments. The PO commits to keeping the backlog ready.
Exam Scenario: A developer realizes mid-sprint they won't finish their task. Commitment requires they immediately raise this in the Daily Scrum — not hide it until sprint end.
🦁 2. COURAGE
What it means: Scrum Team members must have the courage to do the right thing — raise problems, disagree with stakeholders, say "no" when sprint scope is threatened, and admit mistakes.
In practice: The SM tells a senior stakeholder they cannot give direct instructions to the team. A developer admits their estimate was wrong. The PO cancels a sprint that's lost its value.
Exam Scenario: A powerful stakeholder demands a feature be added mid-sprint. Courage means the SM and PO jointly explain why this cannot happen and offer it as the next sprint's top priority.
🎯 3. FOCUS
What it means: The team focuses entirely on the sprint goal and the backlog. No distractions, no side projects during sprint time. Everyone's energy is directed at what matters most right now.
In practice: Sprint goal is locked — no scope creep mid-sprint. Daily Scrum keeps everyone aligned. The SM removes organizational distractions so the team can focus.
Exam Scenario: A developer is asked by another department head to help with a different project during an active sprint. Focus (and the SM's role) means this is declined or deferred until after the sprint.
🔓 4. OPENNESS
What it means: The team and stakeholders are open about all work, progress, challenges, and obstacles. Transparency is a prerequisite — nothing is hidden.
In practice: Burndown charts are visible to all. Daily Scrums are honest about impediments. Sprint Reviews openly show what was and wasn't completed. Retrospectives surface real problems.
Exam Scenario: A sprint is behind. Openness requires the team to show the actual burndown (not a manipulated version) and discuss causes honestly in the review — not present a polished story.
🤝 5. RESPECT
What it means: Scrum Team members respect each other's capabilities, skills, and perspectives. They treat each other as capable, independent professionals — not subordinates or resources to be assigned tasks.
In practice: No team leader dictates tasks — the team self-assigns. Specialists respect each other's domains. The PO trusts the team's technical judgment. The SM facilitates without controlling.
Exam Scenario: A senior developer dismisses a junior's sprint estimate as "too high." Respect means the junior's reasoning is heard in Planning Poker — all voices are equal in estimation. Experience informs; it doesn't dictate.
| Value | Who Demonstrates It Most | Violated When… |
|---|---|---|
| Commitment | Entire Scrum Team | Team members hide problems; skip Daily Scrums; ignore sprint goals |
| Courage | SM (protects process); PO (says no to stakeholders) | SM allows mid-sprint scope changes; PO caves to stakeholder pressure |
| Focus | Dev Team (sprint execution); SM (removes distractions) | Developers work on non-sprint tasks; sprint goal changes mid-sprint |
| Openness | All roles — especially in ceremonies | Burndown charts are manipulated; retrospectives avoid real problems |
| Respect | PO trusts team; team trusts each other | PO micromanages dev tasks; senior devs override junior estimates without discussion |
PMP Exam Memory Trick — CCFOR:
Commitment · Courage · Focus · Openness · Respect
→ "Committed Courageous Focused Open Respectful teams"
The exam tests these through scenario questions. If an answer choice involves the SM enforcing a Scrum rule against organizational pressure → that's Courage. If it involves honest reporting of bad news → that's Openness. If it involves trusting the team to self-organize → that's Respect.
5 Scrum Values (CCFOR):
✅ Commitment — personal accountability to sprint goal and team
✅ Courage — do the right thing; protect the process; say no
✅ Focus — sprint goal only; no distractions; SM shields team
✅ Openness — transparent progress, problems, and challenges
✅ Respect — trust each other's expertise; no hierarchy within Dev Team
📌 These values apply to ALL Scrum Team members — not just one role
4.1 Why Scrum? — The 3 Key Advantages
⚡ 1. Rapid Adaptation
Market conditions, technology, and user needs change constantly. A 6-month project plan is obsolete the day it's published. Scrum re-plans every sprint (2 weeks), making course-corrections natural and cheap.
🏆 2. Outstanding Results
Continuous testing during development means no final QA shock. Each component is "done" when it's delivered — not when the project ends. The product grows through constantly verified increments.
😊 3. Worker Satisfaction
Teams take complete ownership. No impossible deadlines set by non-technical managers. Freedom to self-organize. This attracts better talent and reduces turnover.
4.2 Requirements & User Stories
Traditional projects have requirements — fixed, stone-carved specifications. Scrum has User Stories — living, evolving descriptions of features from the user's perspective.
The User Story Template
📝 Standard Format
"As [role/user] I want [feature/function] so that [benefit/value]."
Example — Navigation App:
"As a user I want my position shown on the map."
Back of the card (Conditions of Satisfaction):
• Position should be accurate
• Position should use GPS data
• Position should use Wi-Fi
• Position should use mobile data
Example — AR App (Persona Technique):
Josh, 30 years old, tech-savvy, medium-high income, walks downtown frequently.
Story: "Josh wants to see store offers and discounts as he passes so he doesn't have to go inside and ask."
User Story Hierarchy
| Level | Name | Description |
|---|---|---|
| Large | Epic | Overarching theme — "War and Peace." Too big for a sprint. Broken down into stories. |
| Medium | User Story | Standard unit — fits in a sprint. "As a user I want to…" |
| Small | Task | Technical sub-items within a story. E.g., "Design UI: 4 hours", "Code: 16 hours" |
Know the difference: Epic → User Story → Task. Epics are in the product backlog as placeholders and gradually broken down. Tasks live in the sprint backlog. The PMP exam may ask you to identify what level of decomposition is appropriate for sprint planning.
✅ User Stories replace "requirements" in Scrum
✅ Written from the user's perspective
✅ Back of the card = Conditions of Satisfaction
✅ Epics → Stories → Tasks (smallest)
✅ Detail level depends on sprint proximity (high priority = more detail)
4.2a Developing Stories — The First Session
At the very beginning of a Scrum project you have an idea or a customer order — but no user stories yet. The first step is to bring together all key players for an initial story-development session: stakeholders, Product Owner, Scrum Master, and Development Team.
This first meeting is essentially a structured brainstorm. It is usually the longest single meeting in the entire project — potentially lasting hours or even days depending on project scope. After this, all future sprint meetings will be much shorter.
How the Session Works
- Assemble everyone: Stakeholders, PO, SM, Dev Team all in one room
- Brainstorm freely: Don't worry about hierarchies or structure — get all information captured first
- Use mind maps (especially electronic ones) to capture and connect ideas visually
- Use physical boards with Post-It notes if working on paper — set up boards per level (Epic board, Story board, etc.)
- Define user roles: Clearly identify who the "users" in the stories actually are
- Apply DEEP rules as stories develop — detail only what's needed for now
Defining User Roles — The Persona Technique
Before writing stories, identify and name the actual user types. Borrow the advertiser's technique: visualize your customer as a real person. Give them a name, age, income level, and habits. This makes stories specific, empathetic, and testable.
Example — AR Navigation App:
User role identified: "Josh" — 30-year-old male, tech-savvy, medium-to-high income, frequently walks through commercial streets.
Story derived from this persona:
"Josh wants to see the offers and discounts in the stores he passes in the street so he doesn't have to go in and ask about them."
Other roles in the same project might be:
• The end-user who installs the app on their phone
• A marketing colleague who needs to analyse app data
• An HR representative who needs to ensure the app is accessible
Team Styles — Two Common Approaches
🔽 Top-Down: Start with Epics
Some teams prefer to first define broad Epics (the big picture), then break each Epic into smaller user stories. Good for teams who think holistically and need to see the full landscape before drilling down.
🔼 Bottom-Up: Start with Features
Other teams jump immediately into specific features and group them into Epics later. Good for teams who are feature-driven and technically minded. Requires good facilitation to avoid losing the big picture.
Key Rules for the First Story Session
- Stories are only a starting point — they will change significantly over time
- Early stories can be vague or abstract — that is expected and acceptable
- Do NOT try to clarify every item at this stage — it violates Scrum principles
- The SM serves as facilitator — keeping the session productive without directing content
- Use a keyword, colour code, or cover-sheet card to link child stories back to their parent Epic
- Record all key decisions and discussion points for documentation
Real-World Scenario — Website Development:
Day 1 brainstorm produces 60 Post-It notes on three boards. The team groups them into 8 Epics. Each Epic has 4–10 rough stories. Only the top 3 Epics have stories detailed enough for the first sprint. The remaining 5 Epics remain as placeholders in the Product Backlog — they will be refined as the project progresses. This is exactly how Scrum intends backlog to begin.
Developing Stories — Key Facts:
✅ First meeting: longest in the project (hours to days)
✅ Attendees: ALL roles — stakeholders, PO, SM, Dev Team
✅ Tools: Mind maps (electronic preferred), Post-It boards
✅ Persona technique: give users names, ages, habits
✅ Early stories can be vague — do NOT over-clarify at start
✅ Two styles: Epic-first (top-down) or Feature-first (bottom-up)
✅ Link child stories to parent Epics via colour/keyword/card
5. Starting a Scrum Project
A Scrum project begins with assembling a team, establishing roles, and creating an initial product backlog. The most critical success factor: everyone must understand the goal and the strategy.
The PMP exam tests whether you know that Scrum roles are assigned to individuals — not teams. Roles cannot be shared or delegated. Each role holder operates autonomously.
5.1 Roles — The Scrum Team Structure
Scrum defines four key roles. Three are within the Scrum Team; one is external.
🌐 Stakeholders (External)
Everyone with an interest in the project: business owner, customers, end users, finance, marketing, legal, regulatory bodies. They define the goal and set the budget but communicate only through the Product Owner — they cannot contact developers directly.
- Set the framework and goal of the project
- Can set constraints (e.g., legal requirements)
- Cannot give instructions to the development team
- Cannot tell the Product Owner what priorities to set
📊 Product Owner (PO) — "The Project Manager Equivalent"
The interface between stakeholders and the development team. Owns the Product Backlog. Responsible for financial performance of the product. Accepts or rejects completed increments.
- Owns: Product Backlog (creates, refines, prioritizes)
- Responsibilities: ROI, budget monitoring, release decisions
- Financial tools: Velocity, CPI, Earned Value, payback period
- Key rule: Only ONE Product Owner — never an assistant or co-PO
- Can end a sprint early if product is done or market conditions change
LTE to 5G Scenario: A company is developing an LTE chip when 5G launches ahead of schedule. The Product Owner must be ready to "pull the trigger" — cancel the LTE sprint and redirect resources. This is the PO's financial decision-making power.
🛡️ Scrum Master (SM) — "The Coach / Facilitator"
Ensures the Scrum process runs smoothly. NOT responsible for financial or technical decisions. Serves both the Development Team and the Product Owner.
- Role: Trainer, mentor, facilitator, servant-leader
- Responsibilities: Remove impediments, enforce Scrum rules, prevent disruption
- Does NOT: Direct content of work, control financial decisions
- Can use authority only when all other solutions fail (e.g., team wants to skip Daily Scrum)
- Manages workspaces: Ensures team has tools, equipment, environment needed
The SM is a servant-leader — facilitates but doesn't dictate. On the PMP exam, if a scenario shows the SM making technical decisions or managing the budget, that is WRONG behavior.
💻 Development Team — "The School of Fish"
Coders, testers, designers, network admins, database managers, UI specialists. No internal hierarchy. Self-organizing. Cross-functional.
- Size: 3–9 people (too large = uneconomical; too small = overloaded)
- Responsibilities: Sprint execution, sprint backlog maintenance, product testing
- No team leader: Points of contact are only the SM and PO
- T-shaped skills: Broad knowledge + deep specialist expertise
- Flexibility: Must help each other — "not my job" attitude is incompatible with Scrum
School of Fish Analogy: No alpha fish. No predetermined plan. Each fish sees prey or predators and the school reacts. The first fish to spot something signals, and the school responds. Development teams must operate with the same fluidity — anyone who spots a problem or opportunity raises it and the team adapts.
Scrum Roles Quick Reference:
PO → Product Backlog owner, financial decisions, stakeholder interface
SM → Process guardian, impediment remover, servant-leader
Dev Team → Self-organizing, cross-functional, Sprint executor
Stakeholders → External, goal-setters, communicate via PO only
📌 No role can be shared or have a deputy
📌 Stakeholders → PO only (not SM, not Dev Team)
5.2 Artefacts — The Scrum Inventory
Scrum has three core artefacts that together represent all work and value in the project:
| Artefact | Owned By | Contains | Changes? |
|---|---|---|---|
| Product Backlog | Product Owner | All features, changes, bugs, knowledge work | Always evolving |
| Sprint Backlog | Development Team | Sprint tasks broken from backlog items | Within sprint |
| Increment | Dev Team → PO accepts | Working, tested, potentially shippable product | Grows each sprint |
5.2.1 The Product Backlog
The Product Backlog is the master list of everything the product needs. It is never complete, always evolving. Four types of items:
- Features: "I want a form that sends me an email."
- Changes: "I want default picture sorting to be by date, not name."
- Defects: "Database crashes on image uploads over 2MB."
- Knowledge Work: "Test VR vs. AR vs. 360° to determine best prototype."
The DEEP Rules for Product Backlog Items
Definition of Ready (DoR) — When Can an Item Be Pulled?
| Criterion | Meaning |
|---|---|
| Clear | Everyone understands it — technically and functionally |
| Feasible | Can be delivered within budget; financially makes sense |
| Detailed | Contains all technical details and dependencies |
| Independent | Can be delivered standalone, in one sprint |
| Testable | Ready for testing immediately after development |
| Reviewable | Scrum Team can review it in the Sprint Review |
Financial Concepts for the Product Owner
| Term | Formula/Definition |
|---|---|
| Velocity | Developers × Hours × Working Days |
| Earned Value (EV) | Value of all "potentially shippable" completed items (meeting DoD) |
| Cost Variance (CV) | Earned Value (EV) − Actual Costs (AC) |
| CPI | EV ÷ AC — CPI > 1 means under budget; CPI < 1 means at risk of overrun |
| ROI | Point where product profits cover all development costs |
| Payback Period | Time until investment is recovered (used in international projects) |
Sprint Calculation Example:
Goal: 160 story points total
Velocity: 10 story points/sprint
Sprint length: 2 weeks
→ 160 ÷ 10 = 16 sprints = 32 weeks
Multiply 32 weeks × weekly manpower cost ÷ 52 = estimated annual manpower cost
The PMP exam tests CPI and EV calculations. Remember: CPI = EV/AC. CPI > 1 is GOOD (under budget). CPI < 1 is BAD (over budget). Same logic as traditional project EVM but applied sprint-by-sprint in Agile.
Product Backlog Key Facts:
✅ Owned by Product Owner (only one PO!)
✅ Never fully complete — always evolving
✅ DEEP: Detailed, Emergent, Estimated, Prioritized
✅ Anyone can add to it; PO prioritizes
✅ DoR criteria determine when an item can enter a sprint
✅ CPI = EV/AC | Velocity = Devs × Hours × Days
5.2.1a Maintaining the Backlog
The Product Backlog is a living document. It must never be fully empty or fully completed while the project is active. The Product Owner is responsible for keeping it healthy, current, and actionable at all times.
What Backlog Maintenance Involves
- Refining user stories — adding detail as items rise in priority
- Re-prioritizing — an item that was low priority may need urgent elevation without disrupting current sprint work
- Adding new items — new ideas, market changes, and bug discoveries are continuously added
- Removing stale items — items that no longer make business sense are removed
- Updating estimates — story points are revisited as more is learned
- Consulting stakeholders — regular check-ins to confirm alignment with evolving business goals
Navigation App Example: The team is developing a navigation app. Mid-project, a new map provider enters the market offering cheaper and better maps. The PO must now either: (a) add a story to test the new maps, or (b) determine whether existing sprint items/increments can integrate the new provider. The backlog is updated immediately to reflect this real-world change — this is why Scrum embraces change rather than resisting it.
The "Ravioli Pan" Principle of Backlog Health
🍝 Always Keep the Pan Balanced
Think of the Product Backlog as a pot of cooking ravioli. Low-priority items sit at the bottom (not yet ready). As they get refined and their priority rises, they float to the top (ready for a sprint). You — the PO, as the cook — must constantly:
• Add new ravioli (new backlog items)
• Let them cook (refine detail and raise priority gradually)
• Remove them when ready (pull into sprint)
❌ Don't let the pan go empty (backlog exhausted — no future sprints planned)
❌ Don't let too many float up at once (sprint overload, unclear priorities)
The PMP exam may ask what happens when a backlog item's priority needs to change urgently. The answer: the PO updates the backlog priority immediately. However, items already in an active sprint cannot be changed — the sprint goal is locked. The re-prioritized item enters the NEXT sprint's planning.
Backlog Maintenance Rules:
✅ PO maintains continuously — not just before sprints
✅ Backlog should never be empty or "complete"
✅ Consult stakeholders regularly for alignment
✅ Refine stories as they rise in priority
✅ New items enter bottom; rise as they mature
✅ Mid-sprint priority changes only affect NEXT sprint
5.2.1b Who Adds to the Product Backlog?
Because Scrum and teamwork are inseparable, anyone involved in a project can contribute to the Product Backlog. However, only the Product Owner controls prioritization and final content decisions.
Contributors by Phase
| Phase | Who Contributes | What They Add |
|---|---|---|
| Project Start | Stakeholders | Wishes, goals, budget constraints, legal requirements |
| During Development | Development Team | Change proposals, bug reports, requests for clarification, technical refinements |
| Throughout | Product Owner | Re-prioritization, item refinement, removal of obsolete items, sprint readiness checks |
| Sprint Reviews | Stakeholders + Dev Team | Feedback-based additions, new stories triggered by demo outcomes |
The PO's Responsibility — Ensuring Constant Motion
While anyone can add items, the PO must ensure the backlog is always in motion — items being added, refined, re-estimated, and removed continuously. There is no fixed schedule for this; it is an ongoing responsibility.
Development Team Contributions:
During a sprint, a developer discovers that the API used to fetch location data has been deprecated. They add two items to the Product Backlog:
1. "Research alternative location data APIs" (knowledge work)
2. "Migrate from deprecated API to new provider" (change/feature)
The developer doesn't prioritize these — they add them and flag them to the PO. The PO assesses business impact and assigns priority. This is the correct Scrum workflow.
Stakeholder Contributions via PO:
A stakeholder from the legal department emails the PO: "The new GDPR update requires a data deletion feature by Q3." The PO adds this to the backlog, estimates its impact, and elevates it in priority. The legal team never contacts the Development Team directly — all communication flows through the PO.
A common PMP exam scenario: A developer notices a critical bug and wants to fix it immediately. What should they do? Add it to the Product Backlog and inform the PO. If the PO agrees it's critical, it may enter the next sprint. If it's urgent enough, the PO can cancel the current sprint — but this is rare and a serious decision.
Who Adds to the Backlog:
✅ Anyone can ADD items to the backlog
✅ Only the PO PRIORITIZES and controls the backlog
✅ Stakeholders contribute via PO (never directly to team)
✅ Dev Team adds bugs, change proposals, info requests
✅ PO ensures backlog stays in constant motion
✅ Sprint Review feedback → new backlog items immediately
5.2.2 The Sprint Backlog
The Sprint Backlog is the Development Team's to-do list for one sprint. It contains items pulled from the Product Backlog, broken into specific, technical tasks.
A typical Sprint Backlog table format:
| Description | Start Date | Scheduled Duration | Owner (Developer) | Progress | Timetable (Weeks) |
|---|---|---|---|---|---|
| Design window overlay | Day 1 | 4 hrs | Ana | Done ✅ | Wk 1 |
| Implement CSS overlay | Day 2 | 4 hrs | Carlos | In Progress 🔄 | Wk 1 |
| Code overlay logic | Day 3 | 16 hrs | Dev Team | Not Started ⬜ | Wk 2 |
| Testing overlay | Day 9 | 4 hrs | QA Team | Not Started ⬜ | Wk 2 |
The Sprint Backlog is owned by the Development Team — not the Product Owner, not the Scrum Master. The PO cannot change what's in the sprint once it starts (sprint goal is locked). The team can refine HOW tasks are done.
5.2.3 Sprints (Increments)
A Sprint is a fixed, timeboxed development cycle — typically 2 weeks (never more than 4 weeks). Two things are non-negotiable in a sprint:
- How long it lasts (fixed duration)
- What it will accomplish (sprint goal, agreed at planning)
Sprint Planning — Day 0
Both PO and Development Team agree on sprint goal. High-priority backlog items are selected. Developers (and usually SM) then break items into tasks:
Example — Window Overlay Feature:
Feature: Window overlay in camera display
Tasks:
• Design — 4 hours
• Implementation in CSS — 4 hours
• Coding — 16 hours
• Testing — 4 hours
Note: While CSS developers wait for designs, coders can work in parallel — smart parallel planning reduces idle time.
Capacity Planning
Realistic capacity calculation for a 2-week sprint with 5-day weeks:
10 days × 8 hrs = 80 hrs total
Minus Daily Scrums: 10 × 15 min = 2.5 hrs
Minus other activities (backlog, admin): ~5 hrs
Minus buffer/sick/vacation: ~5 hrs
→ Real capacity ≈ 67 hrs per developer per sprint
84% of theoretical capacity is realistically available
The Burndown Chart
The primary visual for tracking sprint progress:
| Y-Axis | X-Axis | What to Watch |
|---|---|---|
| Work Remaining (hours) | Time Elapsed (days/sprints) | Actual line vs. Ideal line |
| Actual above ideal line → Progress too slow → At risk of failing the sprint | ||
| Actual below ideal line → Ahead of schedule → Possibly too many resources or too few tasks | ||
The PMP exam loves Burndown Charts. Remember: The Y-axis is work remaining, not work completed. If the burndown line is ABOVE the ideal line, the team is behind. The goal is for the actual line to touch zero by sprint end.
Sprint Facts:
✅ Fixed duration: 2–4 weeks (2 weeks preferred)
✅ Sprint Goal = locked once sprint starts
✅ Day 0 = Sprint Planning Meeting
✅ Velocity = Devs × Hours × Working Days
✅ Burndown: Y = remaining work, X = time
✅ Sprint ends with "potentially shippable product"
✅ PO can cancel a sprint only if goal becomes obsolete
The Taskboard
The taskboard is the Development Team's primary visual management tool during a sprint. It displays every task and its current status — giving the entire team real-time visibility into sprint progress at a glance.
Taskboard Structure (4 Columns):
| 📋 TO DO | 🔄 IN PROGRESS | ⏸ BLOCKED | ✅ DONE |
|---|---|---|---|
| Tasks selected for the sprint but not yet started. Pulled from the sprint backlog during Sprint Planning. | Tasks actively being worked on. Scrum convention: a developer should only have 1–2 tasks In Progress at a time to avoid multitasking waste. | Tasks that cannot proceed due to an impediment (missing info, dependency, tool issue). SM is responsible for resolving these urgently. | Tasks meeting the Definition of Done. Moved here after the team verifies completion. These feed into the sprint increment. |
How the Taskboard Works in Practice:
Day 1 of sprint: All tasks in "To Do." A developer picks a task → moves it to "In Progress." Another developer finds they're waiting on an API key → moves their task to "Blocked" and flags it at the Daily Scrum. The SM resolves the API issue by Day 2 → task moves back to "In Progress." By sprint end, the goal is all tasks in "Done."
Physical vs. Digital: Physical boards (whiteboard + sticky notes) are preferred for co-located teams — high visibility and zero latency. Digital tools (Jira, Trello, Axosoft) are used for distributed teams. Both are valid in Scrum.
The PMP exam may describe a taskboard scenario and ask what the SM should do when many tasks are in the "Blocked" column. Answer: The SM's primary job is to immediately remove impediments — blocked tasks are the SM's highest priority. A taskboard with many blocked items signals a systemic problem requiring urgent SM intervention.
Release Planning vs. Sprint Planning
Two distinct levels of planning in Scrum that the PMP exam frequently tests. Understanding the difference prevents costly confusion in real projects and exam scenarios.
| Dimension | 📦 Release Planning | ⚡ Sprint Planning |
|---|---|---|
| Timeframe | Long-term (multiple sprints — weeks to months) | Short-term (one sprint — 1–4 weeks) |
| Purpose | Define when a set of features will be ready for market release (a shippable product version) | Define what the team will build in the next sprint and how |
| Who Leads | Product Owner (with stakeholder input) | PO sets goal; Dev Team plans tasks; SM facilitates |
| Input | Product Backlog priorities + velocity + market timing | Top-priority Product Backlog items + team capacity |
| Output | Release date + feature scope for that release | Sprint Backlog (tasks for the sprint) |
| Frequency | Once per release cycle (several months) | Once per sprint (every 1–4 weeks) |
| Flexibility | High — release scope adjusts as sprints complete | Locked once sprint starts (sprint goal non-negotiable) |
| Level of Detail | Feature-level (what will be in the release) | Task-level (design 4hrs, code 16hrs, test 4hrs) |
Real-World Example — Mobile Banking App:
Release Planning: The PO and stakeholders agree that Release 1.0 will include: account login, balance display, and transaction history — targeting a launch in 4 months (8 sprints at 2 weeks each). This is the release plan.
Sprint Planning (Sprint 1): The team selects "account login" from the backlog. They break it into tasks: UI design (8hrs), backend auth (16hrs), API integration (8hrs), testing (8hrs). This is Sprint Planning — it defines exactly what will be built and how in the next 2 weeks.
The PMP exam often asks: "Who is responsible for the release plan?" Answer: The Product Owner owns release planning. The SM does not set release dates. The Dev Team does not make market release decisions. Release planning is a business function driven by business value and market timing.
Release vs. Sprint Planning:
✅ Release = months ahead; features for next market launch; owned by PO
✅ Sprint = 1–4 weeks; specific tasks; owned jointly (PO goal + Dev Team tasks)
✅ Multiple sprints → one release (not every sprint is a release)
✅ Sprint goal is LOCKED; release scope can flex sprint-to-sprint
✅ Release plan adjusts as velocity and market conditions evolve
Planning Poker
A collaborative estimation game that makes sprint planning engaging and accurate.
- A Game Master (doesn't play) reads the user story
- Team asks clarifying questions
- Each player picks a card (face down) representing their estimate
- All cards are revealed simultaneously
- Highest and lowest estimators explain their choice
- Re-estimate until consensus is reached
- Record key discussion points in item documentation
Why Simultaneous Reveal? If cards were revealed one by one, each person would be influenced by the previous estimates (anchoring bias). Simultaneous reveal ensures truly independent estimates — capturing the range of knowledge and risk perception across the team.
Planning Poker uses Fibonacci sequence (1,2,3,5,8,13,20,40,100) — the gaps increase because estimating large items is inherently less precise. A story estimated at 100 is much more uncertain than one estimated at 5.
Story Points — Relative Effort Estimation
Story Points measure relative effort — not actual hours. They capture three dimensions:
- Time — raw amount of work
- Complexity — technical difficulty
- Risk/Uncertainty — unknowns that could blow estimates
Website Example:
Item A: Contact form with 10 fields (data transfer, validation, error handling, testing)
Item B: A page with one picture
Item A has more time (more HTML/code), more complexity (data handling), and more risk (data loss bug potential).
If B = 2 story points, then A might be = 13 story points. The ratio matters, not the absolute number.
| Story Points | Hours? | Usage |
|---|---|---|
| Not hours | ❌ Not actual hours | Relative comparison between items |
| Fibonacci scale | 1,2,3,5,8,13,20,40,100 | Larger gaps reflect estimation uncertainty at scale |
| Help PO prioritize | Used with business value | ROI = Business Value ÷ Story Points |
Critical PMP Exam Point: Story points should NEVER prevent the team from pulling a high-value item just because it has many points. The goal is product value, not minimizing story points. Don't cherry-pick easy items.
Tracking Time in Scrum
Even though sprints are measured in story points and the focus is on value delivered, the use of time recording systems in Scrum remains a debated topic. Understanding both sides is essential — for real projects and for the PMP exam.
Arguments AGAINST Time Tracking
❌ The Case Against Timesheets
- Time recording can become pure bureaucracy — wasting the same time it claims to measure
- Classic project trap: spending all day recording hours instead of doing work
- Scrum's focus is on value delivered — not hours logged
- If billing by the hour, there is an incentive to sell more hours rather than work efficiently — directly contradicting Agile principles
- Creates a monitoring/surveillance dynamic that damages team trust
Arguments FOR Time Tracking
✅ The Case For Timesheets
- Customer billing: Many clients want to know not just the result but the effort behind it
- PO verification: Only way for the PO to confirm that sprint estimates match reality — critical for future planning accuracy
- Legal compliance: Many jurisdictions legally require time records (overtime calculations, labor audits)
- Contractual requirements: Some contracts explicitly require time records as deliverables
- Learning: Time data is not about monitoring — it's about using past data to improve future estimates
How to Implement Time Tracking in Scrum (If Required)
- Use software tools — modern time tracking apps can start/stop automatically or with one click, minimizing administrative burden
- Keep it minimal — the goal is the least possible overhead while still providing useful data
- Discuss as a team — explain clearly that tracking is not surveillance; it's a learning tool
- Review in retrospectives — is the time tracking system helping or slowing the team down? Adjust accordingly
- Treat as a trend indicator — time data shows directional trends, not precise performance judgments (just like the burndown chart)
Scenario — Timesheet Conflict with Customer:
A client insists on weekly timesheets showing every hour billed. As the Scrum Master or PO, what should you do?
✅ Best approach: Negotiate firmly. Explain that billing by the hour creates incentives to work slowly and sell more hours — it is against the Scrum principle of delivering maximum value in minimum time. Propose instead to bill by sprint milestone or feature delivered. If the client insists for legal/contractual reasons, comply but ensure the team understands it is not a performance evaluation tool.
Scenario — Legal Requirement:
A government contract requires time logs for all project staff. In this case time tracking is mandatory. The team should:
• Use automated time-tracking software that captures project codes with minimal input
• Set aside 5 minutes at end of each day for entries (not an interruption)
• Discuss the system in the first sprint retrospective to ensure it's working efficiently
• Never use the data to evaluate individual developer performance in Scrum reviews
Time Tracking vs. Story Points — Key Distinction
| Dimension | Story Points | Time Tracking (Hours) |
|---|---|---|
| Purpose | Relative effort estimation; sprint planning | Actual time spent; billing; legal compliance |
| Unit | Relative (1, 2, 3, 5, 8…) | Absolute (hours, minutes) |
| Owner | Dev Team (estimation); PO (prioritization) | Individual developers (input) |
| Used For | Sprint planning; velocity; ROI | Customer billing; legal records; PO verification |
| Scrum Stance | Essential — core Scrum tool | Controversial — use only when needed |
The PMP exam may present a scenario where a client demands hourly billing. The Agile-correct answer is to discourage hourly billing because it incentivizes slow work and contradicts Scrum's goal of maximum value in minimum time. However, if there is a legal or contractual requirement, compliance is necessary — with minimum overhead and no use of data for performance surveillance.
Tracking Time in Scrum:
✅ Time tracking is OPTIONAL in Scrum (unless legal/contractual)
✅ Use automated tools to minimize administrative burden
✅ Purpose = learning and billing, NOT surveillance
✅ Discuss in retrospectives: is it helping or hurting?
✅ Advise clients against hourly billing — propose milestone billing
✅ Time data = trend indicator, not precise performance metric
✅ Story Points ≠ Hours (different tools, different purposes)
6. The Daily Scrum
The Daily Scrum is a 15-minute, timeboxed, daily standing meeting for the Development Team during an active sprint. Held at the same time and place every day.
Three Questions Every Team Member Answers:
❓ Question 1
What have I achieved in the last 24 hours?
❓ Question 2
What will I do in the next 24 hours?
❓ Question 3 — Most Important
What impediments are there to my progress?
Location Tip: Hold the Daily Scrum in the kitchen area — no seats, so everyone stays standing. This naturally enforces the 15-minute rule. Nobody is comfortable enough to stay longer than necessary.
What the Daily Scrum is NOT:
- NOT a detailed progress report
- NOT a problem-solving session (problems are resolved separately)
- NOT a planning meeting
- NOT a status report to management
The PMP exam may ask: "Who attends the Daily Scrum?" The answer is the Development Team. The Scrum Master may attend to facilitate. The Product Owner may attend but should not participate. Stakeholders never attend the Daily Scrum.
Daily Scrum:
✅ 15 minutes — timeboxed, no exceptions
✅ 3 questions: Done / Doing / Impediments
✅ Every 24 hours during active sprint
✅ Development Team runs it (SM facilitates optionally)
✅ Impediments discussed separately (not during meeting)
✅ End of day: team updates Burndown Chart
Impediment Management
An impediment is anything that slows down or blocks the Development Team's progress — technical, organizational, or interpersonal. Removing impediments is the Scrum Master's single most important daily responsibility.
Types of Impediments
| Category | Examples | Who Resolves |
|---|---|---|
| Technical | Missing software license; broken test environment; unavailable API; slow server | SM escalates to IT/management; Dev Team works around if possible |
| Organizational | Team member pulled to another project; meeting overload; bureaucratic approval delays | SM negotiates with management; PO adjusts priorities |
| Process | Unclear DoD; ambiguous user story; missing stakeholder decision | SM clarifies with PO; PO contacts stakeholders |
| Interpersonal | Team conflict; communication breakdown; knowledge silos | SM coaches and mediates; may involve HR if severe |
| External | Third-party vendor delay; regulatory hold; infrastructure outage | SM escalates; PO adjusts sprint scope if needed |
The Impediment Log
The SM maintains an Impediment Log — a live tracking list of all known impediments. This is not just a to-do list; it is a transparency and accountability tool.
| Field | Description |
|---|---|
| Impediment ID | Unique identifier for tracking |
| Description | Clear, concise statement of what is blocked and why |
| Raised By | Developer who first raised it (usually in Daily Scrum) |
| Date Raised | When it was first identified |
| Owner | Who is responsible for resolving it (usually SM) |
| Status | Open / In Progress / Resolved |
| Resolution Date | When it was resolved — used to calculate resolution time |
| Impact | Tasks or story points affected while blocked |
The Impediment Resolution Process
- Raised: Developer mentions it in Daily Scrum (3rd question: "What is blocking me?")
- Logged: SM adds it to the Impediment Log immediately
- Assessed: SM determines urgency and owner — is this within the team's control or does it need escalation?
- Resolved: SM removes the impediment — directly if possible, or via escalation to management/PO
- Closed: SM confirms with the developer that the blocker is fully removed and updates the log
- Retrospective: Recurring impediment patterns are analyzed in the Sprint Retrospective to prevent future recurrence
Scenario 1 — Technical Impediment:
At Day 3 Daily Scrum, a developer reports: "I cannot test the payment module because the test server has been down since yesterday." The SM immediately logs this, contacts IT infrastructure within the hour, and escalates to management if not resolved by end of day. While the server is being fixed, the SM and PO work with the team to identify other tasks from the sprint backlog the blocked developer can work on — preventing idle time.
Scenario 2 — Organizational Impediment:
A department head requests that a senior developer attend a 3-day conference mid-sprint. This threatens the sprint goal. The SM has the courage to push back — not rudely, but firmly — explaining the impact on the sprint. If the conference is mandatory, the SM works with the PO to reduce sprint scope accordingly, rather than pretending the sprint can still succeed at full scope.
Scenario 3 — Impediment the SM Cannot Resolve:
A critical third-party API the team depends on will be unavailable for 5 days due to vendor maintenance. The SM cannot fix the vendor's schedule. The correct action: log it, inform the PO, and collaboratively re-plan the sprint. Items dependent on the API are de-prioritized; independent items are pulled forward. The sprint goal may need adjustment — the PO makes that call.
The PMP exam tests this distinction:
• SM resolves impediments — this is non-negotiable
• SM does NOT resolve them by making technical decisions — they facilitate resolution
• If the SM cannot resolve an impediment, they escalate — never just accept it
• Impediments are raised in the Daily Scrum but never discussed there — discussion happens immediately after or separately
• A Scrum team with many recurring impediments has a process problem — address it in the Retrospective
Impediment Management:
✅ Raised in Daily Scrum (Question 3); resolved separately
✅ SM logs ALL impediments in the Impediment Log
✅ SM resolves immediately — same day is the target
✅ SM escalates if beyond their authority
✅ 5 categories: Technical, Organizational, Process, Interpersonal, External
✅ Recurring patterns → Retrospective action items
✅ Taskboard "Blocked" column = visual impediment indicator
6.1 Definition of Done (DoD)
The Definition of Done is a checklist agreed by the Development Team that defines when a sprint item is truly complete. It is created during Sprint Planning and cannot be loosened to claim false progress.
Common DoD Checklist Items:
| Category | Checklist Items |
|---|---|
| Code Quality | X% of code complete; Code counter-checked by colleague; No bugs discovered |
| Testing | Successful tests for user story; All acceptance criteria fulfilled; Non-functional elements tested; Performance tests passed; Hardware tested |
| Documentation | Technical documentation compiled; Legal docs (licenses) compiled |
| Deployment | Software running on test server; Interface open; Localization available |
The DoD vs. DoR confusion is common on the PMP exam:
• DoR = Item is ready to START being worked on (can enter sprint)
• DoD = Item is truly FINISHED (can exit the sprint as shippable)
The DoD can evolve — e.g., after successful sprints, items may go live directly instead of to a test server.
✅ DoD = checklist created by Dev Team during Sprint Planning
✅ DoD cannot be "fudged" to register false progress
✅ Conditions of Satisfaction (CoS) also checked against DoD
✅ Item is truly done ONLY when DoD AND CoS are met
✅ PO accepts item when DoD + CoS are satisfied
6.2 Documentation in Scrum
Scrum doesn't eliminate documentation — it changes its purpose and timing. Documentation in Scrum is developed "on the job" — not compiled at the end.
Three Rules for Great Scrum Documentation:
1️⃣ Essential
Document only what is truly needed. Precise enough to be understood, but not a book. Documents are created to be used — not because a process demands them.
2️⃣ Timely
Documentation is written alongside development — not after. Provides immediate value and keeps information current.
3️⃣ Valuable
Value of documentation must exceed the cost of writing it. If nobody will use a document, don't create it.
Test-Driven Design
Tests are written before coding begins. The developer knows exactly what test the code must pass before writing a single line. Early tests fail frequently — success rates improve as development progresses.
The Agile Manifesto says "Working software over comprehensive documentation" — but this does NOT mean no documentation. The PMP exam will ask about the appropriate level. The correct answer is: documentation should be just enough, just in time.
7. The Sprint Review
The Sprint Review occurs at or near the end of a sprint (ideally a few days before end to allow last-minute corrections). It is a working meeting — not a presentation show.
Who Attends:
- Development Team ✅
- Scrum Master ✅
- Product Owner ✅
- Stakeholders ✅ (essential — they provide external perspective)
- Colleagues from other divisions (optional, encouraged)
Sprint Review Agenda:
- Sprint Goal Summary — What was the sprint supposed to achieve?
- Progress Overview — What was accomplished? What's still open?
- Demonstrations — Only for "done" items. Interactive demos preferred.
- Discussion — Are stakeholders satisfied? What changes are needed?
- Backlog Impact — How do learnings affect future sprint priorities?
Payment Gateway Sprint Review Example: The team is reviewing a completed payment gateway. During the review, business development reports a new Apple Pay contract was just signed. The stakeholders' input immediately influences the product backlog — Apple Pay integration jumps to the next sprint's priority. This real-time feedback loop is one of Scrum's greatest strengths.
The Sprint Review is NOT a sign-off ceremony. Items are "done" when they meet the DoD and the PO accepts them. The review is for analysis and feedback — not formal release. If the PO decides to return items after the review, this should be the exception, never the rule.
Sprint Review:
✅ Working meeting — no PowerPoints, no formalities
✅ Led by Scrum Master
✅ Stakeholders MUST attend
✅ Demos only for DONE items
✅ NOT a sign-off — PO already accepted done items
✅ Outcomes feed into next sprint's backlog
8. The Sprint Retrospective
The Sprint Retrospective is the team's self-improvement meeting — held after every sprint. It focuses on the process, not the product (that's the Sprint Review's job).
Three Core Questions:
✅ What did we do well?
Celebrate successes. Identify what to preserve and amplify in the next sprint.
❌ What didn't go well?
Identify root causes of problems. Not blame — systemic analysis. (Too many items? Wrong estimates? Missing skills?)
🔄 What will we improve?
Actionable commitments for the next sprint. No vague wishes — specific, measurable changes.
Meeting Format:
- Duration: 90–120 minutes (timeboxed)
- Attendees: Development Team only (PO optional)
- Led by: Scrum Master or rotating team member
- Structure: Sum up → Discuss → Solve → Wrap-up
What to Do with Unfinished Items:
Items that don't meet their DoD by sprint end are not carried over automatically. They return to the Product Backlog with a new priority. The next sprint is planned from a blank sheet. The PO may need to adjust the DoR or story point estimates. Never say an incomplete item is "done" — Scrum integrity depends on honesty.
The PMP exam often tests the difference between Sprint Review and Sprint Retrospective:
• Sprint Review = about the PRODUCT (what was built?)
• Sprint Retrospective = about the PROCESS (how did we work?)
The Retrospective is Agile Principle #12: "At regular intervals, the team reflects on how to become more effective."
Sprint Retrospective:
✅ Focus: Process improvement (not product)
✅ Attendees: Dev Team (PO optional)
✅ Duration: 90–120 minutes
✅ Outputs: Actionable improvements for next sprint
✅ Incomplete items → back to backlog (not auto-carried)
✅ Never say an item is done when it isn't
9. When Scrum Projects Fail
Not all Scrum projects succeed. Knowing failure patterns is crucial for the PMP exam and for real projects:
| Failure Mode | Description | Prevention |
|---|---|---|
| "Everyone's Doing It" | Adopting Scrum because it's trendy, not because it fits | Assess project fit before adopting any framework |
| Wrong Team | Solo-preference developers, unwilling POs, wrong personalities | Screen team members for collaborative mindset; train and motivate |
| Wrong Project | Too large (airport construction), too simple (basic website), too compliance-heavy | Match framework to project type and complexity |
| Disruptive Environment | Team members poached, surprise audits, restructuring mid-sprint | Protect the team; shield from organizational disruption; use SM as buffer |
"To the man with a hammer, everything looks like a nail." Just because you've mastered Scrum doesn't mean every project needs it. Scrum won't help you build an airport. A simple website doesn't need a Scrum team. Match the tool to the problem — this is a fundamental PMP principle.
The PMP exam frequently presents scenarios where Scrum is being misapplied. Key failure signals:
• Stakeholders giving instructions directly to developers
• Sprint goals changing mid-sprint
• Multiple Product Owners
• Incomplete items auto-carried into next sprint
• DoD criteria loosened to register false progress
10. Scrum in Other Industries
Scrum originated in software but has been successfully applied across many industries. The key: the principles apply wherever there is a need for iterative delivery, team collaboration, and adaptation to change.
| Industry | Sprint = ? | DoD = ? | Daily Scrum = ? |
|---|---|---|---|
| Construction | 2-week design/planning cycle | Completed architectural iteration | Morning site meeting |
| Healthcare (Hospital) | Patient treatment round | Patient discharge / healed bone / normal labs | Morning rounds |
| Wholesale/Logistics | Supplier onboarding cycle | Supplier meets all delivery requirements | Daily sync on deliveries |
| Marketing | Campaign cycle (2–3 weeks) | Campaign launched and metrics tracked | Daily team standup |
| Legal / Compliance | Case phases | Brief submitted / hearing completed | Daily case review |
Swiss Construction Study: A 4-story apartment building was built using Scrum. Team: 3 architects, construction engineer, engineer, accountant, interior designer. Initial 5-day sprints extended to 2 weeks. Used Trello for distributed task management. Key lesson: the construction crew (actual builders) should have been included — their absence meant focus stayed on planning rather than actual construction.
Scrum Deployment Tips for Non-Software Fields:
- Write down all jobs to be done → This is your backlog
- Define each item concisely on a postcard → User story
- Pin cards on a notice board; discuss priorities with team
- Set sprint timeframe: 2–3 weeks
- Use a Kanban board: To Do → In Progress → On Hold → Done
- Hold 15-minute daily standups
- Meet with team after each cycle (Retrospective)
- Meet with stakeholders after each cycle (Review)
The PMP exam (especially the Agile section) tests whether candidates can apply Agile principles to non-software scenarios. The Kanban board (4 columns: To Do, In Progress, On Hold, Done) is a key hybrid tool used in many industries. Know it.
📋 Kanban vs. Scrum — Complete Comparison
Both Kanban and Scrum are Agile frameworks — but they work very differently. The PMP exam frequently presents scenarios requiring you to distinguish between them or choose which fits better.
| Dimension | ⚡ Scrum | 📋 Kanban |
|---|---|---|
| Cadence | Fixed-length sprints (1–4 weeks); timeboxed | Continuous flow; no fixed iterations |
| Roles | 3 defined roles: PO, SM, Dev Team | No prescribed roles; existing team structure |
| Planning | Sprint Planning every sprint; items selected in advance | Items pulled continuously as capacity allows |
| Board | Sprint board resets each sprint | Persistent board; cards flow continuously |
| WIP Limits | Not required (but recommended) | WIP (Work In Progress) limits are mandatory per column |
| Change Mid-Cycle | Prohibited mid-sprint (sprint goal locked) | Allowed at any time — new items added as soon as capacity opens |
| Ceremonies | 4 fixed ceremonies (Planning, Daily, Review, Retro) | No prescribed ceremonies; teams choose their own cadence |
| Metrics | Velocity, Burndown Chart, Story Points | Lead Time, Cycle Time, Throughput, Cumulative Flow Diagram |
| Backlog | Prioritized Product Backlog (managed by PO) | Queue of items; no formal ownership required |
| Best For | Teams with predictable sprint cadence; complex, feature-rich products | Teams with variable, unpredictable work; maintenance/support teams; ops |
| Learning Curve | Higher — roles, ceremonies, artefacts all prescribed | Lower — start with existing process and evolve |
| Release | At end of sprint (or planned release) | Continuous delivery — items released when done |
Key Kanban Concepts the PMP Tests
🔢 WIP Limits (Work In Progress Limits)
Each column on a Kanban board has a maximum number of items allowed simultaneously. When a column is full, no new work enters until existing work moves forward. This prevents bottlenecks, forces focus, and surfaces process problems immediately.
Example: "In Progress" column has a WIP limit of 3. If 3 items are already in progress and a 4th needs to start, the team must first finish one before starting anything new. This exposes hidden constraints instead of hiding them under multitasking.
⏱ Lead Time vs. Cycle Time
Lead Time: Total time from when a customer request is received to when it is delivered. Measures the customer's wait experience.
Cycle Time: Time from when the team STARTS working on an item to when it is delivered. Measures team efficiency.
Lead Time ≥ Cycle Time always. The gap between them represents queue/wait time.
Kanban Board (4-Column Standard)
| 📋 BACKLOG | 🔄 IN PROGRESS | ⏸ ON HOLD | ✅ DONE |
|---|---|---|---|
| All incoming work items, prioritized. Items pulled into In Progress as capacity becomes available. | Actively being worked on. WIP limit enforced here. Prevents overload and multitasking waste. | Items temporarily blocked or waiting. Unlike Scrum (which returns these to backlog), Kanban keeps them visible on the board. | Complete. In Kanban, "done" items can be released immediately — no sprint end gate required. |
When to Choose Scrum vs. Kanban
| Situation | Better Choice | Why |
|---|---|---|
| Building a new product with defined feature sets | ✅ Scrum | Sprint structure ensures focused delivery of specific features |
| IT support / help desk / maintenance work | ✅ Kanban | Unpredictable incoming work flows better without fixed sprint commitments |
| Team new to Agile needing clear structure | ✅ Scrum | Defined roles and ceremonies provide guardrails for beginners |
| Existing team wanting to improve their current process | ✅ Kanban | Start where you are; evolve incrementally without restructuring |
| Need continuous deployment / release | ✅ Kanban | No sprint gate; items ship as soon as they're done |
| Complex product with many interdependencies | ✅ Scrum | Sprint planning and retrospectives manage complexity systematically |
| Mixed: new development + ongoing support | ✅ Scrumban | Hybrid: sprint structure for new features + Kanban flow for support |
The PMP exam often asks: "What is the main difference between Scrum and Kanban?" The most important answer: Scrum uses timeboxed sprints with a locked sprint goal; Kanban uses continuous flow with WIP limits and no fixed iterations. If a scenario shows a team that can't commit to sprint goals because work is too unpredictable → Kanban is the better fit.
Kanban vs. Scrum Quick Facts:
✅ Scrum = sprints + roles + ceremonies + backlog
✅ Kanban = continuous flow + WIP limits + no roles required
✅ Both = visual board + pull-based work + Agile mindset
✅ WIP limit = Kanban's most critical rule
✅ Lead Time = customer wait (request → delivery)
✅ Cycle Time = team efficiency (start → delivery)
✅ Scrumban = hybrid when both apply
✅ On Hold column: Kanban keeps it on board; Scrum returns to backlog
11. Software for Scrum
While Scrum can run with just paper and flipcharts, dedicated software dramatically improves tracking, collaboration, and transparency.
| Tool | Type | Key Features | Used By |
|---|---|---|---|
| Axosoft | SaaS / In-house | Product backlog management, Daily Scrum tool, documentation | Boeing, Cisco |
| VersionOne | Agile/Scrum cockpit | Progress tracking, task admin, social communication tools | Enterprise teams |
| Yodiz | Dedicated Scrum | Sprint planning, backlog maintenance, epic handling, bug tracking | Agile teams globally |
| Trello | Kanban/visual board | Distributed teams, card-based task management | Small-medium teams |
| Jira | Full Agile suite | Scrum boards, sprint management, velocity tracking | Software industry standard |
The PMP exam won't test specific software, but may test whether you understand that Scrum software should support Agile values — not reintroduce waterfall thinking (milestone obsession, rigid task assignment, etc.).
12. Certified Scrum Masters and Product Owners
Certification Bodies:
| Organization | Scrum Master Cert | Product Owner Cert |
|---|---|---|
| Scrum.org | PSM I, PSM II, PSM III | PSPO I, PSPO II |
| Scrum Alliance | CSM (Certified Scrum Master) | CSPO (Certified Scrum Product Owner) |
Scrum Master Certification Levels (Scrum.org PSM):
PSM I — Fundamental
Demonstrates understanding of Scrum terminology, framework, and how to apply it in basic contexts. Entry-level certification.
PSM II — Advanced
Deeper understanding of Scrum principles and implementation in complex situations. Shows ability to adapt Scrum across environments.
PSM III — Expert
Can implement Scrum in any organization. Works with complex, large-scale projects. Understands all aspects of Scrum values and philosophy.
Product Owner Certification Levels (Scrum.org PSPO):
PSPO I — Foundation
Understanding of how Scrum works and the value it brings to products. Minimum knowledge any professional PO should demonstrate.
PSPO II — Advanced
Comprehensive knowledge of Scrum, deep understanding of product backlog management, ability to lead Scrum projects professionally.
For the PMP exam, you don't need Scrum certification — but understanding the Scrum roles, responsibilities, and ceremonies is tested extensively in the Agile domain (which makes up ~50% of the current PMP exam). The PMI also offers the PMI-ACP (Agile Certified Practitioner) — a dedicated Agile certification that covers Scrum, Kanban, XP, and other frameworks.
📅 Ceremonies Master Reference Table
All 4 Scrum ceremonies in one consolidated reference — the most-tested topic on the PMP Agile exam. Print this and memorize it.
| Ceremony | When | Duration (2-wk Sprint) | Who Attends | Who Leads | Purpose | Key Output |
|---|---|---|---|---|---|---|
| Sprint Planning | Day 0 of each sprint | Up to 8 hours | PO + SM + Dev Team | SM facilitates; PO sets goal; Dev Team plans tasks | Define what will be built (sprint goal) and how (task breakdown) | Sprint Backlog + Sprint Goal |
| Daily Scrum | Every day of sprint, same time | 15 minutes exactly | Dev Team (SM optional; PO can attend silently) | Dev Team (any member); SM facilitates optionally | Synchronize the team; surface impediments; plan next 24 hours | Updated impediment list; updated Burndown Chart (end of day) |
| Sprint Review | End of sprint (or few days before) | Up to 4 hours | PO + SM + Dev Team + Stakeholders + Optional: other colleagues | Scrum Master (best positioned to manage agenda) | Demonstrate DONE increments; gather stakeholder feedback; inspect product | Feedback → updated Product Backlog priorities |
| Sprint Retrospective | After Sprint Review, before next sprint | 90–120 minutes | Dev Team (PO optional; Stakeholders NEVER) | SM or rotating team member | Inspect the PROCESS (not the product); identify improvements | Actionable improvement items for next sprint |
Ceremonies — What Each Is NOT
| Ceremony | Common Misconception | Reality |
|---|---|---|
| Sprint Planning | PO assigns tasks to developers | Dev Team self-selects tasks; PO only defines the WHAT, not the HOW |
| Daily Scrum | Status report to management / problem-solving meeting | 15-min sync for Dev Team only; problems resolved separately |
| Sprint Review | Sign-off ceremony / PowerPoint showcase | Working meeting; stakeholders give real feedback; not a formal presentation |
| Sprint Retrospective | Blame session / optional if sprint went well | Mandatory every sprint; blameless; focuses on process not people |
Duration Formula (for any sprint length)
📐 Ceremony Duration Scaling Rule
Scrum guidelines scale ceremony duration to sprint length:
Sprint Planning: Max 2 hours per week of sprint (2-week sprint → 4 hrs; 4-week sprint → 8 hrs)
Daily Scrum: Always 15 minutes regardless of sprint length
Sprint Review: Max 1 hour per week of sprint (2-week sprint → 2 hrs; 4-week sprint → 4 hrs)
Sprint Retrospective: Max 45 minutes per week of sprint (2-week sprint → 90 min; 4-week sprint → 3 hrs)
The most commonly confused pair on the PMP exam:
Sprint Review = PRODUCT inspection (what was built?) — stakeholders attend
Sprint Retrospective = PROCESS inspection (how did we work?) — stakeholders do NOT attend
Second most confused: Daily Scrum attendees. Only the Development Team is required. SM may attend to facilitate. PO may observe. Stakeholders never.
Ceremonies Quick-Ref:
✅ Planning → Sprint Backlog + Sprint Goal | PO+SM+Dev
✅ Daily Scrum → 15 min | Dev Team | 3 questions
✅ Review → Done demos | PO+SM+Dev+Stakeholders | product feedback
✅ Retrospective → Process improvement | Dev Team (+PO optional) | no stakeholders
✅ All are TIMEBOXED — duration is a ceiling, not a target
✅ All 4 ceremonies = transparency + inspect + adapt
14. Conclusion — Key Takeaways
"Good is the enemy of great, but great is the enemy of shipped." — Jeffrey Zeldman
Scrum is not a silver bullet — it's a framework for teams who want to deliver real value continuously, adapt to change, and take ownership of their work. The best Scrum practitioners know when to apply it, when to adapt it, and when to choose a different approach entirely.
Final PMP Exam Reminders:
✅ Agile ≈ 50% of current PMP exam content
✅ Agile = values + principles; Scrum = specific framework
✅ Product Owner = product value; Scrum Master = process; Dev Team = delivery
✅ Sprint goal is LOCKED once sprint starts
✅ Only PO can accept or reject completed items
✅ Stakeholders → PO only (not directly to team)
✅ Retrospective = process improvement (not product)
✅ DoD ≠ DoR — know the difference
✅ Story Points ≠ Hours — relative effort, not time
🏆 Master Cheat Sheet — All Critical Facts
| Topic | Critical Fact |
|---|---|
| Agile Manifesto | 17 signatories, February 2001, 4 values, 12 principles |
| Scrum Founders | Jeff Sutherland + Ken Schwaber (1995 conference, Austin TX) |
| Scrum Origin Word | Rugby — coordinated team effort, not an acronym |
| Scrum Roles | Product Owner, Scrum Master, Development Team (+ Stakeholders external) |
| Product Backlog Owner | Product Owner (one, never two) |
| Sprint Backlog Owner | Development Team |
| Sprint Length | 1–4 weeks (2 weeks preferred) |
| Daily Scrum Duration | 15 minutes, timeboxed |
| Sprint Review Attendees | Dev Team + SM + PO + Stakeholders |
| Sprint Retro Attendees | Dev Team (PO optional) |
| Retrospective Duration | 90–120 minutes |
| DEEP Rules | Detailed, Emergent, Estimated, Prioritized |
| Fibonacci Sequence | 1, 2, 3, 5, 8, 13, 20, 40, 100 (story points) |
| CPI Formula | EV ÷ AC (>1 good, <1 bad) |
| Velocity Formula | Developers × Hours × Working Days |
| Burndown Y-Axis | Work Remaining (hours); X = Time elapsed |
| Definition of Done | Checklist by Dev Team; cannot be weakened to fake completion |
| Definition of Ready | Item criteria met before it can enter a sprint |
| Stakeholders Contact | ONLY through Product Owner — never directly to team |
| Test-Driven Design | Write tests BEFORE writing code |
| Kanban Columns | To Do → In Progress → On Hold → Done |
| Planning Poker Goal | Consensus-building, not winning; uses Fibonacci cards |
| Epic | Large user story; broken into smaller stories for sprints |
| User Story Template | "As [role] I want [feature] so that [benefit]" |
| Team Size | 3–9 developers (optimal) |
| T-Shaped Skills | Broad general knowledge + Deep specialist expertise |
🎯 PMP Exam Summary — Agile/Scrum Domain
The current PMP exam is approximately 50% predictive (Waterfall) and 50% Agile/hybrid. Expect scenario-based questions testing your ability to apply Agile principles, not just recall definitions.
Most Commonly Tested PMP Agile Topics:
- When to use Agile vs. Waterfall vs. Hybrid — Know the selection criteria
- Scrum Roles and Boundaries — Who can do what; who reports to whom
- Servant Leadership — Scrum Master as facilitator, not director
- Sprint ceremonies — Planning, Daily Scrum, Review, Retrospective (purpose and attendees)
- Backlog management — DEEP rules, prioritization, DoR, DoD
- EVM in Agile — EV, AC, CPI in sprint context
- Burndown Charts — Reading and interpreting
- User Stories and Epics — Writing and decomposition
- Self-organizing teams — Team selects their own work; no external assignment
- Change management in Agile — Welcome change; update backlog; don't panic
Top 5 PMP Exam "Trap" Answers in Agile Questions:
❌ "The PM assigns tasks to team members" → WRONG. Dev Team self-assigns from sprint backlog.
❌ "The Scrum Master approves sprint items" → WRONG. PO accepts/rejects, not SM.
❌ "Stakeholders attend Daily Scrum" → WRONG. Dev Team only.
❌ "Carry incomplete items to next sprint automatically" → WRONG. Return to backlog, re-prioritize.
❌ "Multiple Product Owners for a large project" → WRONG. Always one PO.
Agile Exam Formula Summary:
CPI = EV ÷ AC (Cost Performance Index)
CV = EV − AC (Cost Variance)
Velocity = Devs × Hours × Working Days
Sprint Capacity = (Days × 8 hrs) − Meetings − Other Activities − Buffer
ROI at story level = Business Value ÷ Story Points
Payback Period = Time to recover all development costs from product revenue
🧠 Practice Quiz — 15 PMP-Style Scenario Questions
Click each question to reveal the answer and explanation. These are styled exactly like PMP exam questions — scenario-based, with one best answer.
⚠️ Try to answer each question mentally BEFORE clicking to reveal.