Aging Work in Progress: Spotting At-Risk Work Before It Carries Over
Cycle time tells you how long finished work took. Aging WIP tells you how long unfinished work has been going — which makes it a leading indicator of next sprint's carryover.
Code review · Team A
29 issues — and 19 of them older than 5 days.
Code review · Team B
23 issues — nearly all fresh and moving.
How many issues sit in a stage says little; how long they have been there — against the team’s own history — says a lot.
How this is calculated: Count vs age in the methodology
What aging WIP is
Work item age is the time since an unfinished item started. Aging WIP is the set of in-progress items and their ages, typically grouped into buckets such as 0–2, 3–5, 6–10 and more than 10 days, and broken down by stage.
Age is different from time in the current stage. An item can be 12 days old but only one day into code review: the age says it is at risk overall, the stage time says where it is waiting now. Both are useful, and a good view shows both.
Cycle time is a lagging indicator — you only learn it once an item is finished. Work item age is a leading indicator: it tells you today which items are drifting, while there is still time to do something about them.
Why it matters
Work that has been in progress much longer than usual is unlikely to finish soon without attention. Surfacing it mid-sprint gives the team a chance to swarm, split or unblock it before it becomes carryover — which is far cheaper than explaining it afterwards.
How to calculate it
Age needs a start date. In order of accuracy:
| Source | Accuracy |
|---|---|
| Status change history — first move into an active status | Exact |
| Jira "Status Category Changed" for items currently In Progress | Good — the moment the item entered the In Progress category |
| Created date | Proxy only — includes backlog wait, overstates age |
Then compare each age with the team's own completed-work history, for example the 85th percentile of cycle time. An item older than P85 is older than 85% of everything the team has finished — a clear, non-arbitrary definition of "unusually old". Compare like with like: ages measured from creation should be compared with lead time, not cycle time.
How to interpret it
ABC-204 · one issue’s journey
The longest single segment is code review (4 days) — more than development itself.
Cycle time is the sum of waiting and working in each stage — the longest segment is where to look first.
- Old items in wait stages (review, ready for QA, ready for release) need a process nudge, not more effort.
- Old items in development are often too large or blocked in ways the status does not show.
- Many items in the 0–2 bucket late in a sprint means work is still being started — it will probably carry over.
- A growing count above the alert threshold over several sprints means WIP is rising; expect cycle time and carryover to follow.
Reading age mid-sprint
Compare each item's age with the team's typical cycle time and the days left in the sprint. An item already older than your median cycle time with three days to go needs a decision now: swarm on it, split it, or accept that it will carry over and tell stakeholders early. Surprises at sprint review are almost always visible in the aging view a few days before.
Apply this to your team’s delivery
Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.
Common mistakes
- Measuring age from creation without saying so. It can make a two-day-old piece of work look like a two-month-old one.
- Showing aging by assignee. It turns a flow signal into a performance review and people will stop updating statuses.
- Arbitrary thresholds. Use the team's own cycle-time percentiles as the reference.
- Only looking at it in the retro. Aging WIP is useful mid-sprint, when there is still time to act.
What engineering managers can do
- Review the oldest few items in stand-up: "what would it take to finish this today?"
- Swarm on old items before starting new ones.
- Split items that have outgrown the sprint.
- Introduce WIP limits per stage if the same wait stage keeps accumulating old work.
WIP limits work because of the relationship between work in progress, throughput and cycle time: with throughput roughly fixed, more items in progress means each one takes longer. A simple starting point is to cap in-progress items at about the number of people on the team, and to treat hitting the cap as a signal to help finish something rather than start something new.
Example
Mid-sprint, 13 items are in progress: 4 aged 0–2 days, 3 aged 3–5, and 6 aged 6–10 — two of which are older than the team's P85 cycle time measured from work start. Both are in code review. A reviewer picks them up that morning and they ship two days later instead of carrying over.
The same view also shows four items that entered development in the last two days of the sprint. With a median cycle time of six days, they almost certainly will not finish. The team flags them as expected carryover in the sprint review rather than presenting them as a surprise.
How this tool helps
See it on your own data in the Aging WIP report.
The aging WIP view buckets active work by age and stage, compares each item with your historical P85, states which start date was used, and deliberately omits assignees. It runs locally on your export.
Frequently asked questions
- How is aging WIP different from cycle time?
- Cycle time is measured for finished items. Work item age is measured for unfinished items, so it can warn you before an item becomes late.
- What age should count as "too old"?
- Use your own history: items older than the 85th percentile of completed cycle time are older than most of what your team finishes, which is a defensible threshold.
Related guides
Cycle time
What cycle time is, how it differs from lead time, how to calculate median and percentiles from Jira, why averages mislead, and why a CSV export alone cannot give you time per stage.
Sprint carryover
How to calculate sprint carryover from a Jira export, classify it by reason (review, QA, release, blocked), and tell the difference between observed and inferred causes.
Engineering bottlenecks
How to find delivery bottlenecks in an engineering workflow using queue size and time-in-stage, why arbitrary red/amber/green thresholds mislead, and what to do once you find the constraint.
Reduce carryover
A practical, evidence-first playbook for reducing sprint carryover: diagnose by stage, right-size commitments, limit WIP, and fix the constraint instead of pushing harder.