Scrum: Metrics, Scaling & Anti-Patterns

Key Metrics

Velocity       — story points completed per sprint (average over 3-5 sprints)
                  Used for forecasting only, not performance measurement

Burndown Chart — remaining work (story points) vs time within a sprint
                  Steep drop = good; flat line = blocked

Burnup Chart   — completed work vs total scope; shows scope changes clearly

Lead Time      — time from item added to backlog → delivered to production
Cycle Time     — time from item started → delivered (subset of lead time)

Sprint Goal    — qualitative success indicator: was the sprint goal met?

Scrum at Scale

• Scrum of Scrums: multiple teams sync via a meta-Scrum meeting — one rep per team discusses cross-team dependencies

• SAFe (Scaled Agile Framework): enterprise scaling with Program Increments (PI) — quarterly planning cycles across many teams

• LeSS (Large-Scale Scrum): minimal overhead — one Product Owner, one Product Backlog, multiple teams in one Sprint

• Nexus: Scrum.org's scaling framework — adds Integration Team to manage cross-team dependencies and integration

• Spotify Model: not Scrum — squads, tribes, chapters, guilds — often misunderstood as a prescribed framework

Common Anti-Patterns

• Scrum Master as project manager: tracking hours, assigning tasks, reporting status — kills self-organization

• Sprint as mini-waterfall: design sprint, dev sprint, testing sprint — defeats continuous integration

• Zombie Scrum: going through motions (standups, retrospectives) without inspecting or adapting

• Backlog as a wish list: thousands of items, never refined, no prioritization — PO is overwhelmed

• Velocity as KPI: pressures teams to game story points; velocity only valid for forecasting within one team

• No Definition of Done: "done" means different things → technical debt accumulates sprint over sprint

• Skipping retrospectives: "no time to improve how we work" — the team never gets better

• PO absent during sprint: team makes assumptions → wrong product built, rework in next sprint

Scrum vs Kanban

              Scrum                    Kanban
Cadence       Fixed sprints (1-4 weeks)  Continuous flow
Roles         PO, SM, Dev Team           None prescribed
WIP limits    Sprint capacity            Explicit per-column limits
Change        Between sprints            Anytime (pull new work when capacity frees)
Metrics       Velocity, burndown         Lead time, cycle time, throughput
Best for      Product development        Support, ops, maintenance, unpredictable work

Scrumban: hybrid — use sprint cadence but Kanban-style WIP limits and flow

Interview Questions

• What's the difference between Sprint Review and Retrospective? Review = inspect the product (stakeholders attend); Retro = inspect the process (team only)

• Who can change the Sprint Backlog during a sprint? Only the Development Team — PO cannot add new work mid-sprint

• What happens if the team can't complete all Sprint Backlog items? Incomplete items return to Product Backlog; the sprint ends on schedule regardless

• How do you handle bugs found during a sprint? Minor: fix within sprint. Major: create backlog item, prioritize with PO for next sprint.

• What's the PO's role during Sprint Planning? Clarify stories and acceptance criteria — but the team decides HOW much to take on