Up To Your Arse In Alligators? The Hard Truth About Work in Progress (WIP)

Let me ask you a few direct questions: Exactly how many tickets do you have in your system right now? And how old is the oldest one? 30 days? 45 days? How about 60?

Now for the most telling metric: How many of those tickets are In Progress? By "In Progress" I mean it has actually been touched at some point by a tech or engineer—they've logged time, or the status is no longer “New”; they have in fact started work on the ticket.

The term for all these "In Progress" tickets is of course Work in Progress (WIP).

I'm here to tell you what most service delivery teams don't fully understand: Your team's belief that every ticket has to be touched as soon as possible is a fallacy. This idea that you have to "get started" on every issue just so the client thinks you're on it is actually a performance dampener and a time stealer.

For the sake of real efficiency and performance, that thinking couldn't be farther from the truth.

WIP is actually one of the greatest leading indicators of your team's performance. Too much WIP is the sprawl of more issues being opened and started than your team can possibly manage while still maintaining high customer satisfaction.

One of my favorite sayings is, "When you're up to you’re a$$ in alligators, it's hard to remember that your primary objective was to drain the swamp." Your job is to get WIP under control. To do that, you must do two things: Measure it, and manage it.

Step 1: How to Measure Your WIP

You can't manage what you don't measure. It's that simple.

To get a handle on your WIP, you must track it in (at least) two ways:

1. As a Percentage of Total Issues: This is the most straightforward calculation.
• (Total Tickets In Progress) / (Total Ticket Count)
2. As a Percentage of Total Backlog Hours: This is a more advanced and accurate metric.
• (Total Estimated Hours for In-Progress Items) / (Total Hours Estimated for All Issues)

Of course, to calculate this second metric, your team must have the discipline to put a time estimate on every single issue that comes in. If you're not doing that, you don't have a clear picture of your total service backlog. Start there.

Step 2: How to Manage Your WIP

Now for the execution.

If you start tracking WIP alongside your other key metrics, you will find an undeniable correlation: As you allow your WIP to grow, your average Lead Time for a ticket (how long it lives from initial entry to close) will also grow.

And right alongside it, your customer satisfaction will be falling.

Your job as a leader is to find the "sweet spot" and set a hard limit for your WIP. This is the cutoff.

Note that this WIP threshold is team-specific. A crack team of senior engineers can handle a higher level of WIP than a slower, less efficient team. You must track your own data—WIP, Lead Time, and CSAT—to find out where your team's limit should be.

It may be at 50% of the total ticket count or 30% of the total backlog hours. Whatever that number is, here is the rule:

Once you hit that WIP limit, the team must stop opening new issues.

I’ll repeat that. They stop pulling new work. Their entire focus must shift to closing existing issues until they have brought the WIP sufficiently back down under the limit.

This isn't about arbitrary numbers; it's about building a system of discipline. Focus on limiting your WIP. It's the only way to keep your issues from getting too old and spiraling out of hand. This, in turn, is what actually keeps your Customer Satisfaction at the highest levels—not the illusion of progress, but the reality of completion.

 _{Image created using ImageGen by Envato}