What does a low-scoring story actually cost?

A low-scoring story costs whatever the defect it becomes costs, paid later and by you. That is the whole argument for scoring a client’s backlog before you build from it, and it is easier to show than to explain, so here is one story from vague to shipped defect.

This is the guide to hand a client who agrees their requirements are “a bit thin” but doesn’t see why that should change the plan.

What does a story that looks ready look like?

Exactly like a story that is ready. That’s the problem: there is no visual difference between a well-specified story and an underspecified one, because what’s missing is absent, and absence doesn’t catch the eye in a backlog of four hundred rows.

Read it again as the developer who picks it up. What counts as a preference? Which channels? Does an admin override a user’s choice? What happens to preferences when the account changes? The story doesn’t say, so every one of those becomes a decision made quietly, at speed, by whoever is closest to the keyboard.

What does scoring actually flag?

A score turns that absence into something visible and sortable. The same story, scored, stops being a row in a backlog and becomes a specific, named risk with reasons attached.

The three findings matter more than the number. “Acceptance criteria are missing” is a fact anyone can verify in two seconds, which means the finding survives an argument. A single aggregate score invites debate about methodology; a finding that names the missing field invites a fix.

What happens if nobody acts on it?

The story gets built. It has to: it was in the sprint, it looked ready, and no gate stopped it. The undefined behaviour becomes defined by whatever the implementation happens to do, and the first person to discover the mismatch is a user.

Notice what the defect is not. It isn’t a typo or a failed test. It is a behaviour nobody specified, discovered in production, now costing a triage cycle, a fix, a regression pass, a release, and a conversation with the client about how it shipped. All of it traceable to an empty field two sprints earlier.

Why score requirements instead of tracking defects?

Because every other quality signal an agency has arrives too late to be useful commercially. Defect counts, escape rates, and rework hours are all measured after the build, when the money is already spent. Requirement quality is measurable at write time, which is the one moment when the fix is a paragraph.

The economics are the entire point. Adding acceptance criteria to PLT-2841 during refinement is a five-minute conversation. Fixing PLT-3190 after release is a defect ticket, a code change, a regression cycle, and a client apology. Same missing information, two very different invoices, and on a fixed bid, only one of them is billable.

Who ends up paying?

You do. The requirement was the client’s, but the defect arrives attached to your delivery, inside a price you already agreed. That asymmetry is the reason this guide exists: the party who writes the vague story is rarely the party who absorbs its cost, and the gap between those two parties is where agency margin quietly goes.

Which is also why the fix has to happen before the number is signed. Scoring the backlog during discovery converts an unknown into a priced risk; estimating from a scored backlog covers how to turn that into a number you can defend, and protecting fixed-bid margins covers holding the line after signature.

How do I show a client this chain in their own backlog?

Score it and point at the worst three. The argument lands differently when the story on screen is one their team wrote, about their product, with their ticket key. Drop a CSV export into the free evaluator for real scores in about 30 seconds with no signup, then read presenting findings to a client before you put any of it in front of the team that wrote it.