Task backlog growth

Task backlog growth is the net change in the size of your backlog over a period, calculated as tasks created minus tasks closed. If a team opens 120 tasks in a month and closes 100, the backlog grows by 20. If it opens 80 and closes 100, the backlog shrinks by 20. The sign matters more than the size: a consistently positive figure means demand is outrunning throughput.

The metric is useful because a raw backlog count is hard to read. A backlog of 400 tasks could be perfectly healthy for a large team or a crisis for a small one. Growth strips out that ambiguity and tells you the direction of travel. A flat backlog means the team is keeping pace. A growing one, week after week, means something upstream is feeding work faster than it can be cleared, and the queue will only get longer.

Backlog growth is best read as a rate over several periods, not a single snapshot. One bad week tells you little, because intake is naturally lumpy. A trend line tells you whether the team is in balance, slowly falling behind, or recovering after a spike. Pair it with the age of the oldest open tasks, because a stable count can still hide work that has been sitting untouched for months.

The core calculation is simple: subtract tasks closed from tasks created in the same window. The result is the net change in the backlog. Express it as an absolute number for capacity planning, or as a percentage of the starting backlog to compare teams of different sizes.

For example, a backlog of 200 tasks that grows by 20 in a month has grown 10 percent. Tracked across a quarter, a steady 10 percent monthly growth compounds into a backlog roughly a third larger, which is the kind of trend that is invisible in any single week but obvious in the rate.

1. 1

   Tasks created

   Count every task added to the backlog in the period, including reopened tasks. This is intake, the demand side.

2. 2

   Tasks closed

   Count tasks completed or cancelled in the same period. This is throughput, the supply side.

3. 3

   Net growth

   Subtract closed from created. Positive means the backlog grew, negative means it shrank, zero means balance.

4. 4

   Growth rate

   Divide net growth by the starting backlog size for a percentage that compares fairly across teams.

Backlog growth has exactly two sides, intake and throughput, and a metric tree makes that structure explicit. A growing backlog is either an intake problem, a throughput problem, or both, and the only way to intervene precisely is to know which. Decomposing the metric splits the headline number into the drivers each team actually controls.

KPI Tree lets you connect each branch to the team and action that influences it. The team triaging incoming requests owns the intake side. The team delivering work owns throughput. With RACI ownership on every node, the accountable owner sees their branch and how it rolls up to the headline number. When backlog growth turns positive and stays there, the change is pushed to the owner of the branch that moved, so the right team responds instead of everyone debating whose problem it is.

There is no universal target, because the right backlog growth depends on the kind of work. A support queue should run close to zero net growth, because tickets that pile up turn into angry customers. A product backlog can grow deliberately as ideas accumulate faster than they ship, as long as the team is honest that most will never be built. Use the ranges below as a guide, and always read growth against the age of the oldest open work.

You can only move backlog growth by changing one of two things: how much work comes in, or how much goes out. Most teams reach for throughput first, but tightening intake is often faster and cheaper. Before adding capacity, make sure the work entering the backlog is real, deduplicated, and worth doing.

1. 1

   Reading a single week as a trend

   Intake is lumpy, so one busy week looks like a crisis. Read growth as a rate over several periods, not a snapshot.

2. 2

   Closing tasks to game the number

   Mass-closing stale tasks flatters throughput without delivering value. Track tasks closed without an outcome separately.

3. 3

   Ignoring task age

   A flat backlog can still hide work that has sat untouched for months. Pair growth with the age of the oldest open tasks.

4. 4

   Blaming throughput by default

   Telling the team to work harder ignores the intake side. Decompose first, because the cause is often upstream of delivery.