Definition of Done
The definition of “Done” is a shared understanding by everyone in the Scrum Team of when an item is “Done” and has a potentially releasable state.
The intention is that the outcome of each Sprint is a potentially releasable Increment that can be added to the previous Increments, which work together. The definition of “Done” helps Scrum Teams to determine if an item is actually “Done” to meet this intention.
If the Definition of “Done” is part of the standards or guidelines of an organisation, then the expectation is that the Scrum Teams will follow it as a minimum.
If no such standards or guidelines exist then the expectation is that the Development Team would create their own Definition of “Done” that is appropriate to their work, capability and environment etc. Over the time the definition of “Done” may be reviewed and enhanced to become more comprehensive and enhance the quality levels of items as the team becomes more proficient and confident.
If working with multiple teams on a single product, then all teams are expected to mutually define and apply their Definition of “Done”.
Practical Tips
| Team Agreement | Drafting a team agreement with their definition of what “Done” is can help to explicitly describe what “Done” really means. Making this visible in the team area can help as a reminder and a reference point. |
| Expanding the DoD | Continually considering the definition of “Done” and challenging what is possible within the context of a Sprint can help a team to increase their confidence and strive towards good product development skills |
| Automation | Investing in automating repetitive processes can help to relieve the amount of manual effort within a Sprint, which then allows for time to expand the definition of “Done”.
Examples include automating the regression testing efforts, using deployment scripts, setting up build agents within a continuous integration / delivery ecosystem |
| Newbie | For a team just starting out with Agile and Scrum it can help to initially start with a modest definition of “Done” to help them establish a rhythm and build confidence. However, soon afterwards it is then recommended to begin to expand this definition to become more comprehensive before too many Increments are built. |
| Veterans | For a seasoned team it can help build their confidence to challenge the definition of “Done” and the team’s capabilities to expand the definition to become more comprehensive and repeatable, with ever more automation and strive towards a continuous delivery state.
For a seasoned team that consistently rests with a mediocre definition of “Done” this can lead to stagnation, ambivalence and zombie Sprints. So keep them alive and active. |
| Undone Work | Using weak definitions of “Done” for extended periods of time implies that work that is not expected to be finished within a Sprint for the Increment such as non-functional testing or support documentation for example, will still be outstanding when a release is due.
This can present a “shock” to the team when it is realised that all of the undone work that was not in the definition of “Done” still needs to be done in order to make a release. Hence, expanding the definition of “Done” reduces the amount of undone work that is stacking up for the release. |
| Unfinished Items | If items are not finished within a Sprint and are carried over to the following Sprint. This may be due to a team not understanding or respecting their exhibited capacity.
This can be a result of working with large items rather than small items that are more easily consumed, working as a group of independents rather than rallying as a team, or assigning items to individuals rather than treating them as a team objectives. Consistently carrying over unfinished items to the next Sprint removes the team’s ability to inspect the Increment and be transparent about the work. |