What is a definition of done, and why we write it on day one
A definition of done is a short list of checkable items that says when a job counts as finished. We write it on day one, because a project that never defines its end never ends. Each item is either done or not done. There is no 90 percent.
What is a definition of done?
A definition of done is a short list of checkable items that says when a piece of work counts as finished. Each item either holds or it does not. There is no room for interpretation. We keep a short entry on it in our glossary under definition of done. Here we explain why we care so much about it.
What does one look like?
It fits in a few lines and reads without any technical background. For a company website, ours typically looks like this:
- Done: 6 pages live, tested on phone and desktop.
- Done: Form submissions show up in the CRM and an email notification goes out.
- Done: Domain and server are in the client's account, all access handed over.
- Not done: Any one of the above is missing.
The last line is there on purpose. Two out of three is not done. That single sentence makes both sides look at the same thing.
Why write the definition of done on day one?
Because a project that never defines its end never ends. Without it, each side pictures a different finish line. The client assumes the form feeds the CRM. The team assumes an email is enough. Both believe they are right, and handover day turns into an argument.
Written on day one, the gap shows up before any work starts. It gets settled in minutes, on one page, not in the middle of the project.
A deadline also means nothing without it. "Delivered on the 15th" is an empty date if nobody wrote down what gets delivered. We set the end date on day one and deliver on that day. We can do that because we also write down, on day one, what we are delivering.
Why is "90 percent done" meaningless?
Because nobody knows what the 90 percent is of. In software the last stretch is usually the hardest: bugs, edge cases, going live, handover. Work that is "90 percent done" can sit there for weeks. So we do not use percentages. It is done or it is not, and status reports list which items are finished and when the rest will be.
How do you write a good one?
Keep it short, measurable and checkable by the client. The rules we follow:
- Checkable: every item answers the question "how do we verify this".
- Specific: not "a few pages" but "6 pages".
- Outcome, not task: not "build a form" but "submissions appear in the CRM".
- Includes handover: accounts, access and documents are part of done.
- Short: if it runs past a page, it has turned into a scope document.
What happens when something changes mid-project?
The definition of done is updated in writing and both sides approve it again. Change is normal. The trouble starts when it is not written down. Any added item comes with its effect on time and price on the same page, so nothing shows up on the invoice later.
The client checks the list, not us. We test every item ourselves, but you have the final word. Bug fixes are free for 30 days after handover, and the same list tells a bug apart from a new request.
You can see where this step sits in our process on how we work. If you are planning a website, what website cost depends on covers the budget side, and web design covers what we build. Comparing several offers? How to compare software quotes shows why the quote that defines "done" is worth more.
Is a definition of done the same as scope?
No. Scope says what will be built, and the definition of done says what will be checked. Scope says "contact form". The definition of done says "form submissions appear in the CRM and an email notification goes out". The two work together. Our quote is one page and covers the scope. The definition of done is signed straight after it, and that is the day work starts.
What does a definition of done look like for other kinds of work?
Each kind of work has its own finish line, but the rule is the same: write the outcome so the client can check it. The table below gives sample items.
| Type of work | Sample item | How you check it |
|---|---|---|
| Online shop | An order placed with a test card appears in the admin panel and the customer gets a confirmation email. | Place an order, then check the panel and your inbox. |
| Mobile app | The app is live in both stores and a test push notification reaches a phone that allowed notifications. | Install it from the store and wait for the notification. |
| Integration | A confirmed sale creates an invoice in the integrator's test environment and the status is written back to the order. | Open the test order and look at the invoice status. |
| Project takeover | The project installs from scratch on a new server by following the setup note. | Someone follows the note and gets it running. |
| Internal system | Three user roles exist and each role sees only the screens it is allowed to. | Log in with each role and check the screens. |
What mistakes do people make when writing one?
The most common mistake is writing the task instead of the outcome. "Build a form" is a task. "Submissions appear in the CRM" is an outcome, and only the outcome can be checked. Other mistakes we see often:
- Using adjectives: "modern", "user-friendly" and "fast" mean something different to everyone.
- Forgetting handover: the site works, but nobody knows who holds the domain, the server and the logins.
- Leaving content vague: if nobody writes down who supplies the text and images, and when, the timeline stalls on it.
- Making it too long: detail belongs in the scope. Outcomes belong in the definition of done.
How do you write technical items such as speed and SEO?
Name a measuring tool anyone can use and a threshold agreed in advance. Instead of "the site will be fast", write which pages, measured with which tool, must reach which value. Google's Core Web Vitals are a good shared language for page speed.
SEO works the same way. Instead of "SEO-friendly", list concrete checks: every page has its own title and description, a sitemap exists, and old addresses redirect to new ones. Rankings never go on the list, because the search engine decides them. We cover the checks that matter in what makes a website SEO-friendly.
How do you check it on handover day?
Go through the list item by item and try each one yourself. These are the steps on your side.
Handover day checks
- 01 Open the signed list Check against the definition of done you signed, not against what anyone says in a call.
- 02 Try every item Open the pages on your phone and computer, fill in the form, place the order. Do exactly what each item says.
- 03 Check your access Log in to the domain, server and code repository accounts with your own credentials.
- 04 Write down what failed For any item that does not hold, send a short note: what you expected and what you saw.
- 05 Sign off When every item holds, the work is done. The 30-day free bug-fix period starts that day.
Frequently asked questions
Who writes the definition of done?
We draft it, you read and correct it. Once both sides agree, it is signed and work starts.
Does it replace the contract?
No. The contract and quote cover commercial terms. The definition of done covers when the work counts as finished. They are used together.
What if one item fails?
Then the work is not done. We finish the missing item and tell you in writing where things stand.
What is the difference between a definition of done and acceptance criteria?
Acceptance criteria say when a single feature is accepted, while a definition of done says when the whole piece of work is finished. "Form submissions appear in the CRM" is an acceptance criterion. The definition of done gathers items like that together with handover and access in one list.
Is a definition of done only used in Scrum?
No. The term comes from Scrum and other agile methods, but any project with a clear outcome can use one. We use it on fixed-scope client projects, from a company website to an integration.
Who checks the definition of done?
The client does. We test every item on our side first, but you have the final word. The items are written so you can check them yourself, on your phone, without technical knowledge.
Do you write one for small jobs too?
Yes. For a small job it is two or three lines. It takes minutes to write and prevents arguments later.
What happens if a project starts without one?
Each side pictures a different finish line, and the gap usually shows up on handover day. The result is a project that drags on or extra charges nobody expected. Writing one straight away, even mid-project, removes most of that risk.