Work Item Age: The one metric to rule them all

If you only tracked one metric for your flow of work, this would be it.

Not cycle time.
Not throughput.
Not a beautifully colour-coded cumulative flow diagram.

Work Item Age.

And the reason is simple: Work Item Age tells you what is going wrong right now, not what went wrong last month. Fix your flow of work now and your delivery becomes more efficient, more effective and more predictable.


Most software delivery organisations are drowning in historical data and starving for present time insight. They measure averages, trends, and distributions, then act surprised when something that looked “fine” on a chart explodes into a late delivery, an escalation, or a missed commitment. Age is the metric that cuts through that nonsense.




What Work Item Age Actually Is (and Why People Get It Wrong)


Work Item Age is brutally simple:

How long has this item been in progress since it started?

• Not “how long does work usually take”.
• Not “how long did this take after it finished”.
• Not “how long has it existed in the backlog”.

It’s the elapsed time between start and now.

That’s it.


And yet, most teams either don’t track it at all or treat it as a curiosity instead of a management signal. Why? Because Age is uncomfortable. It exposes indecision, overload, dependency failures, and wishful thinking in a way that averages never do.

Cycle Time makes you feel informed.
Age makes you feel accountable.

The Fatal Blind Spot of Cycle Time

Cycle Time is a lagging indicator. You only know it once the work is done.

That makes it excellent for forecasting and improvement conversations, but useless for answering the most important delivery question:

“Is this item in trouble?”

Imagine a hospital that only reviewed patient outcomes after discharge. That’s how most organisations use Cycle Time. By the time you notice a problem, the damage is already done.

Work Item Age is the early warning system.

If something has been in progress for 18 days in a system where most work finishes in under 10, you don’t need a PhD in statistics to know you have a problem. You need to intervene.

Age is risk, not performance

One of the most common misconceptions amongst both managers and team members is treating Age as a productivity metric. It isn’t.

Age does not tell you whether someone is “working hard enough”.
Age tells you how much delivery risk you are accumulating.

Every extra day an item ages:
    •    Delays customer feedback
    •    Increases the chance requirements change
    •    Increases dependency risk
    •    Increases the probability of SLE breach

Long-running work isn’t heroic. It’s fragile.

If you care about predictability, Age should make you uneasy long before a deadline does.

Why WIP limits alone won’t save you
You’ll often hear: “We control WIP, so ageing isn’t a problem.”
That’s optimistic at best.

WIP limits restrict how many items you start. They say nothing about whether the items you’ve already started are actually moving. A system can be “within WIP” and still be rotting from the inside.

Age exposes when WIP control has become symbolic rather than functional.

If items are ageing:
    •    You’ve started work you weren’t ready to finish
    •    You’ve tolerated blockers too long
    •    You’ve allowed hidden queues to form
    •    Or the work is simply too big

Age doesn’t care which excuse you prefer. It just keeps counting.

Age is the (missing) link between flow metrics

One reason Work Item Age is so powerful is that it connects every other Kanban metric into something actionable.
    •    Cycle Time tells you what “normal” looks like
    •    SLEs tell you how much risk you’re willing to tolerate
    •    WIP tells you how much you’ve started
    •    Throughput tells you what finishes

But Age tells you which specific items are threatening all of the above.

Without Age, flow metrics stay abstract. With it, they become operational.

“But all work ages” (Yes, and that’s the point)

A common pushback is: “Everything has to age. Age alone doesn’t mean something is wrong.”

Correct. And irrelevant.

The question is not whether something is ageing, but whether it is ageing unnecessarily.

That distinction matters.

An item that is ageing because it is actively progressing through a well-understood workflow is fine. An item that is ageing because nobody quite knows what to do next is not. The metric doesn’t tell you the answer — it tells you where to look.

Age creates a forcing function for conversation.

How delivery leaders should actually use age

This is where most tooling and dashboards fall down. They show Age, but don’t integrate it into decision-making.

Here’s how Age should be used by delivery leads and managers:
    1.    Daily visibility
If you can’t see the age of in-progress items at a glance, you’re already too late.
    2.    Escalation by exception, not by deadline
Stop waiting for due dates. Escalate when Age crosses a meaningful threshold.
    3.    Trigger intervention, not blame
Pairing, swarming, de-scoping, dependency removal, or breaking the work down — not “working harder”.
    4.    Expose systemic issues
Patterns of ageing point to policy failures, not individual ones.

Age should make it obvious where leadership attention is needed, without leaders having to micromanage.

At this point I expect the question, “but our leaders don’t care about the cards on our board or how we deliver, how does age help us?” While there is more to unpack in this question, I’ll just focus on the age related part - Make age visible at the level they care. If you are delivering “New Payment System” but you’re only tracking and showing the work item age of the 20+ individual tasks then you’re missing a trick. Age needs to be visible at the level your boss cares!

The uncomfortable truth: age exposes bad decisions

Here’s why Age is so often ignored.

It shines a light on:
    •    Work started “just in case”
    •    Features prioritised without capacity
    •    Dependencies hand-waved away
    •    Oversized items pushed downstream
    •    Exceptions that quietly became the rule

Age doesn’t let these slide. It keeps counting while everyone else rationalises.

That’s why teams prefer historical metrics. They’re safer.

If you ignore age, you don’t really care about flow

This might sound harsh, but it’s accurate.

If your Kanban system:
    •    Tracks Cycle Time but not Age
    •    Celebrates throughput while items quietly rot
    •    Reviews charts but ignores ageing work

…then you’re not managing flow. You’re managing reports.

Kanban exists to optimise the delivery of customer value. Letting work age unnecessarily is the single biggest threat to that goal.

Everything else — WIP limits, boards, dashboards, forecasts — is in service of one thing:

Finish what you start, and don’t start what you can’t finish.

Work Item Age tells you whether you’re actually doing that.

In the next post, we’ll look at Service Level Expectations, and how Age turns an abstract forecast into a real-time risk signal instead of a broken promise.