Christophe MontagneInterim CTO · Advisory

Beyond the Demo/2 min read

06Bringing control back: a specific Definition of Done

When “done” becomes a risk decision, two levels of control bound by time, and who decides.

Short cycles are how the project learns, not how it is controlled. A team can run cycle after cycle, each showing a little progress, without anyone being able to say whether the system is good enough to use. That is how a pilot quietly becomes permanent.

Agile frameworks have a simple tool against this: the Definition of Done, an explicit, shared description of what work must satisfy before it counts as finished (described in more detail in my article on Agile planning). Usually it is an internal agreement within the team. Here it becomes something more.

When "done" is a risk decision

With no specification to meet, saying the system is done means saying its remaining errors are acceptable. How many wrong answers per hundred? What must happen when the documents don't contain the answer? These are decisions about risk, and they belong to the people who carry the consequences. The Definition of Done moves up from the team to management.

For our rail maintainer, a cycle's work is done only when, among other things: answers on the test set reach the agreed quality, with nothing that worked before getting worse; every answer cites the right version of the right document, and only documents the technician may see; safety-critical questions never receive a value the system cannot source; and the test set has grown with the cycle's questions and expert corrections, which is where much of the experts' knowledge gets written down.

Two levels of control, both bound by time

As Figure 7 shows, the Definition of Done decides at every cycle whether the work is kept, and the exit criteria from chapter 05 decide at every stage whether to move on, adjust, or stop. Repeated failures to meet the Definition of Done are themselves a reason to stop or rethink.

INSIDE ONE STAGE (for example, Walk) Envelope agreed in advance: max. N cycles and a fixed budget Cycle 1 fixed length Cycle 2 fixed length Cycle 3 fixed length Cycle 4 fixed length Stage gate move on, adjust, stop Every cycle: Definition of Done Is this increment good enough to keep? If not, it is not released, and the gap is the first item of the next cycle. End of stage: exit criteria Has the stage answered its question? Repeated failures to meet the Definition of Done are themselves a reason to stop.
Figure 7. Two levels of control: the Definition of Done at every cycle, the exit criteria at every stage, both bound by time.

Cycles have a fixed length, a few weeks at most. Each stage has an envelope of cycles and budget agreed before it starts; when it is used up, the gate is held whether or not the criteria are met. Without these limits, there is always a good reason for one more week (see Agile Planning). A timebox can shrink the scope. It must never lower the safety criteria.

Who decides

The team and the experts propose the thresholds, because they know what is achievable. The business owner approves them, because the risk is theirs. Safety criteria are not negotiable. Thresholds tighten from stage to stage, and every change is a recorded decision by the same people; otherwise the bar drifts until nobody can say what "done" means. Short cycles let the organisation learn. A Definition of Done owned by those who carry the risk keeps it in control.