Why We Only Talk About Aging Work

For years, I facilitated daily standups that looked like most others:
round-robin updates, status reporting, and a lot of “still working on it.”

They were well intentioned—and mostly useless. Useless standups are one of things that gives Scrum a bad name.

Everything changed when we made one simple rule:

At the daily standup, we only talk about work items that have exceeded an aging threshold. Nothing else is discussed.

The result?

  • Standups consistently under 15 minutes

  • Fewer surprises late in the workflow

  • Better flow, with less effort

Here’s why that works.

Work Item Aging Is a Leading Indicator

Cycle time tells you how long work took after it’s finished.
That’s useful for analysis, but it’s too late to intervene.

Work item aging tells you how long work has been in progress right now.

That makes it a leading indicator.

When an item is aging beyond expectation, it’s signaling:

  • A hidden dependency

  • Unclear scope

  • Too much WIP

  • A blocked decision

  • Or simple overload

In other words, aging tells you where risk is accumulating while you can still act.

The Threshold Is the Control Mechanism

The real power is not the metric—it’s the threshold.

We agreed, as a team, on an aging threshold based on our historical flow.
Any work item above that line was considered at risk.

The standup rule was simple:

If an item is below the aging threshold, it’s assumed to be healthy and is not discussed.

No updates.
No explanations.
No commentary.

Only exceptions speak.

In the chart below, the dashed red line is the agreed aging threshold. We will only discuss items 04 and 05 at standup.

Item Aging Chart
Item Aging Chart

To create a chart like this from Jira stamp an “In Progress Since” date when an issue transitions into an in-progress status. Then you can sort/filter by that date every day (or build a dashboard).

  1. Create a custom field: In Progress Since (date/time).

  2. Create an Automation rule:

    • Trigger: Issue transitioned
    • Condition: To status in {In Progress, Doing, In Dev, …}
    • Action: Edit issue → set In Progress Since = {{now}}

Get the data using a JQL query like: JQL: status in ("In Progress","Doing") AND "In Progress Since" is not EMPTY ORDER BY "In Progress Since" ASC

Why This Keeps Standups Short (and Useful)

This approach eliminates three things that quietly kill flow:

  1. Status reporting
    “Still working on it” adds no information.

  2. Premature problem-solving
    Healthy work doesn’t need attention.

  3. Diffuse accountability
    Risk is visible, explicit, and owned.

Instead, the standup answers one question only:

Which work is at risk right now, and what are we doing about it?

If nothing is aging beyond the threshold, the meeting ends early.

That’s not a failure of collaboration.
That’s a sign the system is working.

This Is Not a Facilitation Trick

What we implemented was not a clever meeting format.

It was exception-based flow control.

The same pattern is used in:

  • Manufacturing Andon systems

  • Operations control rooms

  • Incident management in SRE teams

Normal flow is silent.
Only risk demands attention.

Why This Matters Beyond the Team

The deeper insight is this:

If we trust work item aging and WIP at the team level, we should trust them everywhere else too.

The same pattern scales cleanly:

  • Teams focus on aging stories

  • ARTs focus on aging features

  • Portfolios focus on aging epics

In each case:

  • Thresholds trigger attention

  • Exceptions drive decisions

  • Meetings stay short and purposeful

This is how flow replaces planning as the primary control mechanism.

The Takeaway

Daily standups don’t need better questions.
They need better signals.

When everything is discussed, nothing is controlled.
Flow improves when only aging work is allowed to speak.

Scroll to Top