The Definition of Done (DoD) is a list of criteria that must be completed for a product backlog item (PBI) before it can be considered complete within a sprint.
The initial DoD is created by the development team at the start of a project, often in sprint zero. When multiple scrum teams are working on the same product backlog they must collaborate to agree a mutual DoD. It is critical that the DoD remains clearly owned by the development team; it cannot be changed by anyone else.
The DoD should be reviewed and expanded by the development team throughout the project in order to raise the quality bar. It should be possible to include wider activities into the DoD over time as organizational support improves and the ability of the team increases.
Note that the DoD cannot be changed during a sprint for any reason, additionally all work must be assessed against it. In the sprint review any work rejected or causing rework should be identified and subsequently analysed within the retrospective to ensure the relevance and completeness of the DoD.
The purpose of the DoD is to:
- Provide a common understanding of completed work to both the team and the stakeholders thus reducing the risk of misunderstanding and conflict
- Drive up the quality of work produced and ensure that quality level is visible
- Provide an auditable checklist within the team and for QA
- Ensure that technical debt does not build up on the project
- Verify that integration and stabilisation activities are performed iteratively
- Guide pre-coding activities (such as backlog refinement) to ensure all criteria can be met
- Allow the team to focus on development whilst eliminating wasteful activities
Note that teams often need multiple DoD for stories, sprints, releases etc.
The Scrum Guide (2013) includes the definitive description for the definition of done.
It is common to see some of the following issues when coaching scrum teams:
- Teams typically create an unrealistic DoD which prevents initial sprints from being successful and slows down the improvement cycle
- Spending too much time producing the DoD and then striving to achieve it can be counter-productive. The focus should be to complete the minimum amount of work in order to complete a PBI
- The DoD is generic whereas individual stories often require additional done criteria. Although it is usual to have acceptance criteria defined for each PBI, the DoD can mask this work
- The DoD as a shared understanding must be explicit and displayed prominently on the wall (or task board). The DoD is less effective unless the contract is visible and prominent
- ‘Done-Done’ – Some teams use multiple levels of done such as done with development followed by done with testing giving a ‘done-done’ state. I am unsure where this stops when additional steps are added – Done-Done-Done-Done-Done? I am really not keen on this approach, the definition of done should take the PBI to a potentially deployable state, i.e. ‘done is done’
It is a good idea to check that the team can point to it’s DoD and that the team uses it to justify if a PBI is to be included in the velocity at the end of a sprint.
Agile teams generally exist in one of five states with respect to the DoD (unfortunately not often in the last state):
- No DoD exists for the team
- A DoD has been created but is not generally used
- The team often fails to meet it’s DoD
- Although a DoD exists and is met for each PBI, there still remains work to be completed for each release
- A DoD exists, is met and includes all required work to deliver a PBI “from concept to cash” (Poppendieck).
The Definition of Done will vary from team to team and also by product, project, technology or domain. The criteria are often created by the team within an initial brainstorming session followed by a meeting to order, prioritise and vote on the content.
The following elements are often included in the DoD for a PBI (often a user story):
- Design has passed review
- Code is version controlled
- Code builds without warnings or errors
- Code has been refactored
- Code meets standards
- Code has passed review
- Code has passed static analysis
- Acceptance criteria met
- Zero new defects
- Regression tests pass
- Unit test code coverage = x%
- Automated functional tests for the the PBI pass
- Integration testing passed
- System level performance testing passes
- Platform and localisation testing passes
- Technical documentation updated
- Help file generated
- User documentation updated
History of the Definition of Done
- In 2002 Bill Wake wrote an article on coaching skills and exercises that included the term ‘done’ along with questions corresponding to it
- In 2003 a slide title in Scrum training materials was ‘The story of Done’
- In 2005 Scrum training materials got attendees to create a ‘definition of done’
- By 2007 the Definition of Done was in widespread use as a standard Scrum practice
So that’s it for this week, I hope you found something interesting within the post so that it included some value for you. Please post a comment as I would love to hear what you thought. The next item on my backlog is Sprint durations so see you next week.