Field Notes · Elle Anderson · andersonco.uk

Scrum in a nutshell

First of three short pieces on ways of working: Scrum, then Kanban, then flow, the physics underneath both. Drawn from running these methods inside real organisations, where the slides meet the sprint board.

What it is, and what it is actually for

Scrum is a lightweight framework from the 1990s: a team works in fixed cycles called sprints, usually one to four weeks, with a small set of roles, events, and artefacts around them. A Product Owner decides what is most valuable next, the team decides how much of it fits and how, and every sprint ends with working product in front of people who can react to it. That is the whole machine.

Its real purpose is often forgotten. Scrum exists to force decisions and feedback onto a clock. Organisations left to their own devices will postpone both indefinitely; the sprint boundary makes postponement visible and slightly embarrassing. Everything else, the standups, the ceremonies, the planning poker, is scaffolding around that one idea.

The parts that carry the weight

A Product Owner with genuine authority to order the work and say no, because a PO who must escalate every trade-off is a ticket clerk with a fancier title. A sprint goal that describes an outcome, not a load list, so the team can trade scope intelligently when reality arrives mid-sprint. A review where real stakeholders meet working product, not a slide about product. And a retrospective that changes exactly one thing each cycle, because a retro that changes nothing is a support group, and one that changes five things is a wish list.

Where it curdles

The failure patterns are so consistent you can bingo-card them. Sprints treated as fixed-price delivery contracts, with carry-over quietly normalised. Velocity used as a productivity measure and then, inevitably, gamed. Standups performed as status reporting to a manager rather than replanning by a team. Ceremonies held with religious precision while nobody can state the sprint goal. When you see the rituals intact and the decisions absent, you are watching Scrum theatre, and the health check has a whole dimension for it.

What Scrum honestly does not do

Scrum says nothing about how work flows between teams, nothing about discovery and whether you are building the right thing at all, and very little about what happens to a piece of work before it reaches the backlog or after it leaves the sprint. It optimises the middle of the pipe. Teams that feel busy inside sprints yet slow end-to-end usually have a flow problem wearing a Scrum costume, which is exactly where Kanban and flow thinking pick up.