Velocity — the number of story points completed per sprint — is one of the most widely used and most widely misused metrics in Agile. This post explains exactly why velocity is insufficient and what flow metrics you should be tracking instead.
The Problem With Velocity
Velocity was designed as a team planning tool, not a performance metric. When organisations use velocity to compare teams, track progress against a fixed roadmap, or pressure teams to increase it quarter-over-quarter, they corrupt the metric and incentivise exactly the wrong behaviour.
Flow Metrics: A Better Model
| Metric | What it measures | Why it matters |
|---|---|---|
| Cycle Time | Time from work start to delivery | Predicts how quickly a new item will be done |
| Throughput | Items completed per time period | Actual delivery rate, size-independent |
| WIP (Work in Progress) | Items actively being worked | Early indicator of flow problems |
| Work Item Age | Time since work started (incomplete) | Flags stalled items before they become blockers |
| Cumulative Flow Diagram | Work across all states over time | Visualises bottlenecks and flow health |
Cycle Time: The Most Useful Single Metric
Cycle time measures how long it takes from when a team starts work on an item to when it is delivered. Unlike velocity, cycle time is size-independent and directly predicts future delivery dates. A team with a median cycle time of 4 days can reliably commit to "within a week" for any single item.
Improving cycle time requires reducing batch size (smaller stories), limiting WIP, and eliminating waiting time (handoffs, approvals, environment delays).
Throughput: The Honest Delivery Rate
Throughput counts the number of items (not points) completed per sprint or per week. It is harder to game than velocity — you either shipped the feature or you did not. Teams with consistent throughput are more predictable than teams with fluctuating velocity.
WIP Limits: The Intervention Tool
Limiting work in progress is the single most impactful change most Scrum teams can make. When teams work on 8 items simultaneously in a 5-person team, context switching destroys productivity. Setting a WIP limit of 1.5× team size forces prioritisation and dramatically reduces cycle time.
Cumulative Flow Diagram (CFD)
The CFD shows the volume of work in each state (To Do, In Progress, Review, Done) over time. Widening bands indicate accumulating WIP. Flat bands indicate blocked flow. A healthy CFD shows smooth, parallel bands moving upward over time.
DORA Metrics for Engineering Teams
For software delivery teams, the four DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Recovery) complement flow metrics by measuring delivery pipeline health. High-performing teams deploy multiple times daily with sub-hour lead times.
What This Means for CREA-SM
CREA-SM's metrics module covers both velocity (as a planning tool) and the full suite of flow metrics. The scenario-based exam specifically tests how to respond when velocity-obsessed stakeholders demand metric comparisons across teams — a real-world situation every enterprise SM faces.