Why Your Definition of Done Is Probably Too Vague

I ask every new team I work with to show me their Definition of Done. Most of the time it looks like this: "Code reviewed, tested, deployed to staging." That is not a Definition of Done. That is a wish list.

A real Definition of Done is specific enough that two people could independently look at a piece of work and agree on whether it is done or not. "Tested" means nothing. Tested how? Unit tests with what coverage threshold? Integration tests against which scenarios? Manual QA by whom?

The Cost of Vagueness

When your DoD is vague, every story carries hidden work. The developer thinks "done" means code complete. The QA engineer thinks it means tested. The PM thinks it means deployed and verified by the Product Owner. These misaligned expectations surface during sprint review when someone asks "is this actually done?" and the answer is complicated.

Over time, this erodes trust. Stakeholders stop believing the team when they say something is complete. The team starts padding estimates to account for the ambiguity. Everyone is working harder than they need to because the ground rules are unclear.

How to Fix It

Sit down with the team and write out every step between "development started" and "this is in production and we are confident it works." Include code review, specific testing requirements, documentation updates, accessibility checks, deployment verification, and Product Owner acceptance.

Then make it visible. Print it out. Put it on the team wiki. Reference it during sprint planning when discussing whether something can fit in the sprint.

Review the DoD quarterly. As the team matures, the DoD should get more rigorous. Add performance testing, security scans, monitoring alerts. Each addition raises the quality bar.

A specific Definition of Done is one of the highest-leverage process investments a team can make. It costs one meeting to create and pays dividends every sprint.