Posts

Flow metrics for Scrum teams: cycle time, throughput, and what to actually measure

Your team tracks velocity. You talk about it in sprint planning, maybe reference it in retros. But when a stakeholder asks "when will this be done?" you still end up guessing. Velocity tells you how much you estimated you completed, not how long things actually take or where work gets stuck. Flow metrics fill that gap. They measure what's actually happening in your process using real data, not estimates. And you don't need to abandon Scrum or "go Kanban" to use them.

The four metrics that matter

The Kanban Guide for Scrum Teams (published by Scrum.org) defines four flow metrics. Here's what each one tells you and why it's worth tracking.

Work in progress (WIP)

The count of items your team has started but not finished. No formulas, just a number. WIP matters because of a simple truth: the more things you juggle, the longer everything takes. Context switching, handoffs, and waiting time all increase with higher WIP. Most teams are surprised when they first count their actual WIP.

Cycle time

The elapsed calendar time from when work starts to when it's done. Not effort hours, wall-clock time. Cycle time is a lagging indicator. You only know it after an item finishes. But collect enough data points (aim for 30+) and you can say things like "85% of our items finish in 10 days or less." That's a Service Level Expectation (SLE), and it's far more useful than a velocity-based guess.

Throughput

The number of items your team finishes per unit of time, typically per sprint or per week. Throughput is a count of completed items regardless of size. A 3-point story and an 8-point story each count as one. This sounds like a limitation, but it's actually a strength: it sidesteps all the debates about whether your points are "accurate" and measures what you actually delivered.

Work item age

The elapsed time since an in-progress item was started. Think of it as cycle time for things that aren't done yet. This is the one metric you should check daily. If an item's age is approaching your typical cycle time and it's still far from done, that's an early warning sign. Once the item finishes, its age becomes its cycle time. Until then, it's your best leading indicator.

How these metrics connect

Little's Law ties the first three together: Average WIP = Average Throughput × Average Cycle Time This matters in practice. If you reduce WIP without changing anything else, cycle time drops. Your team doesn't need to work faster. They need to work on fewer things at once.

If you want to...	Then...
Reduce cycle time	Lower your WIP
Increase throughput	Finish current work before starting new work
Predict delivery dates	Use cycle time percentiles (SLEs)
Spot problems early	Watch work item age daily

Getting started without overhauling your process

You don't need new tools or a process overhaul. Here's a practical path.

1. Track three dates per item

   For every product backlog item, record when it was created, when work started, and when it was done. Most tools like Jira and Azure DevOps already capture this. You just need to start paying attention to it.

2. Define your workflow explicitly

   Write down what "started" and "done" mean for your team. What are the columns on your board? What are the rules for moving items between them? This is your Definition of Workflow, and it's the foundation for consistent measurement.

3. Collect data for a few sprints

   Don't try to analyze anything yet. Just let the data accumulate. You need at least 30 completed items for meaningful patterns, which most teams hit in 3-4 sprints.

4. Create your first cycle time scatterplot

   Plot each completed item with its finish date on the x-axis and cycle time on the y-axis. Draw horizontal lines at the 50th, 85th, and 95th percentiles. Your 85th percentile is a solid starting point for an SLE.

5. Bring it into your Scrum events

   Use throughput history in sprint planning instead of (or alongside) velocity. Check work item age in daily scrums. Review cycle time trends in retrospectives. Present SLE performance in sprint reviews.

Where flow metrics fit in each Scrum event

These metrics become useful when you plug them into events you're already running. Sprint planning: Use your throughput history to forecast how many items you can realistically pull in. "We've completed 6-9 items per sprint over the last 8 sprints" is more grounded than debating story point totals. For more on running effective planning sessions, check out our sprint planning guide. Daily scrum: Shift from status updates to flow. "What's aging?" is a better question than "what did you do yesterday?" If an item is 7 days old and your 85th percentile cycle time is 10 days, the team should be swarming on it. Sprint review: Show stakeholders your cycle time trend and SLE performance. "We delivered 85% of items within 10 days this sprint, up from 72% last month" builds trust through transparency. Sprint retrospective: This is where flow metrics pay off most. A cumulative flow diagram shows bottlenecks that are invisible in a burndown chart, like work piling up in code review or a testing phase that starves when QA gets pulled into meetings.

Flow metrics vs. velocity: not a cage match

Velocity isn't broken, it's just limited. It works fine as an internal planning tool for sprint-level conversations. The problem starts when teams use it for delivery commitments, compare it across teams, or treat it as a performance metric. Flow metrics answer the questions velocity can't:

• "When will this be done?" Cycle time percentiles give probabilistic answers.
• "Why are things taking so long?" WIP and work item age show you where work is stuck.
• "Can we commit to this date?" Monte Carlo simulations using throughput history give you confidence levels.

The practical approach: use both. Keep velocity for sprint planning if it works for your team. Add flow metrics for delivery forecasting and process improvement.

Mistakes that trip teams up

Optimizing throughput at the cost of everything else. Pushing teams to close more items leads to cherry-picking small work, splitting stories artificially, or cutting corners on quality. Throughput is a diagnostic tool, not a target. Ignoring work item age until it's too late. Cycle time only tells you about finished work. If you're not watching age for in-progress items, you'll miss warning signs. Put it on your board or bring it up in daily scrum. Skipping the Definition of Workflow. Without a shared understanding of what "started" and "done" mean, your data is inconsistent and your metrics are unreliable. It doesn't need to be perfect, but it needs to exist. Measuring everything. You don't need 15 charts. The four flow metrics, a cycle time scatterplot, and maybe a cumulative flow diagram will cover 90% of what you need. Add complexity only when you have a specific question to answer.

What good looks like after a few months

Teams that stick with flow metrics for 3-6 months tend to notice a few things. Sprint planning gets faster because throughput gives a clear starting point for capacity. Retros produce more specific action items because you're looking at data instead of gut feelings. The biggest change is usually cultural. Teams stop thinking about starting work and start thinking about finishing it. The question shifts from "what should I pick up next?" to "what can I help get across the line?" That's the shift that actually moves the needle. Tools like Kollabe's planning poker help with the estimation side of sprint planning, but flow metrics give you the delivery predictability that estimation alone can't provide.