Parts 1 through 4 each named a KPI — a key performance indicator, the one number a piece of work is judged by. That's not a writing habit; it's how the work is sold, built, and judged. We've written elsewhere about why the contract is shaped as two-week fixed prices — the short version is that a fixed price on a year of work carries a year of contingency (padding for unknowns), and two weeks of it is small. This post is about the other half of that shape: the number each sprint is held to.
What makes a number a good KPI
Discovery produces a list of places the shop is losing time or money. Most of them can be turned into a sprint. The ones that make good sprint KPIs share four properties:
It's measurable before and after with the same instrument. Office minutes per order, timed the same way both weeks. WIP at the station, counted the same way. If the "before" was a guess and the "after" is a dashboard, nothing was measured — a change in instrument looks like a change in the business.
It can move inside two weeks. "Lead time" is a fine goal and a bad sprint KPI — too many things feed it and most of them don't change in two weeks. "Order-to-floor latency" is the part of lead time this sprint can actually touch. Pick the part.
It's a business number, not a software number. "Order-entry screen shipped" is a deliverable, not a KPI. "Orders entered per hour, per person" is a KPI. The screen is how; the number is why. A sprint that ships the feature and doesn't move the number didn't count, and we'd rather say that than celebrate the feature.
Someone in the shop already cares about it. If the number has to be explained, it's the wrong number. The best KPIs are things the owner already checks — the cart in front of the bottleneck, the late list, the remake pile — made exact.
From the earlier posts: completions per day at the station. Keying errors per month. Percent of jobs whose position the system knows without a walk. Each one passes all four tests, and each one is the kind of thing a shop owner nods at without a slide.
What goes on the quote
The sprint quote is one page, and the number is on it:
- The price. Fixed. Known before anything starts.
- The KPI, its current value, how it was measured, and the target.
- What ships — the software, deployed to a URL the shop can click.
- What we'll show at the end: dated before/after screenshots, the measurement rerun the same way, and anything that didn't match the target.
That last line is the one most proposals leave out, and it's the one that matters. A quote that names the number and the instrument before the work is a quote that can be checked. One that says "improve order entry" cannot, and it isn't an accident that it can't.
How it gets proven
"You never take our word for it" has to come down to specific things or it's a slogan. It cashes out as:
- A live URL every sprint. Progress is judged by clicking the app, not reading a status deck. If it isn't deployed, it didn't ship.
- Dated before/after evidence. Screenshots, each dated, kept in a folder the shop can scroll back through. A running record of what changed and when.
- The same instrument, rerun. The minutes get timed again. The WIP gets counted again. By the same method, written down, so the comparison is honest.
- Reconciliation against history when the sprint touches numbers the business runs on. A pricing engine isn't done when it computes a price; it's done when it reproduces last year's invoices, and the cases where it doesn't are listed, not smoothed over.
- An audit trail in the delivered system, enforced by tests. Every write logged. Not as a feature — as the thing that makes every later measurement trustworthy.
What happens when it misses
Sometimes the number doesn't move. The office found a workaround we didn't see; the station's real bottleneck was the one next to it; the shop changed a process mid-sprint. This is not a failure of the method — it's the method working, two weeks in instead of a year in.
What we do: say so, in writing, at the end of the sprint. The retrospective names what moved, what didn't, and our best read of why. Then the shop decides the next sprint with that in hand — change direction, repeat, or stop. What we don't do is roll the miss quietly into the next quote and hope. The miss is information, and it was paid for.
Every quarter, the retrospective becomes a written document: what shipped, what the KPIs actually did, what we learned, and the updated plan. It's the discovery deliverable kept alive, and like the original, the shop keeps it whether they keep us or not.
And if you have to RFP
Some organizations can only buy through an RFP (request for proposal: a formal bid for the whole project), and we'll answer one. Two honest things about it:
It costs more. An RFP wants a fixed scope and a single fixed price for all of it, which means pricing every unknown across the whole project up front. That's the year-of-contingency problem in its purest form. The same work bought two weeks at a time usually costs less, because the unknowns get retired before they're paid for.
We'll shape it as stages, not one number. When we bid a well-specified project, we bid fixed-price stages, with the contingency stated per stage rather than buried in the total, and a rule written into the proposal: discovery can only lower the number, never raise it. If the first stage finds the job is smaller than the RFP assumed, you pay less. It's the closest an RFP can get to the two-week promise without being one.
If you don't have to RFP, don't. Ask for the number, the instrument, and the two-week price instead — from us or from anyone.
Next: the rare rung — when the honest answer really is the full overhaul, and what one actually looks like from the inside.