Process · 13 November 2026 · 4 min read

Scrum Measures the Wrong Thing

For a long time I thought our problem with Scrum was that we weren't doing it properly. Maybe the estimates were off. Maybe the tickets were too big. Maybe planning needed more discipline.

After years of running both Scrum and Kanban on software and game projects, I've landed somewhere else. The rituals aren't the problem. What the sprint is asked to measure is.

The sprint promise breaks on contact with reality

On paper it's tidy: define a sprint, agree on the tickets, execute, ship an increment. Then real work happens. Priorities shift. A dependency slips. Someone gets sick. A "simple change" hides three unknowns and turns into a week of cleanup.

So teams quietly bend the process. Tickets get added, removed, re-estimated, split mid-sprint. The burndown is maintained just enough not to look broken. At that point, what is the sprint actually measuring? Not the work. It's measuring how well we keep up the appearance of a plan.

Rhythm is good. False promises aren't.

I'm not against cycles. Teams need a cadence, stakeholders need checkpoints, and everyone needs regular moments to line up. The problem is treating the sprint's ticket list as a promise when everyone in the room knows it's fragile.

A sprint should be a coordination window. The question at the end shouldn't be "did we preserve the list we started with?" It should be "did we deliver a meaningful amount of valuable work?"

The work that disappears

Sprint reporting mostly measures loyalty to the original scope: planned tickets closed, burndown shape, carry-over. What it barely sees is everything that makes the feature work possible:

• reviewing code,
• pairing with someone who's stuck,
• improving logging or paying down tech debt,
• turning a vague request into actionable tasks,
• splitting one huge ticket into three shippable ones.

All of that is work. A process becomes dishonest the moment useful work stops being visible in it. And most tools make it worse: a ticket has one assignee, so the reviewer, the pair and the person who unblocked it all vanish. Reward only the visible work and you get exactly what you'd expect: inconsistent reviews, little mentoring, and shared ownership that's only shared on paper.

Commit to work, not tickets

So here's the model I keep coming back to. Keep the sprint, but stop letting the original ticket list define success. The team commits to completing a weighted amount of work. It's still tracked as cards, but the sprint measures contribution, not faithfulness to an outdated plan.

That makes the metric survive reality:

• Something urgent comes in? The sprint still makes sense.
• A planned card gets blocked? Work finished elsewhere still counts.
• A big card is split into three? That's an improvement, not accounting damage.

Weighted doesn't mean pretending estimates are precise. Some tasks are bigger, more urgent, or support rather than ownership, and the system should reflect that roughly, without turning into estimate theatre.

Sprint HP

In my head this has always been a health bar. The sprint has a target value; every completed piece of work knocks some off; when it hits zero, the sprint is won. That's literally how it works in FrostFire: every sprint has a boss, and finishing cards deals damage.

The metaphor is the fun part, but it's not the point. The point is that the team is measured against completed work instead of the survival of a ticket list, which gives a far more honest picture of what actually happened.

Why gamification, and what to avoid

I know how this sounds. I'm not interested in tricking engineers into working, and definitely not in surveillance dressed up as fun. What I want is for progress to be visible, for collaborative work to count, and for anyone to read the state of a sprint at a glance. Most workflow tools are functional but emotionally dead: they track tasks without showing momentum.

A light game layer helps with that: a visible sprint target, damage for completed work, the biggest reward for finishing the sprint together, credit for reviews and support, and a curated deck of ready-to-pull work, so nobody burns half an hour deciding what to pick up next.

It needs guardrails, though. Every metric can be gamed; the aim is to make honest contribution more rewarding than gaming it. So avoid:

• rewarding raw ticket counts,
• making big tickets automatically worth more than well-split work,
• leaderboards that punish quiet, essential contributors,
• rewarding people just for showing up. (Confession: FrostFire still does a little of this. It's on my list.)

Team completion has to matter more than personal point farming. Otherwise you've just rebuilt the same dysfunction with nicer visuals.

A better sprint, in seven lines

1. Pick the sprint length for coordination needs, not ideology.
2. Treat the sprint as a planning and review cadence, not a rigid promise.
3. Commit to a target amount of weighted work, not a frozen ticket list.
4. Let scope change without breaking the measurement.
5. Make support, review, maintenance and enabling work visible, and let it count.
6. Keep a curated deck of ready work to pull from.
7. Make the system reflect what actually moved the project forward.

So, did I fix Scrum?

No. But I do think it often measures the wrong thing. The real question isn't whether the sprint stayed faithful to its starting list; it's whether the team made meaningful progress despite shifting priorities, uncertain implementation and all the collaborative work in between.

If a process can't show that honestly, it isn't helping the team. It's forcing reality to fit the report, and that's the point where agile stops being agile and starts being theatre.