How do I audit a backlog when the project is already slipping?

When the project is already slipping, audit the backlog that remains, not the sprints that went wrong. Score what is left, split the slip into the part that traces to requirement quality and the part that doesn’t, and put both into a single recovery plan. A backwards-looking audit produces an argument; a forwards-looking one produces a schedule.

This is the hardest audit an agency runs, because you are not a neutral party. You are the vendor, the delay is partly yours, and anything you say about the client’s requirements can be heard as deflection.

Why score the remaining backlog first?

Because it is the only part still under anyone’s control, and because it changes the meeting. Scoring delivered work invites a forensic argument about decisions taken months ago, with both sides motivated to remember them differently. Scoring the remaining two hundred stories asks a different question: given what we now know about how these requirements are written, what will the next three months actually cost?

That question has an answer, the answer is measurable, and nobody has to lose face to accept it.

How do I separate requirement quality from my own delivery?

Deliberately and in public, because a rescue readout that finds the client entirely at fault has no credibility. Do the split explicitly:

• Traceable to requirement quality. Rework on stories that scored below the bar, defects from behaviour that was never specified, estimates that moved after a clarification. Evidence, per story, from the scoring engine.
• Traceable to delivery. Your own estimation misses, staffing gaps, environment problems, decisions you got wrong. Name these first if you want the rest to be believed.
• Neither. Third-party dependencies, access delays, market changes. Worth listing so the total adds up.

A distribution across three named causes reads as engineering. A single cause that happens to be the client reads as an excuse, even when it is true.

How much of the delivered work should I score?

Enough to establish that the pattern is real, and no more. If ten of the twelve defects in production came from stories that scored in the bottom quartile, that is a finding worth two slides — it demonstrates the mechanism rather than asserting it. Beyond that, more historical scoring buys nothing except a longer argument.

The full causal chain from a low score to a shipped defect is worked through in what a low-scoring story actually costs, which is a useful thing to send ahead of a rescue readout so the mechanism is understood before the numbers about their project appear.

What does the recovery plan contain?

1. A quality gate on the remaining backlog. No story enters a sprint below an agreed score. This is the single change that stops the slip compounding, and it is cheap.
2. A hardening pass on the worst stories, sized and scheduled as real work rather than absorbed into refinement.
3. A re-baselined date built on scored stories, so the new date rests on different evidence than the one that slipped.
4. A re-score cadence, so movement is visible every fortnight rather than asserted at the end.

How do I keep the client’s trust while doing this?

Make the findings an artefact rather than a conversation. A written report is re-readable, forwardable to a sponsor who wasn’t in the room, and impossible to remember as more hostile than it was. It also survives the staff change that happens on most troubled projects.

Then close on the re-score, because a rescue is judged on movement rather than on diagnosis. When the second round shows the remaining backlog above the bar and the new date holding, the audit stops being the meeting where things were bad and becomes the point where the project turned. Vindex adds that round-over-round comparison to the report automatically once a project has two scoring rounds; how a project works shows the loop end to end, and auditing a client backlog covers the cleaner pre-engagement version of this exercise.