What’s actually happening
Developers and PMs use the same word done...
but they mean completely different things.
Let’s step into the developer’s shoes for a moment.
You’re Steve, a front-end dev with 5 years of experience.
You pick up a new user story, spend hours debugging, finally get the code to work.
Tests pass. It’s merged. Victory. You close the story.
From your view, it’s done.
Now meet Ana, the PM.
She’s thinking about business value, user adoption, and compliance.
For her, done means the feature is in production, users are using it,
and no one is screaming in Teams.
So who’s right? Both.
They’re just playing different games.
How to bridge the gap
Instead of trying to “control” the process, align on what done means together.
Here’s a simple 3-step flow I’ve used:
1️⃣ Run a Definition of Done workshop
→ Bring devs, QA, and PMs together.
→ Ask: “What has to be true for us to call a story done?”
→ Write everything down. Expect debates... that’s the point.
→ End with a shared list everyone agrees on.
2️⃣ Pilot it for two sprints
→ Use it as a checklist for every story.
→ Let developers drive it the second sprint. Ownership matters.
→ Adjust as needed. The goal isn’t perfection, it’s shared understanding.
3️⃣ Give context beyond the code
→ Walk devs through the full software lifecycle: testing, change management, user feedback.
→ Let them see how their “done” work performs in production.
→ Show the real impact... both good and bad. Nothing motivates more.
My team’s Definition of Done (example)
Here’s what ours looks like right now:
→ Code created
→ Unit tested
→ Code reviewed
→ Merged to main
→ Technical documentation updated
→ Deployed to test environment
→ Functionally tested and accepted
→ Security and performance verified
→ Regressions checked for dependent products
→ Bugs fixed and retested
We don’t include UAT or release because we operate in a regulated environment and release on a fixed cadence, about once a month.
If your team releases every sprint, include those steps too.
There’s no one-size-fits-all version of done.
But agreeing on one is half the battle.
Why this matters more than you think
I used to struggle with delegation.
Whenever a dev said something was “done,” I’d go and check myself.
I didn’t want to seem like a control freak... but I also didn’t trust that the process was followed.
It drained my time and theirs.
Creating our Definition of Done changed that.
It became my delegation power tool.
Because now, instead of me chasing them with questions,
they own the quality level they agreed to.
It’s not me checking... it’s them delivering to a standard they helped define.
That shift changed everything.
Less tension. More ownership.
And a team that genuinely cares about the quality of what they ship.
Takeaway
Next time a dev says “done,”
ask: “Have you run it against the Definition of Done checklist?”
That one question can save you endless rework...
and rebuild trust in your team.
Resource
Want to fix this problem once and for all?
I created a Definition of Done Workshop Template you can run with your team.
It walks you through exactly how to align PMs, developers, and QA step by step...
and helps you co-create your own shared definition of done.
It includes:
→ Workshop flow and questions
→ Ready-to-copy DoD checklist
→ Tips to make it stick across sprints
👉 Get the Notion Template
