Definition of Done
2 min read
Most debates and disagreements on shipping are because the team lacks a shared “definition of done” (to borrow from the Agile world). If you ask a team of 10 people “how will we know this is ready to ship?” you may get 12 answers.
Engineers tend to look for objective measures of done (unit tests, perf benchmarks). PMs tend to look for speed and usage data. Designers look for “quality” or “delight”. Legal looks for risk below an acceptable threshold. In some perfect world, each of these is achieved simultaneously and on schedule. Sadly, we do not live on this world.
Having a definition of done, even if that is an arbitrary decision or opinion of a leader is important to establish before getting too deep into work. It isn't necessary to define it before any work starts but the longer it is left undefined the more the team members will independently create definitions of done that are unlikely to be aligned.
The definition of done can be changed while the product is being built but the more the line is moved, the more frustrated the team will become.