What is Definition of Done?
The definition of done is an agreement within the team about what "finished" means. It is not the same as acceptance criteria, which are specific to individual stories. The DoD applies to every piece of work the team delivers.
A typical DoD includes items like: code is reviewed and merged, unit tests pass, the feature works in staging, documentation is updated, and the change is deployable. Some teams add items like accessibility checks, performance benchmarks, or security reviews.
The DoD is a quality gate. Without it, different team members have different ideas about what "done" means. One developer might consider a feature done when the code compiles. Another might wait until it is tested in production. The DoD eliminates that ambiguity.
Why It Matters for Product Teams
A weak DoD leads to technical debt and user disappointment. Features get marked as complete but still have rough edges. Users encounter bugs that should have been caught. The team spends future sprints fixing yesterday's "done" work.
For features that originated from user feedback, the DoD should include a step that verifies the original user need is met. It is possible to ship a feature that meets all technical criteria but fails to solve the problem users described. Checking back against the original request prevents this.
The DoD also protects the team from external pressure to cut corners. When stakeholders push for faster delivery, the DoD gives the team a clear standard to point to.
How to Apply Definition of Done
Create the DoD as a team. Everyone who touches the work should agree on the criteria. Post it somewhere visible: a wiki page, a whiteboard, or the top of your project board.
Include a feedback verification step for user-requested features. Before marking a story as done, check whether it addresses the original feedback. If the feature was requested in your feedback tool, review the original request and confirm the solution matches.
Review and update the DoD regularly. As the team matures, the bar should rise. If you keep finding the same types of bugs in production, add a check for that scenario to the DoD.
Use the DoD during sprint reviews. When demonstrating completed work, walk through the DoD criteria to show stakeholders that quality standards were met. This builds trust and reduces second-guessing.