Scrum in Practice: Sprints, Roles & Ceremonies

The Software Development Lifecycle

Chapter 3 · Scrum in Practice: Sprints, Roles & Ceremonies

Scrum is one specific, concrete implementation of Chapter 2's own values — a timeboxed iteration (the sprint), three defined roles, and four ceremonies whose entire purpose is to make Chapter 2's own "early and continuous delivery" and "responding to change" principles actually happen on a schedule, rather than by hoping the team remembers to. This chapter verifies exactly what two of those ceremonies buy you when they're skipped.

The Three Roles

Role	Owns
Product Owner	The backlog and its priority order — what gets built, and in what order, based on business value
Scrum Master	The process itself — facilitating ceremonies, and specifically removing impediments the team can't clear on their own
Development Team	How the work gets built, and the commitment made at sprint planning

The Scrum Master isn't a manager

Nothing in the role description involves assigning tasks or evaluating individual performance — the Development Team is self-organizing, per Chapter 2's own eleventh principle. The Scrum Master's actual job, verified concretely below, is speed: how fast a blocker gets from "someone hit it" to "someone's fixing it."

Daily Standups: What Removing a Blocker Actually Costs Without One

# a 10-day sprint; a developer is blocked on day 2, needing an API key
# from another team - resolvable in 1 day, once someone actually asks
SPRINT_LENGTH = 10
BLOCKED_ON_DAY = 2
RESOLUTION_TIME_ONCE_ESCALATED = 1
    

Verified directly — the standup itself is what turns a week-long blocker into a one-day blocker

With a daily standup: the blocker is surfaced on day 2 itself, resolved by day 3 — 1 day of lost progress. With no daily check-in — the blocker only comes up at the sprint review on day 10: resolved into the next sprint, having cost 8 days of lost progress within this one. 7 extra days lost, purely from the absence of a daily check-in — 70% of the entire sprint's own length spent unknowingly blocked.

The standup isn't a status report to a manager

Nothing in this finding required anyone to justify their time or account for hours worked. The only thing that mattered was a daily moment where "I'm blocked" becomes audible to someone who can act on it — the Scrum Master's own defined job. A standup used to report progress upward, rather than surface blockers outward, captures none of this 70% finding.

Sprint Planning: What Ignoring Known Velocity Actually Costs

PAST_SPRINT_COMPLETIONS = [19, 22, 20, 21, 18]  # the last 5 real sprints
KNOWN_VELOCITY = sum(PAST_SPRINT_COMPLETIONS) / len(PAST_SPRINT_COMPLETIONS)  # = 20.0
    

Verified directly — overcommitting past known capacity didn't produce more work, only more visible failure

Committing to 35 points at planning, ignoring a known velocity of 20: the team's real throughput never changed — 20 points actually completed, 15 carried over incomplete. A 57% completion rate against what was committed. Committing to 20 points, matching known velocity: 20 completed, 0 carried over — a full 100%.

The team didn't do less work by committing to less — they finished all of it

Both scenarios produced the exact same 20 points of real output — the team's actual capacity didn't change based on what was written on a planning board. The only thing overcommitting changed was whether that output looked like a success (100% of a realistic commitment) or a failure (57% of an unrealistic one), for identical real work.

A Worked Sprint Cadence

Day	Ceremony	Purpose (verified above)
Day 1	Sprint Planning	Commit to a realistic scope — matching known velocity, not aspiration
Days 1–10	Daily Standup	Surface blockers within hours, not days — the 70% finding above
Day 10	Sprint Review	Demo working software to stakeholders, gather real feedback (Chapter 2's own early-feedback finding)
Day 10	Sprint Retrospective	The team reflects on its own process — covered in full in Chapter 9

Where This Connects

This chapter's finding	What it connects to
70% of a sprint lost to an unsurfaced blocker	Chapter 1's own interruption-cost finding — both are real costs of information not reaching the person who could act on it in time
Overcommitting produced identical real output, worse-looking results	Chapter 6's own estimation material — a commitment is only meaningful if it's grounded in a real, measured capacity

Hands-On Exercises

Exercise 1

Using this chapter's own blocker simulation, change BLOCKED_ON_DAY from 2 to 8 (the blocker occurs near the end of the sprint instead of near the start). Determine the new "days lost" figure for both the with-standups and without-standups scenarios, and explain why the gap between them shrinks.

📄 View solution

Exercise 2

Using this chapter's own sprint capacity simulation, add a sixth past sprint completion of 12 points (a notably bad sprint, perhaps due to team illness) to PAST_SPRINT_COMPLETIONS. Recompute the known velocity and determine the new completion rate for a sprint committing to exactly that new velocity.

📄 View solution

Exercise 3

This chapter's own overcommitted-sprint simulation (35 points committed) still completed exactly the known velocity of 20 points. Determine at what committed-points value the completion rate first drops below 90%, using the same simulation logic.

📄 View solution

Chapter 3 Quick Reference

Three roles: Product Owner (backlog/priority), Scrum Master (process/impediments), Development Team (how the work gets built)
Verified: a blocker surfaced at a daily standup cost 1 day; the same blocker surfaced only at the sprint review cost 8 — a 70%-of-sprint difference
Verified: overcommitting past known velocity (35 vs. a real 20) produced identical actual output — 20 points either way — but a 57% completion rate instead of 100%
The real value of ceremonies: not ritual — each one moves specific information to the person who can act on it, at a specific, predictable time
A worked cadence: Day 1 planning, daily standups throughout, Day 10 review and retrospective
Next chapter: Kanban & Flow-Based Work — a genuinely different shape for teams whose work doesn't fit sprint boundaries well