Picture the scene.
It's the end of a sprint. The developer closes the ticket. Someone marks it done. There is a small, collective exhale around the team. Progress! Victory! The thing is finished!
Except.
The QA person opens it the next day and finds three edge cases nobody tested. The stakeholder sees the demo and says "oh, I thought it would also do X." The user tries it in production and it breaks on mobile.
Was it done?
Technically, in the sense that someone moved a card across a board — sure. Actually done? Not even close. And this, my little product fiends, is the gap that the Definition of Done exists to close 💀.
🤔 What Is the Definition of Done?
The Definition of Done (DoD, because we love an acronym) is a shared, explicit agreement between your team about what "done" actually means for a piece of work.
Not what you think done means. Not what the developer thinks done means. Not what the stakeholder who commissioned the work thinks done means.
What the team — collectively, with all its members' hats on — has agreed done means.
This sounds obvious. It is, in practice, startlingly rare.
In the absence of a Definition of Done, every person on the team is operating from their own internal definition. And those definitions, I promise you, are not the same. The developer thinks done means the code is written and the tests pass. The designer thinks done means it looks right. QA thinks done means it's been tested in all the edge cases. The PM thinks done means it's shipped and users can access it. The stakeholder thinks done means it does the thing they imagined, which they now realise they didn't fully explain at the start.
All of these are valid. None of them alone are sufficient. The DoD puts them in the same room and makes them shake hands.
📋 What Goes in a Definition of Done?
This varies by team, by product, and by type of work — but here are the things I'd expect to see in a healthy one:
✅ Code complete — it's written, reviewed, and merged.
🧪 Tests written and passing — unit tests, integration tests, whatever your standard is. Define it.
🎨 Design signed off — does it match the spec? Has the designer looked at it?
♿ Accessibility checked — is it usable by the people who need it?
📱 Cross-browser / cross-device tested — yes, even mobile. Especially mobile.
🚀 Deployed to staging — it works somewhere other than a developer's laptop.
📝 Documentation updated — if it changes how something works, the documentation knows about it.
👀 Accepted by the Product Owner — someone with the authority to say "yes, this is what we asked for" has looked at it and agreed.
Your list might be shorter. It might be longer. What matters is that your team wrote it together and everyone refers to it.
🌱 Definition of Done vs Definition of Ready
Bonus content, because you stayed till the end and you deserve it.
The Definition of Done has a sibling: the Definition of Ready. Where DoD tells you when work is finished, DoR tells you when a piece of work is ready to start.
Think of it like a recipe. The Definition of Ready is your mise en place — everything chopped, measured, and on the counter before you start cooking. The Definition of Done is the moment you plate up and declare it a meal.
A Definition of Ready might include things like: the user story is written; acceptance criteria are defined; design is complete; dependencies are identified; the team has estimated it.
If a ticket doesn't meet the DoR, it shouldn't go into a sprint. Full stop. Pulling half-prepared work into a sprint is how you end up with a sprint full of "almost done" tickets and a retrospective full of sighs.
👷 Making It Stick
Definitions of Done only work if they're alive. A DoD written once, posted somewhere, and never looked at again is a decorative object, not a working agreement.
Revisit it in retrospectives. If something keeps slipping through that your DoD didn't catch, add it. If something in the DoD no longer reflects how you work, remove it. It should be a living document, not a compliance checkbox.
And — this is the bit that gets uncomfortable — use it. When someone says "it's done," ask: does it meet the Definition of Done? All of it? Not to be difficult, but to be honest.
Because the kindest thing you can do for your team is give them a shared standard to work to, and then hold that standard. Consistently. For everyone.
🧟♀️ From the Monster's Notebook
Done is not a feeling. It is an agreement.
The feeling is lovely — that little exhale at the end of a sprint or at release, the satisfaction of watching a card move across the board. I am not suggesting you abolish it. By all means, exhale. Move the card. Celebrate.
Just make sure, before you do, that you and your team mean the same thing when you say the thing is finished.
Because the only thing scarier than unfinished work is work that thinks it's finished 👻.
Until next time, my product fiends 💀.
