Scrum

Software used to be specified first and built second. A team spent months finishing a requirements document, got it approved, built against it for half a year, and shipped once at the end. As long as the market held still while the document was being written, the order made sense.

It didn't hold still. What arrived six months later kept missing the situation it was meant for, and the mismatch always surfaced last, because there was no checkpoint in between. On demo day someone says "this isn't what we pictured," and by then there's no time and no budget left to change it.

So the weight shifted toward not fixing the plan up front: build a slice, show it, correct course. That idea only settles the attitude, though. A team can sit in a room, agree to work that way, and still have no idea what changes on Monday morning. How short is short, when do you hold the meeting where direction gets corrected, who decides what comes first — all of it is blank. And blanks get filled by old habits. Meetings happen when someone calls one, priority goes to whoever is loudest that week, and the plan quietly hardens again into something nobody revisits until it's late.

Scrum fills those blanks with named parts. How many days the cycle runs, which meetings bracket it, who sits in each one and what they decide there — it's all specified. Having that much specified gets held against the framework, but for a team starting out it's the appeal: you can follow it before you understand it well enough to design your own.

The terms under Scrum fall into five branches: when things happen (events), what's left behind (artifacts), who builds it (roles), how you tell whether the cycle is holding (metrics), and where it comes apart (risks). Walking the branches in order is also a walk through one full cycle.

Events are the meetings held at fixed points. There are five, and the first one is the container for the rest.

1. Sprint — a fixed-length cycle, somewhere between one and four weeks. Once chosen, the length stays put, because a cycle that changes length every time makes the last cycle's record useless for the next plan. Two weeks is the most common choice: long enough to finish something worth showing, short enough that a wrong call costs ten working days rather than a quarter.
2. Sprint planning — held on day one to choose what the cycle will contain. Items come off the top of the prioritized list and stop at what the team can absorb. A two-week cycle usually spends two to four hours here, most of it spent turning vague items into work small enough that someone can say what "finished" would look like.
3. Daily scrum — fifteen minutes at the same time every day to share progress and blockers. It isn't a status report to a manager; it's the team lining up the day. When a blocker comes up, it doesn't get solved in the room — the team just decides who will look at it afterward.
4. Sprint review — on the last day, the team runs what it built in front of stakeholders and collects reactions. The rule is that you show working software, not a document or a screenshot, and what comes out of the room feeds the next cycle's list.
5. Retrospective — held right after the review, about the way the work was done rather than the work itself. The team surfaces what went well and what snagged, then picks one or two things to change next cycle. It's the first thing dropped when a week gets busy, and dropping it is how the same problem repeats every cycle.

Artifacts are what the cycle leaves in your hands. There are two. The sprint backlog is the bundle of work chosen during planning. Nothing gets inserted into it from outside once the cycle starts, and that rule is what buys the team two weeks of focus. The increment is what got added in a usable state by the time the cycle ends. A half-built feature doesn't count. Something usable has to exist at every cycle boundary so that stopping at any point still leaves something worth having. What counts as usable is written down in advance — typically reviewed, tested, and running in production. Teams can draw that line differently from each other, but when people inside one team draw it differently, every cycle ends in an argument about what actually finished.

Roles cover who owns what. The development team is everyone who builds the increment. It isn't a headcount of programmers; designers and testers are inside it, and nobody is fenced into a single job. Five to nine people is the usual recommendation. Fewer and the necessary skills aren't in the room; more and a fifteen-minute daily scrum can't give everyone a turn. Two more positions traditionally belong here — the person deciding what gets built first, and the person tending the process — but neither is exclusive to Scrum, so this map keeps them elsewhere. At a ten-person company one or two people usually hold all of these at once.

Metrics tell you whether the cycle is holding. There are three. Velocity is the average amount of work finished per cycle, used to judge how much to take on next. A burndown chart plots remaining work day by day, so a cycle losing pace mid-sprint shows up while there's still time to react. A burnup chart plots finished work alongside the total scope, which is the one you need when a date slips and you have to tell whether the team slowed down or the scope grew.

Risks collect the places where this comes apart. Spillover is work that didn't finish and carried into the next cycle. One or two items is ordinary; the same thing every cycle is a signal. It means the team takes on more than its record supports, or people disagree on what "done" means, or outside work keeps landing mid-cycle. All three are material for the retrospective. A carried-over item also distorts the numbers around it, since the points for it land in the cycle where it finishes rather than the cycle where most of the work happened — one cycle reads low and the next reads high, and neither reflects the pace.

The five branches close a loop. Planning produces the sprint backlog, the daily scrum keeps the days aligned, the review puts the increment in front of people, the retrospective adjusts the method, and that adjustment lands in the next planning session. Metrics show whether the loop turns at a steady rate, and spillover marks where it slips. Looked at one at a time the five meetings just look like a lot of meetings; they're joints in one loop, and pulling one out leaves the next joint without its input.

"That can't go into this sprint. Let's weigh it against everything else at the next planning session."

Invoking the rule that scope doesn't change mid-cycle, and pushing the request to the next one.

"Same blocker three days running in the daily. Let's keep the relevant people after this and work it out."

A repeated blocker needs to be handled outside the meeting, since the daily is for surfacing it rather than solving it.

"Three items spilled over this time. We'll look at why in the retro."

More carryover than usual, so the cause should be looked for in how the team works rather than in how hard anyone tried.

The product team at Pagedeck runs two-week cycles starting on Tuesday. Tuesday rather than Monday, because weekend support tickets make Monday planning chaotic. The first two hours are planning: Mia walks the prioritized list, and Theo and Noa pick what fits in the cycle.

Last quarter this team spilled three or four items every single cycle. The retrospective turned up a cause that had nothing to do with how much they took on. They were putting items into planning while the designs were still unfinished. Noa handed over screens around the middle of the cycle, so engineering had half a cycle to finish, and anything that ran long simply carried over.

The team changed one rule: only items with finished designs go into planning. Noa now works a cycle ahead, and engineering only ever picks up work that's ready. Spillover dropped below one item the following cycle. What changed wasn't how fast anyone worked, but the standard for what counts as takeable. The retrospective earned its slot that quarter by catching something the numbers alone pointed the wrong way about: the team had been planning to cut the amount it committed to, which would have hidden the design gap instead of closing it.

The most common misreading comes from the word sprint, which sounds like a period of running flat out. It's borrowed from track, so the assumption is natural, and plenty of teams do pile overtime into the last few days, which cements the impression. What the rules fix is the length, not the pace. The cycle marks off two weeks and asks the team to take on only what fits, which is the reason velocity gets measured at all. A team reading it as a sprint in the athletic sense takes on more than it can absorb, covers the gap with three late nights, and then that inflated number becomes the baseline for the next cycle. Six months in, the people give out before the process does.

The second is believing that putting five meetings on the calendar means you're running Scrum. Meetings are the visible part and the easiest thing to point at as evidence of adoption. But the meetings are containers, and what changes the way work happens is what the team is allowed to decide inside them. Hold planning while the volume of work is dictated from outside and it becomes a room for taking dictation. Let a retrospective produce improvements that never once land in the next cycle and it becomes a place to collect complaints. Three months of that and the team concludes it gained meetings and nothing else. What was missing was never the meetings — it was the assumption that decisions made in them hold.