The task has been finished (except it's not): meet Definition of Done (DoD)
"Almost done, but..."—and then weeks spent on squeezing out bugs, polishing, reworking, and updating documentation. Déjà vu, anyone? Without a clear definition of what is considered done, the team (most probably each member!) and the customer live in different worlds.
The Definition of Done (DoD) is a list of criteria by which a task is considered complete. Not just "the code has been written," but "the code is there, covered with tests, reviewed, deployed, and verified." That is, ready for use, no surprises. The Definition of Done is a critical part of transparency that aligns everyone and helps to avoid misunderstandings.
Why everything falls apart without DoD:
- Tasks are stuck in the "almost done" status
- Sprints are not closed, and the velocity is barely known
- The team believes that the feature is ready, but the customer never saw it
- The team is arguing about who should have done what
An example of a simple DoD:
- Code is written
- Unit tests are done
- Code review has been passed
- Uploaded to staging
- Checked by QA
- No critical bugs
- Documentation has been updated
How to implement DoD:
- Discuss DoD with the team (at a retro session or project start)
- Consider the specifics—for internal tools and production services, DoD may differ
- Record it in the project space (Confluence, Wiki, Notion) so that everyone can see and follow
The Definition of Done reminds me of the rules of a game. Without them, a project turns into a neverending football game: we run and kick, but no one knows how to score a goal.
