Scrum

The most-implemented Agile framework. Defined by the Scrum Guide (Ken Schwaber + Jeff Sutherland). Three roles, five events, three artifacts. Interview questions test whether you know the vocabulary and have actually lived through Scrum (the difference shows fast).

The roles

The 2020 Scrum Guide dropped “Development Team” — there’s just “Scrum Team” with three roles (PO, SM, Developers).

Common antipatterns:

• PO who’s actually a project manager — assigns work, micromanages “how.” Real PO decides “what” and “why.”
• SM as glorified meeting facilitator — fills time without removing impediments or coaching.
• Developers split across teams — Scrum assumes a stable team; splitting causes context-switching cost.

The events (“ceremonies”)

Plus Backlog Refinement (continuous, not a formal event) — the team grooms upcoming backlog items.

The artifacts

The 2020 Scrum Guide added “commitments” — each artifact has a commitment that anchors it. Product Goal is what we’re building toward. Sprint Goal is the cohesive objective for this sprint. DoD is what “done” means.

Definition of Done — the quality bar

Examples of DoD criteria:

• Code reviewed and merged.
• Unit tests written and passing.
• Integration tests passing in CI.
• Documentation updated.
• Deployed to staging.
• Acceptance criteria met.

DoD is team-defined; it’s not in the Scrum Guide. The point: every increment meets the same quality bar. “Done” doesn’t mean “developer thinks it works.”

For mature teams, “Done” includes “deployed to production.” For teams without CD, staging is acceptable.

Sprint Planning — the typical structure

Two halves:

Half 1 (PO-led): what?

• Review the Product Goal.
• Discuss top backlog items.
• Define the Sprint Goal.
• Forecast which items fit.

Half 2 (Developer-led): how?

• Decompose items into tasks.
• Estimate / re-estimate.
• Commit to the Sprint Backlog.

The Sprint Goal is a key concept: a single cohesive objective. “Improve checkout conversion” is a Sprint Goal. “Finish stories 42, 43, 44, 45” is a wish list. Goals provide focus when priorities shift mid-sprint.

Daily Scrum (standup)

The 15-minute daily sync. The Scrum Guide is loose about format — the team picks what works. Common formats:

The classic three questions can devolve into status reports to the SM/PO. The Sprint Goal focus is closer to the intent: are we on track to deliver?

Antipatterns:

• 30-minute standups (it’s a 15-minute timebox).
• Daily Scrum as a status meeting for managers.
• Discussion of solutions in the standup (those go to follow-ups).
• Everyone reports separately instead of collaborating.

Sprint Review

A demo + conversation, not a presentation. Stakeholders see the increment, give feedback, possibly reorder the backlog. The PO uses this to adapt the Product Backlog.

It’s not a status report. It’s not a sign-off ceremony. It’s “look at what’s working, decide what’s next.”

Sprint Retrospective

Team-only (PO + SM + Developers; no stakeholders). What’s going well, what isn’t, what to change.

The output should be a small number of concrete actions, owned by people, with a timeline. “Communicate better” is a useless retro outcome. “Switch to threaded Slack convo for architecture decisions instead of meetings, owned by Alice, by next sprint” is useful.

Retros that produce no actions, repeat the same actions sprint after sprint, or are dominated by venting are signs of low team health.

Estimation

Scrum doesn’t mandate an estimation technique. Common:

Story points + velocity is the most common. They’re abstract effort + complexity + uncertainty estimates; velocity (points/sprint) becomes a planning input over multiple sprints. See 06_estimation_planning.md.

Antipatterns:

• Story points used as time (8 points = 8 days).
• Velocity used as a performance metric for individuals.
• “Inflation”: team feels pressure, points creep up, velocity looks higher.

Common Scrum antipatterns

“Mini-waterfall sprints”

Sprint planning is “the spec phase,” dev does code, last day is testing. Increment isn’t deliverable until end. Real Scrum: each item is done-as-you-go.

Sprint planning becomes contract negotiation

PO insists on N items; team feels pressured to commit; sprint goal is “ship these N.” Real Scrum: team determines capacity; PO orders the backlog; commitment is the Sprint Goal, not a list.

No actual increment

Sprint ends with code committed but not deployable. “Definition of Done” was watered down. Real Scrum: increment is potentially shippable every sprint.

SM = secretary

SM books meetings, updates Jira, fetches coffee. Real SM: removes impediments, coaches the team, protects from interruptions, improves the process.

Daily Scrum becomes interrogation

Manager attends, asks for justification. Real Daily Scrum: developers coordinate among themselves. No one’s reporting to anyone.

Velocity used to compare teams

Team A does 30 points; Team B does 20. Conclusion: A is better. Wrong: points are team-relative abstractions. Comparing across teams compares incompatible scales.

Mid-sprint scope changes from “above”

PO can re-order the backlog after the sprint. During a sprint, the Sprint Goal is locked. Constant scope changes mid-sprint mean Sprint Planning doesn’t function.

Scrum is not always right

Scrum works best when:

• Requirements evolve (you can’t fully specify upfront).
• Stakeholders can commit time to reviews.
• Team is stable.
• Work fits in 2-week iterations.

Scrum struggles when:

• Continuous-flow work (support tickets, ops) — Kanban fits better.
• Hard external deadlines (regulatory, contractual) — needs different planning.
• Team is fragmented across many concurrent products.
• Stakeholders aren’t available.

For continuous-flow / unpredictable arrival rates: see 03_kanban.md.

Scaling Scrum

Scrum is designed for one team (5–9 people). For larger orgs, frameworks attempt to scale:

Pragmatic teams skip the frameworks and use loose coordination + alignment via Product Goals. Big enterprises adopt SAFe because it has training, certifications, and a vendor ecosystem; opinions on its actual value vary.

Interview angle

• “Walk me through Scrum.” — three roles (PO/SM/Devs), five events (Sprint, Planning, Daily, Review, Retro), three artifacts (Product Backlog, Sprint Backlog, Increment), commitments (Product Goal, Sprint Goal, Definition of Done). Sprints typically 2 weeks.
• “What does the Scrum Master do?” — facilitates the events, removes impediments, coaches the team and org on Scrum, protects from interruptions. Not a project manager or task-assigner.
• “PO vs SM?” — PO owns what (the product, the backlog, prioritization, value). SM owns how (process effectiveness, removing impediments). Different responsibilities; team needs both.
• “What’s the Definition of Done?” — team-defined criteria for “complete” — code reviewed, tests passing, deployed to staging, docs updated, etc. Every increment meets the same DoD.
• “What’s velocity?” — average story points completed per sprint. Used for forecasting (how many sprints to finish a release). Bad use: comparing teams, judging individuals, treating as productivity metric.
• “Common Scrum antipatterns?” — mini-waterfall sprints, mid-sprint scope changes, watered-down DoD, SM as secretary, velocity as performance metric, ceremonies without outcomes.
• “Have you used Scrum? Tell me about it.” — pick a real example, name the specific cadence and what worked / didn’t. Avoid recitation; talk about the team dynamics.