Velocity Is a Shadow; Throughput Is Reality
In the previous post, we argued that estimation is a smell—a signal that teams are compensating for unmanaged uncertainty. Velocity, as a direct descendant of estimation, inherits that smell.
Scrum reminds us that the purpose of a Sprint is to produce an *Increment of value*, not to consume a predetermined number of points. Velocity measures effort expended inside the team. Customers, however, experience outcomes: features delivered, bugs fixed, and capabilities unlocked. No customer has ever benefited from a higher velocity.
Why Velocity Persists
Velocity survives because it is visible, numeric, and easy to chart. It gives leaders something to point at and teams something to optimize. Unfortunately, that optimization rarely aligns with value delivery.
When a measure becomes a target, it ceases to be a good measure. When velocity becomes important, teams respond predictably. Estimates inflate. Stories are sliced to satisfy point targets rather than user needs. Lower-risk, lower-value work gets pulled forward because it fits neatly into a sprint. The metric begins shaping behavior—and not in a way that improves outcomes.
Throughput Reframes the Conversation
Throughput shifts the question from "How busy were we?" to "What did we actually finish?"
Instead of abstract units of effort, throughput counts completed work items over time. It anchors delivery conversations in reality: features shipped, defects resolved, and capabilities made available to users. This reframing matters because it reconnects measurement to outcomes rather than internal activity.
At the organizational level, this distinction becomes even more important. Strategy is not executed in story points—it is realized through delivered features.
Applying Throughput at the Right Level
In many enterprise environments, meaningful commitments are made at the Epic level, often on a quarterly cadence. That makes Epics a far more useful unit of throughput than sprint-level stories.
Tracking completed Epics per quarter aligns measurement with how the organization actually plans, funds, and communicates progress. It also exposes reality quickly: when Epics linger quarter after quarter, the issue is no longer estimation accuracy—it is flow.
This does not eliminate the need for stories or tasks. It simply recognizes that stories are implementation details, while Epics represent customer-visible outcomes.
Making Throughput Visible (Without Turning It Into Another Ritual)
A throughput-first approach does not require elaborate tooling, but it does require discipline.
Work should be clearly linked so that delivery rolls up meaningfully from stories to Epics. Flow metrics such as lead time and cycle time should describe how long work actually takes, not how long it was supposed to take. Work-in-progress must be constrained so that finishing becomes more important than starting.
Tools like Jira can support this view—but they should remain servants, not masters. The goal is not better dashboards. The goal is faster feedback and fewer surprises.
The Bottom Line
When teams optimize for velocity, they optimize for internal efficiency theater. When they optimize for throughput, they are forced to confront reality: how work flows, where it stalls, and what actually reaches users.
Reality > rituals holds here as well. Stop asking how many points were burned. Start asking which features landed—and how reliably they do so.
Agile Engineering: Rhetoric vs Reality series
- Part 1: Agile isn't broken — We just stopped practicing Engineering
- Part 2: Estimation is a Smell
- Part 3: Velocity Is a Shadow; Throughput Is Reality
- Part 4: [Upcoming]
Want to Learn More?
Daniel Vacanti's *Actionable Agile Metrics for Predictability*
The best practical guide for using throughput, cycle time, and lead time to forecast delivery without estimation.
**David J. Anderson's *Kanban***
The foundational framework for understanding flow-based metrics and why managing work-in-progress matters more than maximizing utilization.
**Martin Fowler's "Metrics Are Not Goals"**
A short essay on what happens when we confuse measurement with purpose.
Comments
Post a Comment