PMI PMP: Agile, Scrum & Hybrid Delivery — Study Guide

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Part of the PMP — Study Guide. Practice with verified answers in the PMI exam hub, or take timed practice tests on ExamRoll.io.

Scrum Roles, Ceremonies, and Artifacts

Scrum operates on a deliberately small role structure because accountability diffusion is one of the primary failure modes of complex delivery. The Product Owner owns the what and the why: they define value, prioritize the backlog, and hold the authority to accept or reject increments. The Scrum Master owns the how well the process runs: they are a servant-leader who removes impediments, coaches on agile practices, and shields the team from disruption. The Developers (the entire delivery team, not just coders) own the how: they self-organize to convert backlog items into a working increment each sprint.

These roles must be filled by real, engaged people. A disengaged or absentee Product Owner is one of the most destructive patterns in agile delivery — without their real-time prioritization and acceptance, sprint reviews become status meetings rather than value-validation events, feedback loops stretch, and the team drifts toward building the wrong thing. When facing an absent PO, the correct action is to escalate to the sponsor and re-establish the role, not to have the Scrum Master proxy decisions permanently.

The core ceremonies form a closed feedback loop:

• Sprint Planning
  • Purpose: Negotiate sprint goal and forecast
  • Frequency: Start of sprint
  • Primary Output: Sprint backlog
• Daily Standup
  • Purpose: Synchronize, surface impediments
  • Frequency: Daily, timeboxed 15 min
  • Primary Output: Adjusted plan for the day
• Sprint Review
  • Purpose: Inspect the increment with stakeholders
  • Frequency: End of sprint
  • Primary Output: Feedback, updated product backlog
• Sprint Retrospective
  • Purpose: Inspect the process
  • Frequency: End of sprint
  • Primary Output: Concrete improvement actions

The artifacts — Product Backlog, Sprint Backlog, and Increment — each have a commitment attached: the Product Goal, the Sprint Goal, and the Definition of Done, respectively. These commitments are what prevent Scrum from degenerating into “iterative waterfall.”

Backlog Management and User Stories

The product backlog is a living, ordered list — not a specification document frozen at project start. The Product Owner maintains it in collaboration with the team, refining items so that the top of the backlog is small, well-understood, and ready to pull. A common cadence is spending 5–10% of team capacity on backlog refinement each sprint.

User stories follow the familiar pattern: As a [persona], I want [capability], so that [benefit]. The benefit clause matters as much as the capability — it is what allows the team to propose alternative solutions and what enables the PO to decide whether the story is still worth doing when priorities shift.

Acceptance criteria are the observable, testable conditions under which the PO will accept the story. They differ from the Definition of Done: acceptance criteria are story-specific (does the login screen lock after five failed attempts?), while DoD is universal to every story (was it code-reviewed, tested, documented, deployed to staging?).

When a stakeholder brings a new requirement mid-project — even one that resembles prior work — the PO should not simply blurt out a date. The correct response is to capture the request as a candidate backlog item, work with the team to size it (perhaps using reference stories as anchors for relative estimation), and then place it in the backlog according to its value relative to existing items. Prior similarity accelerates sizing but does not bypass the prioritization conversation.

DoR, DoD, and Iteration Planning

The Definition of Ready is a gate on the entry to a sprint. A story is ready when it is small enough to complete within a sprint, has clear acceptance criteria, has known dependencies identified, and is understood by the team. Enforcing DoR prevents the team from pulling half-baked work that will stall mid-sprint on unanswered questions.

The Definition of Done is a gate on the exit. It is the shared, non-negotiable checklist that transforms “we finished coding” into “this is a potentially shippable increment.” A robust DoD typically includes automated tests passing, code reviewed, security scans clean, documentation updated, and — critically — non-functional requirements like performance and observability addressed. Involving operations and QA in defining the DoD is what prevents the pattern where an increment “works” in the sprint review but collapses under real load in production. If operations raises a performance concern after a sprint and the data already exists in logs, the mature response is to bring that concern into refinement, add performance thresholds to the DoD, and create backlog items to address the gap — not to dismiss it as “not in scope.”

MVP, Release Planning, and Incremental Delivery

The Minimum Viable Product is the smallest coherent slice that lets the team test a key assumption with real users. Its purpose is learning, not merely delivery. Release planning then layers on top: given a roadmap of MVP followed by incremental releases, the team forecasts which capabilities land in which release using velocity as a rough guide.

Incremental delivery is what buys the organization optionality — the ability to change direction based on evidence rather than opinion. Waiting for a “complete” release before showing anything to users is the anti-pattern that agile is specifically designed to prevent.

Estimation, Story Points, and Velocity

Story points measure relative effort, complexity, and uncertainty — not duration. A five-point story is roughly five times the effort of a one-point story for that specific team. Velocity (points completed per sprint) then emerges empirically over several sprints and is used for forecasting ranges, not for making calendar commitments.

Treating story points as fixed days is a serious trap for several reasons. First, it destroys the abstraction: if 1 point = 1 day, the team will simply estimate in days and inflate to hit deadlines. Second, it eliminates the uncertainty signal — a 13-point story is not just “long,” it is risky, and that risk should trigger decomposition. Third, it lets management weaponize the numbers (“you said 40 points, why did you only finish 32?”) which drives sandbagging behavior. The correct use is: velocity trend + backlog size → probabilistic release forecast, communicated as a range.

Managing Impediments, Interruptions, and Flow

The Scrum Master’s most tangible job is impediment removal. When a team member is silently struggling — perhaps too proud or too new to raise it — the team leader should engage directly, understand the impediment, and either help resolve it or escalate. Ignoring the daily standup’s purpose is what allows this pattern to fester; inconsistent standup attendance creates knowledge silos, hides blockers, and lets small issues become schedule risks. Attendance is non-negotiable precisely because the ceremony’s value is in synchronization, not status reporting.

Ad-hoc interruptions — the “urgent” request that bypasses the backlog — are equally corrosive. They erode the sprint goal, invalidate the forecast, and train stakeholders that the process can be circumvented. The correct handling is to route new requests through the PO, who decides whether they justify a sprint cancellation (rare) or belong in a future sprint (usually).

For hybrid teams where testing or another discipline becomes a bottleneck, flow visualization via Kanban boards and burndown/burnup charts exposes the constraint. If the team identifies a tool that could unblock testing, the project manager should not unilaterally approve or reject — they should evaluate the proposal collaboratively, check organizational governance (procurement, security), engage the PO on backlog impact, and then decide. Reflexive approval skips due diligence; reflexive denial ignores the team’s expertise.

Retrospectives and Continuous Improvement

Retrospectives close the loop. A good retrospective produces one or two concrete, owned improvement actions — not a vent session. Bringing operations and QA into retrospectives early prevents the classic handoff failures where teams optimize for sprint-end demos but not for production reality. Continuous improvement is the mechanism that keeps velocity honest, DoD meaningful, and the team’s engagement high across the life of the product.

Practical Problem: Use-Case Scenario

Scenario: Priya Nair is Scrum Master for the “LumenPay” mobile wallet team at a fintech firm, running two-week sprints with six developers, a QA engineer, and a UX designer. Over the last three sprints, the Product Owner, Marcus Reeves, has attended only one sprint planning session and no sprint reviews, citing conflicting responsibilities as head of Retail Partnerships. Stakeholders from Compliance and Fraud Ops have started emailing the developers directly with conflicting priority requests, and the team has carried over 34 of 82 story points across the last two sprints. The sponsor, VP of Product Anita Chen, is beginning to question the team’s velocity.

Challenge: Priya must restore Product Owner engagement and stop the backlog fragmentation without overstepping her servant-leader role by making product decisions herself.

Recommended Approach:

1. Document specific impacts of PO absence over the last three sprints — carryover points, ambiguous acceptance criteria, unresolved backlog items, and the count of direct stakeholder requests bypassing the PO — to build a fact-based case.
2. Hold a one-on-one with Marcus first, sharing the data and asking directly whether he can commit the 10–15 hours per week the role requires, or whether the role needs to be reassigned or split.
3. Escalate formally to Anita Chen with the documented evidence, presenting two options: reassign the PO role to someone with capacity, or negotiate a reduction in Marcus’s Retail Partnerships duties.
4. Coach the development team to redirect all incoming stakeholder requests to the product backlog rather than accepting them ad hoc, and reinforce that only the PO can reprioritize.
5. Once a committed PO is confirmed, run a backlog refinement workshop to re-baseline priorities, clean up acceptance criteria, and reset the sprint goal for the next iteration.
6. Establish a working agreement specifying PO attendance at planning, review, and at least two refinement sessions per sprint.

Why This Works: Escalating the vacancy to the sponsor preserves role integrity — the Scrum Master must not become a proxy Product Owner, because that permanently masks the organizational problem and compromises value-based prioritization. Grounding the escalation in concrete metrics keeps the conversation about delivery outcomes rather than personalities, and re-routing stakeholder traffic through the backlog restores the single-source-of-truth discipline that Scrum depends on.

← Team Leadership · All domains · Scope →

Practice these questions → · Timed practice on ExamRoll.io →