DoD Expansion Is the Cheapest Improvement Instrument

A team I sat with last year had a Definition of Done pinned to the wall: code reviewed, unit-tested, merged to main. It was a good list. It had been a good list for about eighteen months, which was the problem, though nobody in the room saw it that way.

I asked when they had last changed it. There was a pause, the kind that tells you the answer is "we haven't." Someone offered that they hadn't needed to, because the definition still held. Everything they shipped met it. The bar was being cleared every Sprint.

That is what a stalled improvement loop looks like from the inside. It does not look like decline. It looks like consistency. The team clears the bar, the bar stays put, and everyone reads the steadiness as quality. A standard that has gone quiet feels exactly like a standard that has been mastered, and from the inside there is no way to tell the two apart.

A stable bar is not a high bar

Here is the diagnostic, stated plainly. If your Definition of Done has not expanded in a year, your team has stopped maturing. The stability you are reading as quality is the signature of a loop that has gone quiet.

This sounds harsh, and it lands wrong at first, because we are trained to treat a stable standard as an achievement. You set the bar, you meet it consistently, you call that operational excellence. But a standard you can always meet is not measuring your ceiling. It is measuring your comfort. The day a definition stops changing is the day it stops telling you anything about whether you are getting better. It only tells you that you have not gotten worse.

And a Definition of Done is not a scorecard for local efficiency, for how cleanly each step in your own pipeline runs. It measures how close the team is to product done: the whole product actually shippable, not just the slice this team happens to own. Maturity is movement toward that whole, not a tidier version of the work you already do.

Everything the product needs in order to ship, but that your definition does not yet require, still has to be done by someone. In Larman and Vodde's LeSS it has a name: undone work, and it collects in the undone department, the separate QA group, the integration team, the release engineers, the hardening Sprint bolted on before each release. So a piece of work is never simply done. It is done plus undone. What you can actually ship equals your Definition of Done plus everything you quietly handed downstream.

A frozen definition feels fine precisely because that undone half is invisible from where the team stands. They clear their bar every Sprint and never watch the undone pile building up somewhere else. The steadiness on the wall is not the absence of a gap. It is a gap nobody is looking at anymore.

Compare this to the team that keeps moving the bar up. Six months in, they add integration tests. A year in, they require performance benchmarks and a clean security scan. Eighteen months in, every change deploys to staging automatically with smoke tests. Two years in, it ships to production behind a feature flag, with telemetry in place. Each of those additions does something uncomfortable: it makes last quarter's "done" retroactively not done. Work that shipped clean by the old definition is now visibly incomplete by the new one.

That discomfort is the whole point. A definition that never embarrasses your past work is a definition that has stopped doing its job.

The cheapest way to restart the loop

There are expensive ways to restart a stalled improvement loop. You can run a transformation program, hire consultants to assess your maturity, stand up a center of excellence, commission an audit, buy a tool that promises to surface waste. Most of that produces reports. Little of it produces a changed system.

Expanding the Definition of Done is different, and not because it is painless. The work it triggers is expensive, and it should be. The real cost of any improvement is learning, and learning a team out of its current habits (writing the tests it skipped, building the pipeline it never had, cross-training people who have only ever done one job) is slow and hard whatever route you take to it. You pay that bill no matter which instrument you choose.

What the expensive routes add is everything wrapped around the learning: the program, the assessment, the consultants, the tool, the stack of reports. Expanding the definition adds almost none of that. No new headcount, no new budget line, no off-site. In a short retrospective, you agree on one thing the current definition does not yet require, and write it down. The instrument is nearly free. It simply refuses to pay the learning bill for you, because nothing can.

And writing the line is not the same as meeting it. Adding "deploys to staging automatically" to your definition takes a sentence; building the pipeline that makes it true takes weeks. That gap is the whole point. From the moment the line is written, every piece of work is held to a bar the team cannot yet clear, and each expansion pulls a slice of undone work back inside the team: the integration that used to wait for a separate group now has to happen in the Sprint, and the undone department shrinks by exactly what you absorbed. This is what I find genuinely useful: the expansion is the diagnosis and the commitment in one move. It shows you where the team is weak by what the new requirement exposes, and it commits the team to the expensive learning that closes the gap, aimed exactly where the product needs it.

This is what Taiichi Ohno meant by kaizen, stripped of the poster version. Standardize the current best practice, because a team with no standard has no baseline to improve against. Then improve the standard, observe the result, and write down the new baseline as the next temporary one. The phrase that holds it together is "no standard, no kaizen." The phrase that is usually forgotten is the other half: every standard is temporary. Ohno told his people they were not earning their pay if they left the standardized work unchanged for a month. The Definition of Done is the standardized work of a software team, and the same rule applies to it.

And the signal is loud, because the definition touches everything. A metric on a dashboard needs someone to interpret it. An expanded DoD changes what "finished" means for every item in the backlog the moment you write it down. Once the new requirement is in the definition, there is nowhere left to hide a practice the team has quietly stopped doing.

Expand toward what?

It helps to know what you are walking toward, and here most "excellence" programs get the destination backwards. They treat the goal as maximal: more checks, more controls, more gates, until the definition is a wall of requirements nobody can hold in their head. That is the local-efficiency reflex again, polishing the checklist instead of the product.

Aristotle had the opposite idea. Something is complete, he wrote, when nothing can be added and nothing can be taken away. Perfection is as much about what is absent as what is present. For a software team the heading is not "the longest possible Definition of Done." It is closer to a perfect Definition of Done: every day the whole product is shippable, with no undone work left over and no step that does not serve the customer. Most expansions move you toward that by adding a requirement. Some, eventually, move you toward it by removing one: a manual check you used to need becomes automatic, so it leaves the definition entirely.

You will never arrive. That is deliberate. The vision is a compass heading, not a milestone. The gap between today's definition and product done is your undone work, and the point of holding an unreachable heading is that the gap never quite closes, so the pull to improve never switches off. A reachable target gets reached, and then improvement stops, which is precisely the wall the year-stable team walked into.

Why teams freeze it anyway

If the instrument is this cheap and this useful, the interesting question is why so few teams keep reaching for it. The cost of the learning is part of the answer, and it is real. But it is not the whole answer, because teams freeze the definition even when they could afford the next step. The rest is politics, and it is rational.

Expanding the Definition of Done means standing up and saying that work everyone agreed was finished is now not finished. It makes the undone work visible, and that visibility is expensive. Someone reported that work as complete. Someone's status update, someone's release note, someone's promise to a stakeholder rested on the old definition. When you raise the bar, you make those reports retroactively optimistic, and the people who made them feel it. The team that freezes its DoD is not avoiding effort. It is avoiding the conversation where last quarter's "done" gets reopened and the undone pile gets named out loud.

This is why the instrument needs cover from above. A team will only keep expanding the definition if the people they report to can tolerate visible imperfection: if "this used to pass and now it doesn't" reads as the loop working rather than as the team backsliding. Where that tolerance is missing, teams learn the lesson quickly and stop touching the definition, not because the bar is right but because moving it is dangerous. The freeze is a reasonable response to a manager who punishes the appearance of incompleteness more than the fact of stagnation.

So think again about the team with the good list on the wall. Their definition had not moved in eighteen months, and they read that steadiness as quality. But steadiness cannot tell them that. A frozen bar is exactly what would hide a pile of undone work accruing downstream, and also exactly what genuine mastery would look like. From inside the room the two are identical. The only way to find out which one you are living in is to raise the bar and see what fails.

The question to take into your next retrospective is not whether your quality is good. Your quality being good is exactly what a stalled team feels. The question is when your Definition of Done last grew, how much undone work is sitting downstream of it, and whether anyone in the room has the standing to make the discomfort of naming that safe. If nobody does, the stability on your wall is not a product that is done. It is a loop you have quietly switched off.