Before we get too far, I love velocity. Velocity is a core team metric that can help us in so many ways. However, velocity is easy to celebrate, easy to manipulate, and hard to trust when bad actors get hold of it.
Flow metrics are harder to fake, easier to explain, and far better at forecasting delivery. In the end, if our goal truly is business agility, this is the core metric for the team and the organization (even though they might not know it yet).
If your stakeholders have heard “we will hit the date” one too many times, you already know the problem. Predictability is not a motivational speech. Predictability is a system. Flow is how we see that system.
In this post, you’ll find a practical starter kit. You will learn the four flow signals that matter, a simple 2–4 week measurement plan, the five anti-patterns that create thrash, and a short “what to stop doing” list you can act on immediately.
Why flow metrics beat velocity for predictability
Velocity is a local, team-internal measure (or it should be). It changes with story slicing, estimation habits, and even morale. That does not make it “bad.” It makes it a poor foundation for external commitments.
Flow metrics, on the other hand, are grounded in what actually happened to work items as they moved through the system. They are less sensitive to gaming, and more sensitive to bottlenecks, handoffs, and overload. Those are the real causes of unpredictability anyway.
This emphasis on system health, fast feedback, and reliable delivery shows up repeatedly in DORA’s research. Strong performance is not just output; it is stability and learning in the system. DORA 2024 is worth reading from start to finish if you lead tech delivery.
DORA 2024 report: https://dora.dev/research/2024/dora-report/
Flow 101: The four metrics that matter
If you only track four flow signals, track these. Keep them visible, keep them simple, and keep them consistent.
1) WIP, Work in Progress
WIP is the number of items started but not finished. High WIP usually means context switching, longer queues, and more waiting. If you want faster delivery, the first lever is often fewer starts, not faster starts.
2) Throughput
Throughput is the number of items finished per week. Finished is the keyword. Throughput is the best “output reality check” because it reflects the system’s actual capacity to complete work, including the messy parts like reviews, approvals, testing, and deployment.
3) Cycle time
Cycle time is how long an item takes from “start” to “done.” This is what stakeholders feel. If cycle time is unstable, your forecasts will be unstable, even if velocity looks fine. So many other "things" go into and affect cycle time, it might just be "The Agile Metric". Some teams call it Lead Time.
4) Aging work
Aging work is the time current items have been in progress. It is a leading indicator. When aging work rises, risk rises. If you only look at finished work, you find out you were late after you are already late.
A 2–4 week measurement starter plan
You do not need a tool rollout or a metrics committee. You need a short plan, a consistent definition of “start” and “done,” and the discipline to keep it boring.
Week 0, Setup (60 minutes)
- Define start and done, one sentence each. Example: start is “pulled into active work,” done is “deployed and verified.”
- Pick a work item type you can count. Stories, tickets, work requests, it does not matter; consistency matters.
- Create an aging view, a simple list sorted by age in days for all in-progress items.
- Agree on a WIP policy, even if it is loose. Example: no more than 2 active items per person, or a team cap per workflow column.
Weeks 1–2, Measure (10 minutes per day, 15 minutes per week)
- Daily: update which items are in progress, note blockers, and check the top 3 oldest items.
- Weekly: record throughput (finished count), and capture cycle time for each finished item.
- Weekly: compute a simple cycle time summary, median, and 85th percentile are enough for starters.
Weeks 3–4, Improve (one experiment per week)
Choose one friction point per week. Run one small experiment. Examples:
- Reduce WIP by 20 percent, then watch cycle time and aging work.
- Create an explicit “ready” policy, and clarify acceptance before work starts.
- Protect focus time, reduce interrupts, and route urgent work through a single intake path.
- Swarm the oldest item, finish it before starting the next shiny thing.
Five anti-patterns that create thrash
- Starting everything, finishing nothing. High WIP feels productive (and usually optimized for a skill set or individual), but it stretches cycle time and increases risk.
- Hidden expedite lanes. “Just this once,” emergencies become the real process, and everything else becomes late.
- Approval chains that act like parking lots. Work waits, nobody owns the wait, and cycle time becomes a mystery.
- Batching work for big reviews. Large batches create large surprises, and surprises kill predictability.
- Using velocity as a performance metric. The moment velocity becomes a target, it stops being a useful signal and starts being a game.
What to stop doing
If you want less trash, you do not need a new framework. You need fewer self-inflicted wounds. Start here:
- Stop rewarding starting. Celebrate finishing and learning, not “we kicked off 12 things.”
- Stop committing to dates without system evidence. Use cycle time history and throughput trends, then commit with ranges.
- Stop hiding blockers. Make blocked items visible; aging work is a leadership signal, not a team embarrassment.
- Stop letting urgent work bypass the system. Create a single intake policy for true emergencies and protect everything else from chaos.
- Stop measuring people when you should be improving flow. Flow problems are usually policy problems, not effort problems.
A simple weekly cadence that rebuilds trust
If you want to rebuild stakeholder trust fast, run a weekly “flow readout” that takes 10 minutes:
Weekly Flow Readout (10 minutes) 1) What finished (throughput): ___ items 2) Current WIP: ___ items 3) Cycle time: median ___ days; 85th percentile ___ days 4) Aging work: top 3 oldest items, and what is blocking each 5) One decision we need from leaders this week: ___
The magic is not the math. The magic is consistency. You are teaching stakeholders to trust your process because it is observable.
Predictability without fantasy
Flow metrics are not a dashboard project. They are a leadership practice. When you manage WIP, watch aging work, and forecast from cycle time, you move from hope to evidence.
Start small. Measure for 2–4 weeks. Run one experiment per week. Most teams are surprised by what improves when they simply stop starting so much.
Predictability is possible, but it will not come from fantasy. It will come from flow.
Sources
DORA 2024 report: https://dora.dev/research/2024/dora-report/
Daniel Vacanti, Actionable Agile Metrics for Predictability (book overview): https://actionableagile.com/books/aamfp/