Watch the Work, Not the Workers
Four flow metrics that tell you more about your studio than any timesheet ever will
Why tracking work beats tracking workers in a surveillance-heavy industry
Cycle Time, Work Item Age, WIP and Throughput explained for producers
Real examples from mobile and live ops teams
Updated for 2026 with current data on workplace monitoring
Author’s note: I’ve added to each section a short blurb about how I’ve used these tools in the wild. Only the names have been changed to protect the innocent, and my confidentiality obligations. Also updated data since the original publication.
In Gil Broza’s book Deliver Better Results, I came across a short chapter titled “Watch the work, not the workers.” For a system to do its job, it has to move work forward and balance two things at once: looking after the workforce and looking at the work itself. Most companies still spend the bulk of their attention on the first half. Timesheets, individual productivity metrics, activity dashboards, screen recorders. The second half, the actual journey of each piece of work through the studio, gets a fraction of the attention.
That phrase lodged in my head. It kept rising back up every time I read another story about return-to-office mandates and bossware.
The data on this is now genuinely ugly. 74% of US employers use online tracking tools, with 59% running real-time screen tracking and 62% logging web browsing. 61% of US companies now use AI-powered analytics to measure productivity or behaviour. Toggl’s 2025 Productivity Index found that 76% of C-suite leaders believe they should have access to detailed activity tracking and screen monitoring at any time. The same leaders, in the same survey, admitted 75% of them knew excessive monitoring hurts retention and morale. They’re doing it anyway.
The irony is that the surveillance tools are being deployed by the same people who know the surveillance tools don’t work.
The US Government Accountability Office reviewed 122 studies on digital surveillance and found it can increase workers’ risk of injury by pushing them to move faster to hit productivity targets. Meanwhile a WorkLife investigation into the productivity paradox found that 86% of workers now believe employers should be legally required to disclose their monitoring tools, and that surveillance has spawned a whole cottage industry of “task masking” where employees optimise for the appearance of work rather than the work itself.
This is what happens when you watch the workers. You get theatre.
The response from game studios to all of this has been predictable. Agile got weaponised. Velocity and story points stopped being diagnostic tools and became sticks. Product leaders push developers for more output while leaving their own upstream processes in a mess. The whole edifice runs on the assumption that if you can just squeeze the individual contributors a bit harder, the system will deliver. It won’t. The bottleneck is almost never the people doing the work.
Kanban Flow offers a different posture. You visualise the work, you see where it’s stuck, you balance demand against capacity, and you fix the system instead of haranguing the humans inside it. I wrote about the switch from Scrum to Kanban in Evolve From Scrum to Kanban Flow if you want the background.
The rest of this post is about four specific flow metrics I rely on, all visible through the ActionableAgile Jira plugin or any decent Kanban tool. Cycle Time, Work Item Age, Work in Progress, and Throughput. Four charts that will tell you more about your studio than a month of standups.
Cycle Time Scatterplot
A Cycle Time Scatterplot plots every finished work item against the date it was completed, with the vertical axis showing how long that item took from start to finish. Each dot is one ticket. The cloud of dots tells you the shape of your process.
A tight cluster means predictable delivery. A wide scatter means your process is behaving like a fruit machine. Outliers at the top of the chart are the stories that ate someone’s week. Most tools will overlay percentile lines at 50%, 70%, 85% and 95%, which is where the real value lives.
I use the 85th percentile line for right-sizing. If the line sits at twelve days, then I know that historically, 85% of our tickets complete in twelve days or less. That’s a fact, not an opinion. When someone asks how long a new ticket of similar shape will take, I have a real answer backed by the last three months of actual team data.
This matters because the alternative is estimation meetings. Story points, planning poker, three engineers arguing about whether something is a 5 or an 8. All of that is replaced by one number pulled from the data. Right-sizing means breaking work down until it fits comfortably under the 85th percentile. If a ticket can’t be broken down that small, it’s not a ticket, it’s a project, and it needs its own plan.
Actual team data always beats guesswork. The scatterplot shows you how long work takes. Debating how long it should take is a waste of everyone’s afternoon.
The 85th percentile also builds in a natural buffer. It absorbs the normal variation that every knowledge work process carries without having to inflate estimates with fudge factors. Delivery stays predictable. Stakeholders stop being surprised. The team doesn’t get saddled with dates nobody believed in the first place.
Ageing Work-In-Progress Report
Where the scatterplot looks backwards at completed work, the Ageing WIP report looks at everything currently in flight. It shows every open ticket, grouped by workflow column, with the vertical position of each dot indicating how many days it has been open.
The report’s real job is to surface work that’s drifting past the age you’d expect based on your historical cycle times. A ticket that’s been in “In Progress” for eighteen days when your 85th percentile is twelve days is a ticket in trouble. Something is blocking it. Something is unclear. Somebody is sitting on it waiting for an approval that never comes. You want to know before it becomes a launch blocker, not after.
When I join a new team, the Ageing WIP chart tells me almost everything I need to know in five minutes. Lots of ageing tickets usually means one of three things. Either the team is overcommitting and pulling new work before finishing old work, or priorities are unclear and everyone is hedging their bets, or the workflow has handoff gaps that cause tickets to stall between columns. Each of these has a different fix. The chart points you at the right one.
I run this report in every standup. Not the full Jira board. Just the Ageing WIP view. It changes the conversation. Instead of “what did you work on yesterday” you get “why is this ticket seventeen days old” which is a much more useful question. Patterns emerge fast. A recurring blocker. A column that everything stalls in. A senior engineer who’s accidentally become the single point of failure for code review. You see it, you fix it, you move on.
The 10th Anniversary Edition of Daniel Vacanti’s Actionable Agile Metrics for Predictability actually makes the case that Work Item Age is the single most important flow metric. He’s right. It’s the only one that gives you the chance to intervene while the work is still in motion. Everything else is a post-mortem.
Work-in-Progress Run Chart
The WIP Run Chart plots the total amount of work in progress over time. Days on the horizontal axis, ticket count on the vertical. A single line that goes up when WIP rises and down when it falls.
If the line is a jagged sawtooth, something is wrong. If it climbs and never comes down, you’re accumulating work faster than you’re finishing it, and you have a debt that will come due. If it spikes at regular intervals, those spikes are correlated with something in your calendar, and that something is probably a bottleneck you hadn’t noticed.
A mobile team I worked with had wildly inconsistent delivery. Some sprints felt overloaded, others were oddly quiet. The WIP Run Chart showed me a sawtooth pattern with spikes landing just before every milestone review and sharp drops right after. Work was piling up waiting for stakeholder approval, then flooding through the system once approval came in. The team wasn’t the problem. The approval process was the problem.
We changed the review cadence. Approvals happened more often, in smaller batches, spread across the month. The sawtooth smoothed out over about six weeks. Delivery became steadier, crunches disappeared, and the team started trusting their own forecast dates again. The WIP Run Chart was how we knew the fix was working. Without it we’d have been guessing.
Work in progress is debt. You can’t see the interest payments on a Jira board, but you can see them on a run chart.
The chart also correlates beautifully with team composition changes, tool rollouts, and external events. When a new hire joins, you’ll see it. When leadership reorganises a team, you’ll see it. When a dependency from another studio slips, you’ll see it. It’s the closest thing production has to a heart rate monitor.
Throughput Run Chart
Throughput counts how many items the team completes in each time bucket. Days, weeks, sprints, whatever cadence matches your process. It’s the rawest measure of output a team has, and in combination with Cycle Time it’s what you use to forecast future delivery.
A healthy Throughput chart isn’t flat. Knowledge work is lumpy by nature, and anyone who expects a perfectly flat line is selling something. What you want is a stable average with variation that falls within a sensible range. What you don’t want is throughput that trends steadily downward, or throughput that craters every time the team picks up a big piece of work.
I ran this chart on a live ops team for a mobile game that was struggling with unpredictable update cycles. Some weeks they shipped multiple fixes and content drops. Other weeks, nothing went out. The chart showed two patterns immediately. Throughput dipped hard whenever the team pulled in a large, poorly broken-down task, and surged after dedicated bug-fixing sprints because the fixed bugs had been clogging the backlog and blocking other work.
We tightened the backlog refinement process to make sure tasks were sized more evenly. We also started reserving a slice of each sprint for bugs, rather than letting them accumulate until a triage day was unavoidable. Over about two months the chart flattened into something predictable. Delivery became something you could actually plan around.
Throughput pairs with Cycle Time for Monte Carlo forecasting, which is worth a post of its own. The short version is that if you have a clean historical throughput record and a clean cycle time distribution, you can forecast completion dates with statistical confidence intervals instead of hopeful guesses. It’s the most useful thing I’ve learned from flow metrics, and it’s the reason Vacanti’s book is the recommended reading at the end.
What this changes
The point of all four of these charts is that they watch the work. They tell you where it’s stuck, how old it is, how much of it you’re holding, and how fast you’re finishing it. None of them tell you anything about who was at their desk at nine in the morning or whether Sarah’s mouse moved enough this afternoon.
That’s the trade. You give up the illusion of control you get from surveillance, and in exchange you get a system you can actually diagnose. The illusion is comforting but useless. The diagnosis is uncomfortable at first, because it usually points at something the producer or the process owner is responsible for, and then it becomes the most valuable thing in your toolkit.
Game producers are already wired for this. We spend our careers tracking dependencies, predicting delivery, and arguing for realistic scope. Flow metrics are the quantitative version of what experienced producers already do in their heads. They also happen to be the fastest way to convince an exec that the problem isn’t the developers.
Daniel Vacanti’s Actionable Agile Metrics for Predictability: 10th Anniversary Edition is the book to read if you want the underlying theory, and ActionableAgile still offers a free demo of the Jira plugin that produced every chart in this post. Go look at your data. It’s trying to tell you something.