Skip to content
ELEMENT 31

Glossary: done means

Done means is the statement, agreed at the start of an engagement, of what should be true when the work is finished. It is the measure every version is checked against and the handoff is signed off against.

· 2 min read

IN SHORT

Done means is the statement, agreed before an E31 Consulting engagement begins, of what should be true when the work is finished: a desk that drafts and waits, a corpus people can question, or a product customers run under the customer's name. Every version is checked against it, the handoff is signed off against it, and it always includes the site team being able to publish the next version themselves.

Done means is the statement, agreed at the start of an engagement, of what should be true when the work is finished. It is written in terms of the outcome the site will hold, such as a desk that drafts and waits, a corpus people can question, or a product customers run under the customer's name.

Why it matters

An engagement without a statement of done cannot end, because nobody can say whether it has. E31 Consulting will not begin without one. The statement is the measure every version is checked against and the thing the handoff is signed off against.

It also keeps the scope honest. When the site discovers during the work that it wants more, the statement is what makes that discovery visible as a new scope rather than an unwritten extra. That protects the operators, who need to be trained on a stable thing, and the record, which should describe one behaviour.

How it works here

The statement is short and concrete. It names what the use case does, who approves before results land anywhere, which systems it reaches, and who will be able to change it afterward. It is written in the site's vocabulary: if the floor calls a packet a ticket, the statement says ticket.

In a forward-deployed engagement the statement is sharpened while the engineers sit with the desk, because the desk often knows better than the brief what a good result looks like. In an in-house project the statement is the scope, and the customer owns it from the first conversation.

The statement includes the site team being able to publish the next version themselves. That part is not optional, and it is why training is part of the work rather than something added at the end.

When the published version satisfies the statement, the site team has made each change in scope with their own hands, and engineer access has been withdrawn, the engagement is done. Everything that was built stays on the customer's appliance.

Questions this raises

Who writes the statement of done?
The customer owns it. The practice helps sharpen it, and in a forward-deployed engagement it is refined while the engineers sit with the desk, but the customer has to be able to say in their own words what should be true at the end.
What happens if we want more during the work?
The statement makes that visible as a new scope. The current engagement is finished against the original statement, and the addition is a new version, scoped and built from what the site then holds.
How specific does the statement need to be?
Specific enough to check. It names what the use case does, who approves before results land anywhere, which systems it reaches, and who will be able to change it afterward. A sentence or a short paragraph is usually enough.

KEEP READING

Related.