Taking Stock Before You Dig: The Backlog Inventory

Leah was told on Tuesday to "get the backlog down by Friday". That is the kind of instruction that sounds like a plan and is not one. She did what anyone would do: opened the queue, started at the top, and worked. By four o'clock she had closed eleven tickets, mostly quick ones, and felt good about it. Then she looked at the count. It had gone from 412 to 409. Eight new tickets had arrived while she was closing eleven. And the eleven had all been from the last fortnight anyway. The old ones, the ones the backlog was actually made of, had not moved. Three days of that would get the number to roughly 400. The oldest ticket would be roughly the same age it was now, plus three days.

Leah had started digging without a map. The pile was real. The effort was real. And the two had barely touched. That is because the top of the queue is where the new tickets are. The backlog lives at the bottom. Before you dig, you count. You do it not because counting is satisfying (it is not), but because a backlog is several different piles wearing one number. Each pile needs a different shovel.

A backlog inventory is a one-afternoon count of every open ticket, cut four ways: by age, by status, by category and by assignee. It is followed by a rough sort of the old tickets into a handful of piles. The inventory is the map you dig by. This article is part of our Backlog Recovery series. The previous article, How a Ticket Mountain Forms, explained how the pile got there. This one is about looking at it properly before touching it.

It covers why the inventory comes before the dig, then the four cuts and what each reveals. Next come how to pull the inventory in an afternoon and triaging the backlog itself into piles. Then it covers what the numbers usually say when you read them and the honest number to give management before there is a plan. It finishes with what not to do while taking stock and the inventory table to copy.

Why the Inventory Comes First

Digging without an inventory fails in one of two ways, and both feel productive while they are happening. The first is Leah's: you start at the top and close what is quick. The number barely moves because the quick tickets were going to be closed anyway. The old ones are untouched. The second is the opposite: somebody decides the whole pile is dead. They close everything older than ninety days in one go. They spend the next month discovering which of those tickets were not dead at all. The first wastes a week. The second wastes trust, which takes longer to earn back than a week.

The inventory prevents both by replacing one number with a shape. Four hundred and twelve open tickets is a number that supports any plan you like and tells you nothing. "Two hundred and eighty over ninety days, of which a hundred and sixty are Awaiting Reply, ninety are assigned to someone who left, and forty are about a system that was replaced in the spring" is a shape. A shape suggests its own plan. It also answers the question management will ask first. That question is not "what are you going to do?" but "how bad is it?".

The inventory also protects the desk from the dig. A dig-out is two weeks of focused work, described in The Dig-Out Plan. Two weeks is only enough if the work is aimed. Aim comes from knowing that half the pile is one kind of ticket. Without the inventory, the dig is two weeks of opening tickets one at a time to find out what they are. That is the inventory done slowly, with interruptions, by someone who is also trying to fix things.

One afternoon is the right budget. Four hours, one person, one spreadsheet, the queue, and the door closed. Longer than that and the inventory becomes a project. The backlog pillar does not need another project in it.

The Four Cuts

Cut the open tickets four ways, in this order: by age, by status, by category, by assignee. Each cut answers one question, and the order matters because each one narrows the next. Cutting a list just means counting it by one attribute: how many in each age band, how many in each status, and so on. A spreadsheet does it with a pivot table or a handful of count formulas. A tool with a filter list and a live count beside each choice does it on screen.

By age first, because age says how much of the pile is backlog at all. Use the four bands from the measurement sheet: zero to seven days, eight to thirty, thirty-one to ninety, over ninety. The first band is not backlog. It is this week's work. The second is work that has slipped. The third and fourth are the pile, and the inventory is mostly about them. If most of the open count is in the first two bands, you have a busy desk and not a mountain. In that case, the plan is a closing-discipline plan rather than a dig-out.

By status second, because status says what each old ticket is waiting for. Count the old tickets, over thirty days, by status: how many are Awaiting Reply, how many On Hold, and how many Resolved and unconfirmed. Also count how many sit in whatever status your desk uses for "open and nobody has touched it". Each status is a different pile. Awaiting Reply over ninety days is a ticket the requester has very probably abandoned. On Hold over ninety days is a ticket waiting for a thing that has very probably not been chased. An untouched status over ninety days is a ticket that was never worked at all. That is the pile that embarrasses, and the one to be most careful with.

By category third, because category finds the clusters. A category is the label that says what kind of thing a ticket is about: access, hardware, software, printing, and so on. Count the old tickets by category and look for one that is far larger than its share of new tickets. Forty old tickets about the same system usually means one cause. That could be a system that was replaced or a request type that needs a budget holder who never answers. Or it could be a project that was raised as forty tickets. One cause closes in one decision. Forty tickets closed one at a time take a week.

By assignee last, and read it carefully, because this is the cut that gets misused. Count the old tickets by who they are assigned to, including "nobody" and "someone who has left". The point is not to find out who is slow. The point is to find the two patterns that always appear. One is a block of tickets assigned to a person who is no longer here. Nobody has looked at those since they left. The other is a block assigned to the most capable person on the desk. They will get to those when they have a free afternoon. Both blocks are structural. Neither is a performance review. (If you find yourself writing names on a whiteboard, stop.)

Pulling the Inventory in an Afternoon

Start with an export, if the tool has one. You want every open ticket with its number, created date, last updated date, status, category, assignee, requester and subject. Put it in a spreadsheet. Add an age column (today minus created) and a "days since last update" column (today minus last updated). You have the raw material for all four cuts. The second column is one that the measurement sheet does not have, and it earns its place here. A ticket created ninety days ago and updated yesterday is alive. One created ninety days ago and updated eighty-nine days ago is not.

If the tool has no export, use the filter counts. Most ticketing tools let you narrow the list by status, by assignee and by other attributes and show the count for each. That gives you the status and assignee cuts without a spreadsheet. The age cut is harder without an export, because it needs the created date of every ticket. But a backlog-by-age report, if the tool has one, does it for you. Between a filter list with counts, an age report and a CSV export, most tools cover all four cuts one way or another. The test is whether you can get a count by status, by assignee and by age band in under an hour. If you cannot, the list and a tally sheet still work. One thing to check first: whoever takes stock needs to see the whole queue. Many tools scope what a junior agent can see to their own assigned tickets. An inventory taken from that view will miss most of the pile. So confirm the counter's permissions before trusting the counts.

Then sample the old tickets. Do not read all two hundred and eighty. Read thirty, chosen at random from the over-ninety band. Write one line for each: what it is and whether the requester is still here. Include whether the thing is still needed as far as you can tell, and what it is waiting on. Thirty tickets takes about an hour and tells you the proportions. If twenty of the thirty are Awaiting Reply on a question nobody answered, roughly two thirds of the old pile is. You do not need to be precise. You need to know which pile is biggest.

The event history helps with the sample. A ticket's history shows every reply, note, status change and assignment. Some tools also show how long the ticket spent at each status and how often it changed hands. That is worth a look if yours does. A ticket that has been reassigned four times and replied to never is a different animal from one that was worked for a week and then parked. The history tells you which in ten seconds. Read the history before the ticket. The ticket says what the requester wanted. The history says what the desk did about it.

Triaging the Backlog Itself

Once the cuts are done, sort the old tickets into piles. Triage, on a help desk, is the quick sort that decides what each new ticket is and who gets it. It is described properly in What Triage Actually Is. Triaging a backlog is the same sort applied to old tickets, with one difference. The first question is not "what is this?" but "is this still real?". Five piles cover almost everything, and the table below is the decision for each.

The piles are decided on the sample first and then on the whole band. Decide quickly, from the subject line and the last update, without opening every ticket. You will get some wrong. That is fine, because the dig-out opens each ticket before anything irreversible happens to it. A ticket in the wrong pile is noticed then. The inventory's job is proportions, not verdicts. If it says a hundred and sixty of two hundred and eighty are waiting on someone, the plan is mostly a chasing plan. That is the fact that matters.

Two piles deserve a warning. "Probably dead" is the pile that becomes ticket bankruptcy. Bankruptcy done carelessly costs more than the backlog did. How to do it carefully is the whole of Declaring Ticket Bankruptcy. And "real work and still needed" is the pile that nobody wants to find. It is the pile that cannot be chased or closed, only done. Count it honestly. It is the number that turns into a request for time, and management can only give you time for a number they were told.

What the Numbers Usually Say

Here is what the inventory looked like at Bellweather Logistics, a desk of four with 517 open tickets. The shape is typical. By age: 88 in the first week, 61 in the second band, 104 in the third, and 264 over ninety days. By status, for the 368 over thirty days: 171 Awaiting Reply, 42 On Hold, 38 Resolved and unconfirmed, 117 never moved from the status they were created in. By category, the over-ninety band had 71 tickets about a warehouse scanning application that had been replaced four months earlier. It had 36 about access to a shared drive that had been migrated. The rest were spread evenly. By assignee: 93 assigned to Ruben, who had left in the winter, 61 to Anja, the senior technician, 40 unassigned, and the rest spread.

Read it and the plan writes itself. The 71 scanner tickets and the 36 shared-drive tickets are two decisions, not 107 tickets. Ruben's 93 are nobody's, and nobody has read them since he left. So they are the first sample to take. The 171 Awaiting Reply are one chase message and one closing date. The 117 never-moved tickets are the real inventory, and a sample of thirty of them will say how many are still alive. The 38 Resolved tickets are a closing rule that does not exist yet. Only Anja's 61 are a conversation. The conversation is not "why have you got 61" but "which of these needs you and which could anyone do".

Three patterns show up in nearly every inventory I have done, and it is worth expecting them. First, between half and three quarters of the old pile is waiting on someone other than the desk. That part of the pile has been waiting so long that the wait has become permanent. Second, there is at least one cluster of tickets about a thing that no longer exists. Third, the number of old tickets that are real, unstarted, still-needed work is far smaller than the headline count, usually a fifth of it or less. That third pattern is the good news, and it is the reason to take stock before panicking. A mountain of four hundred is usually a hill of eighty with a lot of weather on top.

The Honest Number Before the Plan

Tell management the number before you have the plan, not after. The instinct is the other way round: find out how bad it is, work out what to do, then present the problem and the solution together. That way, you look organised. The trouble is that the plan takes a week to make and a fortnight to run. During that time the number exists and management does not know it. If they find it out from somewhere else, from a director whose ticket was fourteen months old, every plan you present afterwards looks like a cover story. Tell them the shape the day the inventory is done.

The honest number is four sentences. How many open tickets there are and how many of those are over ninety days old. What the biggest pile is and what it is waiting on. What the desk is doing in the next two weeks and when the next number arrives. And one thing you need, if there is one, even if it is only "two afternoons a week with no interruptions for a fortnight". Here is Bellweather's: "We have 517 open tickets, 264 of them over ninety days old. About 170 are waiting for a reply from the requester and roughly 100 are about two systems we have since replaced; fewer than 80 look like real unstarted work. We are starting a two-week dig-out on Monday and I will send the count every Friday. I need the team protected from project work in the afternoons for those two weeks."

Say what you do not know, in the same breath. "I have sampled thirty of the old tickets, not read all of them, so the proportions are estimates and the exact number of real tickets will move." A manager who hears that trusts the rest of the paragraph more, not less. That sounds like a person who counted rather than a person who guessed. Whereas a precise number delivered with total confidence will be remembered precisely, and held against you precisely, when the dig-out finds something the sample missed. The full briefing, with the one-page format, is in Explaining the Backlog to Management. The four sentences are enough for day one.

Do not promise the end state. "We will have it down to fifty by the end of the month" is a sentence that feels good to say. It will be quoted back at you on the thirty-first. The inventory tells you the shape, not the speed. Promise the dig-out, the Friday number, and a plan with dates after the first week, when you know how fast the piles actually move. Managers can live with "I will tell you on Friday". What they cannot live with is a number that was promised and then quietly redefined.

What Not to Do While Taking Stock

Do not fix things during the inventory. You will open a ticket to see what it is, see that it is a two-minute job, and do it. Three hours later you will have done nineteen two-minute jobs and have no inventory. It is the most natural mistake on the desk. I made it on every inventory I ever started before I learned to write the ticket number on a list and move on. The list is the point. The fixing is next week.

Do not close anything either, not even the obvious ones. The ticket about the replaced scanner application looks dead and almost certainly is. But "almost certainly" is a dig-out decision, made with the ticket open and a reply written to the requester. Closing during the inventory produces a pile of silent closes, where the status changes and the requester hears nothing. A silent close on an old ticket is the one thing that makes a requester angrier than the old ticket did. In many tools, changing a status alone sends the requester nothing at all. So every close needs a reply. That is time the inventory does not have.

Do not reassign tickets, and do not escalate them. Moving Ruben's 93 tickets to Anja makes them Anja's problem without making them anyone's work. It generates 93 assignment e-mails that will not be read. The tickets are not going anywhere. They have been there for a year. Another week in the same place, properly counted, costs nothing. Reassigning them in a hurry costs the inventory its accuracy and Anja her afternoon.

And do not announce anything. The inventory is a count. The temptation to tell the organisation "we are tackling the backlog" before the plan exists is strong. It feels like action. It is not action. It is a promise with no date on it. The organisation has had enough of those from the desk. Announce when the dig-out starts, with a date, and when the bankruptcy happens, with a message that has been written carefully. Until then the inventory is the desk's own business.

A Short War Story: The Afternoon Nobody Spent at Ashgrove Housing

Ashgrove Housing's desk had three people supporting a housing association's offices and its tenant portal. The desk was told to clear a backlog of 290 tickets. It started on the newest ones the same morning, because the newest ones were at the top. Owen, the newest technician, spent nine working days closing recent tickets while the old ones sat untouched. The count went from 290 to 271. In the second week, a tenant services manager asked about a block of sixty tickets. They were all over a hundred days old. All were about login problems on a tenant portal that had been replaced in the spring. The desk had not noticed because nobody had cut the pile by category. Forty minutes with a spreadsheet would have found them on day one. Instead the desk had spent nine days doing its normal work faster and calling it a dig-out. The cost was two lost weeks and one awkward meeting. There was also a bankruptcy message for sixty tenants that had to be written in a hurry rather than carefully. Owen now gives the lesson to every new starter: a backlog is dug from the bottom. You cannot see the bottom without counting it first.

The second attempt started with a four-hour inventory. The sixty portal tickets were one decision. A hundred and ten Awaiting Reply tickets were one chase message. The real unstarted work turned out to be forty-four tickets. The desk cleared them in eight working days.

The Backlog Inventory Table

The table below is the inventory on one page. It has the age cut across the top, the piles down the side, and the status, category and assignee cuts underneath. Fill the age columns from the export or the report. Fill the pile rows from the sample and your best estimate for the rest. Fill the bottom three sections from the filter counts. Blank cells are the ones you fill in. The right-hand column is the one management will read.

Keep the completed table. It is the "before" that the dig-out is measured against. In a month it is the evidence that the plan worked, or the evidence of exactly where it did not. A desk that can show the table from before and the table from after has a story that needs no adjectives.

Leah's second attempt at "get the backlog down by Friday" started with the table and took until the following Friday. That is a week later than asked and a year sooner than the alternative. The count was 412, then 409, then 412 again on the day the inventory was finished, because the inventory closes nothing. The table said 280 over ninety, 160 waiting on someone, 40 about a replaced system, 52 real. Fifty-two is a number you can dig. Four hundred and twelve was just weather.

Frequently Asked Questions