Flow Metrics Are How Scrum Grows Up
Replacing estimation theatre with data that actually moves
Why flow metrics belong in Scrum, not just Kanban
The three core metrics (WIP, Throughput, Cycle Time) and how they change planning
How to use flow metrics in sprint planning, daily scrum, review, and retrospective
Why “estimation theatre” quietly wastes most of your planning time
Clinton Keith’s Agile Game Development with SCRUM, published in 2010, was the book that brought Agile and Scrum into game development properly. Keith adapted the practices to the weird realities of our industry and set the template most studios have worked from since. It was the right book at the right time.
A decade later, Daniel Vacanti and Will Seele picked up where that conversation had stalled. Their paper, Flow Metrics for Scrum Teams (free download, worth your evening), built on Vacanti’s earlier Actionable Agile Metrics for Predictability: An Introduction and made a simple argument: the metrics Kanban teams have been using for years work just as well inside Scrum, and they fix most of the things Scrum teams complain about. Completed work items instead of subjective estimates. Real throughput instead of velocity debates. Less time arguing about story points, more time looking at what the team actually delivered.
Flow metrics work in any process where tasks get started and finished, which is why they travel well across methodologies. Dropping them into Scrum extends what the team can see without breaking the ceremonies they already run.
The reason I care about this is practical. Flow metrics get teams asking the right questions earlier. They expose how your policies shape your data, which in turn shapes your strategy. They replace estimation with forecasting based on actual throughput and actual cycle time, so the conversation with stakeholders stops being “we think” and starts being “here is what the data says.”
Uncertainty is not reduced by better planning. It is reduced by doing the work and watching what happens.
My regular readers already know I bang this drum. That is because I have spent most of my career as a Scrum producer running into the same wall: estimates that drifted, data that was not actionable, and problems I only found out about in the post-mortem. Most of my teams used Jira as a bucket for tickets and ran a handful of out-of-the-box reports. It was not enough. We tweaked the Scrum flavour endlessly trying to squeeze more value out of it, and the results were mixed at best.
The turning point for me was finding the ActionableAgile Analytics Jira plugin (also sold as a SaaS product). It gave me the proactive controls I had been trying to hand-roll for years. With the right tool in front of me, flow metrics stopped being a theory I liked and became a thing I could actually run a studio on. It is one of the biggest shifts of my career. Every gap we had tried to paper over with ad-hoc Scrum modifications was a gap flow metrics already filled.
What flow metrics actually get you
The point of collecting this data is not the data. The point is the questions the data lets you ask at the right moment. When the team and stakeholders are looking at the same chart, the conversation gets shorter and the decisions get better.
Transparency is the first thing that changes. Instead of subjective performance assessments, which are always a bit of a political minefield, you have an objective view of how the team is actually performing. That is a healthier foundation for every conversation that follows.
Sprint planning is the second thing that changes. Flow metrics compress the amount of time you spend on speculative estimation, which for most teams is the longest and least productive part of the ceremony. The focus shifts from guessing how big something is to deciding what you actually want to achieve.
And you get to move away from story points. Story points measure active effort. Elapsed time, which is what cycle time actually tracks, includes every minute a work item sits on the board whether someone is touching it or not. That is a much more honest picture of how long things take, and it is the picture your publisher is already looking at from the outside.
Story points measure how hard someone is working. Cycle time measures how long the work is actually taking. These are different numbers, and the second one is the one that ships games.
The broader goal is to move the team away from what I have started calling estimation theatre. You know the ritual. People quote numbers they do not believe, in a meeting nobody enjoys, to produce a plan everyone privately expects to miss. Flow metrics cut the theatre and replace it with something you can actually defend in a steering committee.
The three metrics that matter
There are three flow metrics that do most of the work.
Work in Progress (WIP) is the number of items currently being worked on. Watching WIP stops queues from building up at any one stage of the workflow and keeps the flow balanced. If WIP climbs without throughput climbing with it, you have a bottleneck.
Throughput is the number of items finished in a given period, typically product backlog items per sprint. It gives you a historical baseline you can forecast against. Real throughput, not aspirational velocity.
Cycle Time is the total elapsed time from when work starts on an item to when it ships. Separating elapsed time (how long it was in the workflow) from touch time (how long someone was actively working on it) shows you where items are sitting idle, which is almost always where the real improvement opportunities are.
A few more metrics ride alongside these three and are worth knowing about.
Work Item Age measures how long an unfinished item has been in the system. It is the single most useful metric for spotting stuck work before the sprint ends, because a stale item in week two is a problem you can still act on.
Service Level Expectation (SLE) is a probability forecast built from historical cycle time data: “we complete items like this within X days, 85% of the time.” It gives you a clean rule for deciding whether a PBI is fit to pull into a sprint or needs more refinement.
Monte Carlo Simulations use random sampling against your historical throughput to forecast completion probabilities. I wrote about these in detail recently and will not rehash the full argument here, but they are the backbone of any serious forecasting conversation with stakeholders.
Right-sizing is the practice of breaking work items down until they can reasonably be finished inside a specific window. It improves flow and predictability because smaller, more uniform items produce tighter distributions.
You can read more about Flow Metrics here:
Flow metrics in Scrum ceremonies
Here is where the rubber meets the road. Every Scrum ceremony gets sharper with flow metrics, but in different ways.
In sprint planning, throughput is the first number I put on the screen. Historical throughput tells you roughly how many PBIs this team finishes in a sprint, and that is your starting point for scope. Monte Carlo runs against that history let you attach a probability to “can we finish these twelve items by the sprint end.” Work item age from previous sprints tells you which items need special handling this time, because anything that aged badly last sprint will age badly again unless something changes. Right-sizing conversations happen at this point too: can this PBI realistically land in eleven days or less, or does it need splitting? And SLE becomes your entry criterion — items that do not fit the SLE envelope get refined, not pulled.
The daily scrum is where flow metrics stop being a planning tool and start being an operational one. Work item age is the metric I watch hardest in the daily, because an item ageing past the norm is a problem you can still do something about today. WIP levels come next: if the board is getting heavy in one column, you swarm or split before it turns into a bottleneck. SLE triggers give you a clean rule for when to intervene on an item that is not moving, so you stop having the “is this stuck or is it fine” argument every morning. The ceremony stops being a status update and starts being a workflow adjustment.
The sprint review is where the data becomes a stakeholder conversation. Throughput and cycle time from the sprint give stakeholders a factual view of delivery rate, which makes release planning conversations much calmer. Monte Carlo simulations let you model risk against the next release and refine the plan with stakeholders in the room instead of going away and coming back a week later. And when someone asks “when will feature X be ready,” you have a probability to answer with instead of a date you half-believe.
The sprint retrospective is where you improve the flow itself. Look at WIP, cycle time, and throughput together and ask what the shape of the data is telling you. Outliers are usually more interesting than averages. Adjust WIP limits, try a different splitting policy, change how you handle external dependencies, and then check the metrics next retro to see if the change actually did anything. That feedback loop is the whole point.
What this buys you
Adopting flow metrics across Scrum moves the team from estimative to empirical. That sounds academic but the effect is concrete: planning gets shorter, stakeholder conversations get easier, and the team can see problems while there is still time to fix them instead of writing them up in a post-mortem. The improvements compound sprint over sprint because you are measuring the workflow itself, not just the output, and every adjustment you make shows up in the next cycle’s data.
That is what I wanted out of Scrum the whole time, and flow metrics were the thing that finally delivered it.