Issue age distribution

Issue age distribution is the breakdown of currently open issues by how long each one has been open, sorted into age bands. Rather than reporting a single average age, it shows the full shape: how many issues are fresh, how many are a few days old, and how many have aged into weeks or months. A support queue might show 60% of open tickets under a day old, 30% between one and seven days, and 10% over a week, and that 10% tail is where the real risk sits.

The distribution matters because averages lie about backlogs. A team could report an average open age of three days while a handful of issues have quietly aged past sixty. Those old issues are the ones that turn into escalations, breached commitments, and frustrated customers, yet they vanish into a healthy-looking mean. The distribution keeps them visible by counting the tail separately from the bulk.

Issue age distribution applies anywhere work queues up and waits: customer support tickets, engineering bug backlogs, sprint boards, compliance cases, and procurement requests. In every case the question is the same. Not how many items are open, but how long they have been waiting, and whether the oldest ones are getting older. It pairs naturally with ticket volume and average resolution time, which tell you throughput while the distribution tells you what is stuck.

A healthy distribution is heavily weighted toward the youngest bands and tapers smoothly, with a thin and shrinking tail. An unhealthy one has a fat or growing tail, which means items are entering the backlog faster than the oldest ones are being cleared. Watching the shape move over time is more informative than any single snapshot, because a tail that is thickening week on week is a problem building before it becomes a crisis.

Measuring the distribution is less about one formula and more about choosing sensible age bands and the right summary statistics. Age itself is simply the elapsed time since each open issue was created. The work is in how you group and summarise it so the shape is readable at a glance.

1. 1

   Calculate each issue age

   For every open issue, subtract the created date from the current date. Use the original creation timestamp so age reflects total time waiting, not time since the last update. Closed issues are excluded, since the distribution is about the live backlog.

2. 2

   Define age bands

   Group issues into buckets that match how your team works. Support might use 0 to 1 day, 1 to 3 days, 3 to 7 days, and over 7 days. An engineering backlog might use weeks or months. The bands should make the tail visible rather than burying it in a single wide bucket.

3. 3

   Summarise with median and percentiles

   Report the median age, which resists outliers, and a high percentile such as the 90th or 95th, which captures the tail. The 95th percentile age answers the question that matters most: how old are the oldest issues that are not yet rare.

4. 4

   Track the shape over time

   A single snapshot tells you the current state. The trend tells you the direction. Watch the count in the oldest bands week over week. A tail that is growing means the backlog is ageing faster than it is being cleared.

Worked example. A support team has 200 open tickets. Of these, 120 are under a day old, 50 are one to three days, 20 are three to seven days, and 10 are over a week. The median age is under a day, which looks reassuring. But the 95th percentile age is about seven days, and last week it was five. The bulk of the queue is healthy while the tail is ageing, and only the distribution and its trend reveal that.

A metric tree explains why the distribution looks the way it does. The shape of the backlog is the net result of two flows and how work is handled in between: the rate issues arrive, the rate they are resolved, and the routing and prioritisation that decide which ones wait. When the tail thickens, the tree tells you which of these is responsible.

The inflow branch decomposes into how fast issues are created and whether arrivals spike or stay steady. The outflow branch decomposes into resolution rate, available capacity, and how often work is reopened. Between them sits the handling branch: triage speed, routing accuracy, and prioritisation rules that determine whether old issues get picked up or perpetually leapfrogged by newer, easier ones. A growing tail almost always traces to one of these, and each points to a different fix.

There is no universal target for an age distribution because the right shape depends on the work type and the commitments around it. A frontline support queue should be weighted overwhelmingly toward hours and a day, while an engineering bug backlog may legitimately hold issues for weeks. The benchmarks below describe what a healthy distribution looks like by context, focusing on the shape of the tail rather than the average.

Read the distribution against your own service commitments rather than an external norm. The useful question is not whether your median beats some benchmark, but whether the tail is within the limits you have promised and whether it is shrinking or growing. A team that resolves the bulk quickly but lets a tail age past its commitments has a worse real outcome than a team with a slower median and no tail at all.

Improving the distribution means thinning the tail without simply slowing the bulk. The goal is a shape weighted toward the youngest bands with a tail that is short and shrinking. That usually requires changing how old work is prioritised rather than just adding effort to the queue.

The metric tree approach starts by reading the shape. A fat tail with a healthy median points to prioritisation, so the work is in queue ordering and escalation rules. A distribution that is shifting older across all bands points to capacity or inflow, which is a resourcing conversation. The decomposition tells you which before you spend effort in the wrong place.

KPI Tree lets you connect each branch of the distribution to the team that owns it. Triage owns routing accuracy and orphaned issues. Team leads own capacity and resolution rate. Whoever sets the queue rules owns how the tail is prioritised. With RACI ownership on every node, a thickening tail pushes straight to the accountable owner the moment the shape shifts, and a verified impact loop confirms whether the new ageing rule actually shrank the old band or just reshuffled the queue. That is how the gap between a dashboard showing a growing backlog and a decision about how to clear it gets closed.

1. 1

   Reporting only the average age

   A single mean hides the tail entirely. A few items aged past sixty days disappear into an average that still looks fine. Always report the distribution and a high percentile, not just the average.

2. 2

   Measuring from last touch, not creation

   Resetting the age clock on every comment or status change makes stalled old issues look young. That hides exactly the items that need attention. Measure true age from creation.

3. 3

   Using age bands that bury the tail

   A final bucket of over seven days lumps a nine-day issue with a nine-month one. Use bands granular enough at the old end that the tail stays visible and its growth is obvious.

4. 4

   Watching a snapshot instead of the trend

   One reading tells you the current shape but not the direction. A tail that is small today but doubling each week is a problem forming. Track how the oldest bands move over time, not just where they sit now.

5. 5

   Confusing a slow median with an ageing tail

   These need different fixes. A slow median across all bands is usually capacity or inflow. A healthy median with a growing tail is prioritisation. Treating one as the other sends effort to the wrong place.