Agile workflow optimization means getting work from "started" to "done" faster and more predictably, mostly by starting less. The most reliable levers for a Scrum team are limiting work in progress (WIP), measuring cycle time and work item age, and fixing the one stage where work waits longest. Adding effort or tools rarely helps if the team already has too many things open.
This guide explains the four flow metrics worth tracking, shows the math with a worked example, and gives you a three-sprint plan to try it on your own board.
The four flow metrics
Scrum.org's Kanban Guide for Scrum Teams defines four flow metrics. They work alongside velocity, not instead of it.
| Metric | Definition | What it tells you |
|---|---|---|
| WIP | Number of items started but not finished | How much the team is juggling right now |
| Cycle time | Elapsed time from when an item starts to when it finishes | How long a typical item takes once you begin it |
| Work item age | Elapsed time since an in-progress item started | Which items are at risk today, before they become a late cycle time |
| Throughput | Number of items finished per unit of time | How much the team actually completes |
Two more terms you'll see:
- Lead time is from when the item was requested (or entered the backlog) to done. It's what a stakeholder experiences. Cycle time is the part the team controls.
- Flow efficiency is active work time divided by total cycle time. A story that took 10 days but had only 2 days of someone actually working on it has 20% flow efficiency. The other 8 days it was waiting: for review, for testing, for an answer.
Little's Law: why WIP limits work
Little's Law, from queueing theory, links these metrics for a reasonably stable system:
Average cycle time = Average WIP / Average throughput
If you keep throughput roughly the same and halve the number of items in progress, the average item finishes in roughly half the time. You don't have to work harder; you just stop starting things. That's the whole argument for WIP limits.
Caveats: it's about averages over time, it assumes work that starts mostly finishes (not abandoned), and it assumes the system is roughly stable. It's a guide for direction, not a precise prediction.
Worked example: a five-developer Scrum team
The numbers below are a hypothetical but typical starting point.
Step 1: snapshot the board
A team of five developers plus one tester, two-week sprints. On an average day mid-sprint, the board looks like this:
| Column | Items |
|---|---|
| In Progress | 9 |
| Code Review | 6 |
| Testing | 4 |
| Total WIP | 19 |
Throughput over the last four sprints: about 12 items per sprint, or 6 per week (1.2 per working day).
Little's Law estimate: 19 / 1.2 per day ≈ 16 working days average cycle time. That's longer than the sprint, which matches what the team feels: stories regularly carry over.
Step 2: look at the cycle time distribution
The last ten finished items took these many working days from start to done:
2, 3, 3, 4, 4, 5, 6, 8, 11, 19
| Statistic | Value | Why it matters |
|---|---|---|
| Mean | 6.5 days | Pulled up by the 19-day item |
| Median (50th percentile) | 4.5 days | Half of items finish within this |
| 85th percentile | about 11 days | Most items finish within this; a good basis for a service level expectation |
(Your real data will have more items; ten keeps the example readable. The 85th percentile here is the 9th of 10 sorted values.)
Don't report the mean alone. The median says a typical item takes under a week; the 85th percentile says "most items finish within about two working weeks." That's a forecast you can give a stakeholder: "Once we start something, 85% of the time it's done within 11 working days." (The Little's Law figure above is higher than these completed-item numbers because the items currently on the board include some that have been sitting for a long time and haven't finished yet. That gap is itself a warning sign.)
Step 3: find where items wait
The team tags the 19-day item and a few others and asks where the time went. For a typical 8-day story:
| Stage | Active work | Waiting | Total |
|---|---|---|---|
| In Progress | 2.5 days | 0.5 days | 3 days |
| Waiting for Review | 0 | 2.5 days | 2.5 days |
| Code Review | 0.5 days | 0 | 0.5 days |
| Waiting for Test | 0 | 1.5 days | 1.5 days |
| Testing | 0.5 days | 0 | 0.5 days |
| Total | 3.5 days | 4.5 days | 8 days |
Flow efficiency: 3.5 / 8 ≈ 44%. More useful than the percentage is where the waiting happens: 2.5 days waiting for review is the biggest single delay. With one tester, testing is also a queue.
Step 4: set WIP limits
The team agrees on these column limits:
| Column | Old average | WIP limit |
|---|---|---|
| In Progress | 9 | 4 |
| Code Review | 6 | 3 |
| Testing | 4 | 2 |
| Total | 19 | 9 |
The working agreement that makes it work: when a column is at its limit, you don't pull new work; you help clear the column downstream. A developer with nothing to start reviews a pull request or pairs with the tester.
If throughput holds at 1.2 items per day, Little's Law suggests average cycle time of about 9 / 1.2 ≈ 7.5 working days, roughly half of where they started. In practice, throughput often dips for a sprint while people adjust, then recovers.
Step 5: watch work item age daily
At the Daily Scrum, the team sorts in-progress items by age and asks one question about anything older than the median (4.5 days): "What would it take to finish this today?" Anything approaching the 85th percentile (11 days) gets swarmed. This is the habit that catches the 19-day item while it's still a 6-day item.
Common bottlenecks and what to try
| Symptom | Likely cause | First thing to try |
|---|---|---|
| Pull requests wait days for review | Review isn't anyone's priority; PRs are large | WIP limit on Review; "review before you start" agreement; smaller PRs |
| Work piles up before testing | One tester, testing at the end | Developers test each other's work; write acceptance tests during refinement |
| Many items "In Progress" per person | Context switching, interruptions | Personal WIP of 1-2; triage rota for interrupts |
| Items blocked waiting on other teams | Dependencies found late | Surface dependencies in refinement; agree a turnaround with the other team |
| Stories change mid-sprint | Unclear requirements | Readiness checklist before estimation (see the user story readiness checklist) |
| Cycle time spread is huge | Items vary wildly in size | Split large items; check estimates for anything above 8 points |
On the last point: very wide cycle times often come from stories that should have been split. If your planning poker sessions show wide vote spreads or low confidence on a story, treat that as a flow risk as well as an estimation one. A tool that records both votes and confidence, such as Alignlee's free planning poker, makes those stories easy to spot before they enter the sprint.
Flow and Scrum fit together
Some teams worry that WIP limits conflict with Scrum. They don't. The Sprint Goal and Sprint Backlog define what the team aims to finish; WIP limits govern how many of those items are open at once. A few practical links:
- Sprint Planning: use throughput as a sanity check alongside velocity. If you finish 12 items per sprint on average, a plan with 20 items needs a good reason.
- Daily Scrum: walk the board right to left (closest to done first) and look at work item age.
- Sprint Review: show the cycle time trend next to the Increment.
- Retrospective: review one flow chart and agree one experiment.
For velocity-based forecasting, the sprint velocity calculator and the team velocity guide cover how to turn several sprints of data into a range.
A three-sprint optimization plan
Sprint 1: measure. Don't change anything yet. Record start and finish dates for every item (most tools do this automatically when items move columns). At the end, calculate median and 85th percentile cycle time, average WIP, and throughput.
Sprint 2: limit WIP. Agree column limits a bit below your current averages and the "help downstream" rule. Add work item age to the Daily Scrum. Expect some discomfort; people will have moments with nothing to start. That's the point: those moments go into reviews and testing.
Sprint 3: target the biggest wait. Using your Sprint 1 and 2 data, pick the stage where items wait longest and run one experiment there (for example, a two-hour review turnaround agreement). Compare cycle times at the retro and decide: keep, adjust, or drop.
Write each change as a hypothesis: "If we limit Code Review to 3 items, median cycle time will drop below 5 days within two sprints." That gives the retrospective something concrete to check.
Mistakes that undo the gains
- Limits nobody respects. A WIP limit that's exceeded every day is decoration. Either lower the work coming in or raise the limit honestly, then enforce it.
- Optimizing a non-bottleneck. Theory of Constraints: speeding up coding does nothing if items then wait three days for review. Fix the slowest stage first.
- Turning metrics into targets. If cycle time becomes a performance goal, people split work artificially or close items early. Use flow metrics for the team's own improvement, not for comparing teams.
- Reporting averages only. The mean hides the long tail that actually hurts predictability. Use percentiles.
- Changing five things at once. You won't know what worked. One experiment per sprint or two.
- Ignoring meetings. If the team spends a large share of the week in meetings, that's capacity your flow math doesn't show. The meeting cost calculator makes that visible.
FAQ
What is agile workflow optimization?
It's improving how work moves through your team so items finish faster and more predictably. In practice it means visualizing the workflow, limiting work in progress, measuring cycle time and work item age, and fixing the stage where work waits longest, one experiment at a time.
How do I set WIP limits for a Scrum team?
Measure your average items per column for a sprint, then set limits a little below those averages. Pair the limits with a rule that when a column is full, people help finish work downstream instead of starting something new. Adjust after a sprint or two.
What is a good cycle time for a Scrum team?
There's no universal number; it depends on how you size items. A useful target is for your 85th percentile cycle time to sit comfortably within one sprint, so most items started early in a sprint finish within it. Watch the trend and the spread rather than comparing to other teams.
How is cycle time different from lead time?
Cycle time runs from when the team starts an item to when it's done. Lead time runs from when the item was requested or added to the backlog until it's done, so it includes time waiting in the backlog. Stakeholders feel lead time; the team directly controls cycle time.
Do flow metrics replace velocity in Scrum?
No. Velocity measures story points completed per sprint and works for sprint-level forecasting. Flow metrics show how work moves day to day and where it gets stuck. Using both gives you a forecast and a way to improve it.