What does done mean? Definition of Done in practice
Definition of Done is a shared, written list of what's required for something to count as done – not just that the code exists, but that it's tested, documented, and deployed. For a client, it's protection against half-finished delivery, since it ties the word done to concrete criteria agreed on in advance.
“Is it done?” “Yes, it’s done.” Two weeks later it turns out the feature was never properly tested, lacks documentation, and isn’t even deployed for users. The word done is the most abused word in the project world, because it means different things to different people. The solution is a shared Definition of Done: a written agreement on what’s actually required before something can be called finished.
What a Definition of Done includes
A Definition of Done is a list of criteria that apply equally to everything that gets built. It captures the uncomfortable truth that code isn’t done just because it exists and seems to work. Around the build itself sits a tail of work that otherwise gets silently pushed into the future.
A reasonable example of a Definition of Done might include:
- The feature meets its acceptance criteria. It does what it was supposed to do.
- The code has been reviewed. At least one other developer has read and approved it.
- Tests exist and pass. The feature is tested, and the tests run automatically.
- Documentation is up to date. The next person understands how it fits together.
- Deployed to the right environment. The code lives where it should, not just on a developer’s machine.
- No known serious defects remain. What’s left is actually usable.
The list doesn’t need to be long, but it should be shared and written down. The point is that everyone – developers, testers, and you as the client – means the same thing when the word done gets used.
Why “the code works” isn’t enough
Imagine you’ve ordered a new kitchen. The carpenter says it’s done. You arrive and the cabinets are hanging in place – but the appliances aren’t wired up, the handles are missing, and no one has cleaned up after themselves. Does the kitchen work? Partly. Is it done? No.
Digital development is the same. A feature that lives on a developer’s machine but lacks tests, documentation, and deployment is the kitchen without wired-up appliances. It looks finished in a demo but carries hidden remaining work that sooner or later lands in your lap – often as an unexpected cost or a bug in production. Definition of Done forces that work out before something counts as done, instead of after.
A concrete example
Say the team is delivering a login flow with BankID. Without a Definition of Done, it gets demoed in a meeting, looks good, and gets checked off as done. Three weeks later it’s discovered that it was only manually tested once, that error handling is weak when BankID responds slowly, and that no one documented how it should be deployed in the production environment.
With a Definition of Done in place, the feature can’t be checked off until it’s been reviewed, has automated tests covering slow BankID responses, is documented, and is actually deployed. The demo looks exactly the same – but what you get is finished all the way through, not just on the surface. The difference isn’t noticed that day; it’s noticed the week something else changes and the old feature doesn’t collapse along with it.
The link to contracts and invoices
Definition of Done is at its most powerful when it’s tied to what counts as an approved, and therefore billable, delivery. If payment happens against delivered parts, both parties need to know exactly what must be met before a part can be approved.
Without that agreement, every approval becomes a negotiation over opinions, often just as irritation is starting to rise. With it, approval becomes a check against a list everyone agreed on while the mood was good. It protects both sides: you avoid paying for half-finished work, and the vendor avoids endless disputes over what was actually included.
Raise the question early, then, while everyone’s still on good terms, and write it into the contract or the way of working. Defining done after the fact, once a delivery is already in question, is considerably harder.
At Weapp we work with clear criteria for what counts as finished, precisely to avoid those disputes. Want that clarity in your project? Read about our services or get in touch with a short description of what you want to build.
Frequently asked questions
What is Definition of Done?
Definition of Done is an agreed list of criteria that must be met for a task to count as finished. It captures the fact that code isn't done just because it exists – it should be tested, reviewed, documented, and deployed. The list applies equally to all tasks and is created jointly before work begins.
Why isn't it enough that the code works?
Because a feature that works on the developer's machine but lacks tests, documentation, or deployment isn't done in practice. It can break at the next change, no one knows how to maintain it, and it may not even be available to users. Definition of Done captures all the work that would otherwise be silently pushed into the future.
How do I negotiate Definition of Done into a contract?
Raise it before work begins and tie it to what counts as an approved delivery. It can be written into the contract or into the shared way of working. The point is for both parties to agree on what done means while everyone's still on good terms – not to try to define it after the fact once a delivery is already in question.
Is Definition of Done linked to invoicing?
Yes. If payment is tied to delivered and approved parts, Definition of Done becomes the yardstick for what can be approved. Without it, approval turns into a negotiation over opinions. With it, both parties know in advance exactly what needs to be in place before a delivery counts – and can therefore be invoiced.
Does Definition of Done differ from acceptance criteria?
Yes. Definition of Done is general and applies equally to all tasks – tested, reviewed, deployed. Acceptance criteria are specific to a single feature and describe exactly what it should do. They complement each other: acceptance criteria say what should be built, Definition of Done says what quality level everything must reach.