Skip to content
← All writing

The say/do ratio: measuring delivery predictability without scoring people

· 5 min read · by Tan Gravam

What is the say/do ratio, and how do you measure delivery predictability?

The short answer

The say/do ratio is the number of delivery commitments kept divided by the number made in a period, usually a quarter. It measures delivery predictability only if three things hold. Count from the baseline, so a commitment that was quietly dropped or re-dated still counts as made. Count three outcomes separately: delivered as committed, delivered with exclusions, and not delivered. And keep it at the level of the organisation, never per person or as a ranking of teams, or people start promising less. Report the piles rather than one percentage, then split the misses by whether the commitment was made early, before the evidence was in place. Do not set a target; watch the direction over several quarters.

The say/do ratio is the simplest delivery metric there is: of the things we said we would deliver, how many did we deliver? Leadership likes it because it fits on one line. Teams distrust it because they have seen what happens to a number once it is pointed at them.

Both are right. The ratio is worth keeping, and it lies in three specific ways unless you count it from a record instead of from memory.

What the say/do ratio is

Commitments kept, divided by commitments made, over a period. The unit matters more than the arithmetic. Count delivery commitments: the promises made to someone outside the team, with an owner, a scope and a date. Do not count story points or tickets. A sprint plan is a forecast, not a commitment, and a ratio built on forecasts measures how well people guess.

A quarter is the natural period. Shorter, and most commitments are still open when you count. Longer, and nobody remembers what was said.

Three ways the number lies

The denominator moves. Twelve things were promised in January. Two were quietly dropped in February and one had its date moved in March. At quarter end the list shows nine commitments, eight delivered, and the ratio is 89%. Counted from what was said in January it is eight of twelve.

The fix is to count from the baseline, not from the current list. A commitment that was removed is a commitment not kept, unless the removal was itself a recorded decision. A commitment whose date or scope changed is a re-baseline, and the number of re-baselines belongs next to the ratio.

"Done" is counted instead of "as promised". Work shipped on the date with a third of the scope cut counts as kept in most spreadsheets. So does work that shipped everything six weeks late. "Delivered" is not an outcome. There are three, and they should be counted separately: delivered as committed, delivered with exclusions, and not delivered. A ratio that merges the first two reports the team's persistence, not its predictability.

It gets pointed at people. The moment the ratio appears next to a name, or in a table that ranks teams, it stops measuring delivery and starts measuring caution. People promise less, split promises into safer pieces, and negotiate scope down before saying yes. The number goes up and the organisation gets slower.

Keep it at the level of the organisation, or of a whole portfolio. It is a measure of how good the organisation is at deciding what to promise. That decision is made by several people, and most of a miss is decided before any code is written.

How to count it honestly

At the end of the quarter, list every commitment that was made for it, from the record of when each was made. Sort them into four piles.

  • Delivered as committed. Scope, date and outcome as promised.
  • Delivered with exclusions. Something shipped; write down what differed.
  • Not delivered. Closed, with the reason.
  • Still open. Neither closed nor re-baselined. This pile should be empty, and it never is the first time.

Report all four, not one percentage: "Twelve made. Seven as committed, two with exclusions, two not delivered, one still open. Three re-baselines." That sentence takes ten seconds to read and cannot be gamed by redefining a word.

Then make one cut, the only one that explains anything. Split the misses by whether the commitment was made with the evidence in place or made early, as an exception. If most misses were early commitments, delivery is fine and the deciding is not. If most were commitments everyone agreed were ready, the bar for "ready" is wrong. Those are two different problems, and the bare ratio cannot tell them apart.

What a good number looks like

Not 100%. A team that keeps every promise for a year is promising too little or defining "kept" too kindly. An organisation that delivers seven of ten as committed and can say exactly what happened to the other three is in better shape than one reporting 95% with nobody able to list the commitments.

Do not set a target for it. Watch the direction over three or four quarters, and watch the composition: fewer silent removals, fewer commitments still open at the close, a smaller share of early commitments among the misses.

What to do with it

Two things. Use it to size next quarter: if two of ten slipped because unplanned work took the room, that is an argument for a visible capacity reserve, not for working harder. And put it in the report leadership reads, in the four-pile form, with the lessons from the misses beside it.

If you use DeliverySheet

The product keeps the record the count needs and does not compute a score from it. Every commitment is a recorded baseline; a change of date, scope or capacity is a re-baseline with its reason, and the Commitment ledger report shows which commitments were re-baselined. Closing one requires choosing one of the three outcomes, with what differed when it was not a clean delivery, and the Reports page states how many recorded outcomes were delivered as committed. Early commitments have their own report, with the outcome each one ended on. All of this is at workspace level. Nothing in it is a number about a person.

I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.

$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.

Not ready for that? Play eight rounds of Request or topic? It takes two minutes and needs no sign-up.

More on after the commitment

Read the overview: After the commitment: tracking, closing and learning →

  • Green is a judgement, not a colour

    Status reporting decays into a colour nobody believes. What makes it useful again is requiring the reason, not the rating.

  • What "complete" should mean

    Most systems call work complete when it stops. A more useful definition: complete when the outcome is recorded and something was learned.

  • "Delivered" is not an outcome

    Closing a commitment with a checkbox loses the only information worth keeping: what shipped, and how it differed from what was promised.