Four factors in a Definition of Done.
A continuous flow of work involved taking backlog items through to being completed. We track progress by an Earned Value approach which only measures work which has been completed. This means that we need to be very clear about what “completed” really means.
Central to achieving a good level of quality is ensuring that every team has a common understanding of what completion means. All too often a work item is marked as completed, but when it comes to be time to deliver the item it is discovered that more work is needed. Agile development often refers to the completion of work items as “Done”. In this Play we look at what “Done” really means.
What is a Definition of Done?
Each work item will have a set of specific tests to ensure that the work has been completed without error. These are defined as part of creating an individual backlog item. I would refer to these as “Acceptance Tests”. Agreeing the specific acceptance tests is part of the “Definition of Ready” for each backlog item.
This is not what we mean by a Definition of Done.
The Definition of Done is the overall set of what has to be completed for all work items. Successful completion of acceptance tests for every backlog item would likely be part of the Definition of Done. The specific tests for an individual item would not be.
We have probably all seen times when the team have work marked as Done, but when asked to deliver it announce that there is something still to complete. That suggests that the work was not truly complete and that the team were unaware it was not complete. Possibly they were aware, but unwilling to say, which is more a question about psychological safety than Definition of Done.
At a top level, “Done” should always mean “able to be delivered to the customer with no more work on the specific item”. A team should be comfortable that if they have marked an item as “Done” they should be able to ship it immediately.
A side effect of a weak Definition of Done is frequently observed in scaling organizations. This is the reliance on release testing. With a strong quality culture the code should always be releasable. All backlog items are well tested. The Definition of Done ensures that the product is always in a releasable state after each backlog item. This is referred to as “building in quality” or sometimes “left shifting”.
The alternative is to spend time verifying each release. This is necessary when an organization does not have confidence in the quality of individual backlog items. This means that extensive testing is needed at
Typically a Definition of Done will include four factors.
Code completion
This is the obvious part. The functionality which is specified in the backlog item has been created. The code is written and committed to the code repository. This needs a level of peer review to agree the quality and functionality and ensure it is architecturally compatible.
Functional verification
The functionality has been demonstrated to be correct. This will typically involve completing the acceptance tests specified in the backlog item. It may also include further testing, especially tests targeted at failure modes which may not be included in the acceptance tests. For example, how the code responds to incorrect data.
Regression testing
The new code has been integrated into the product and does not negatively affect existing functionality. This is typically shown through regression testing. We build the product with the new functionality added and run a set of automated tests to test existing functionality is unaffected.
This step also requires that the regression testing suite has been updated with tests to test the new functionality. These can then be used to test the new functionality is not modified by future changes.
Productisation
If we are to be able to deliver the backlog item once it is Done, we need to include productisation in the Definition of Done. What needs to be completed beyond the code itself? We clearly need to be able to build the new code into the product. And we need to be able to deploy the product to the customer. We need to have updated documentation, both customer facing and internal. We need to have ensured compliance with any required standards or APIs.
Good practices
Avoid deferring work and testing to the release point. This is slow and unreliable. Releases are complex and time consuming which leads to many problems making a reliable release.
The exact elements of a Definition of Done will vary between products and teams. However, you should ensure that every team has considered their own DoD. Having agreed what this needs to contain, make sure every team member is aware of it. Teams will generally “own” their own Definition of Done, which may differ slightly from other teams.
Teams should be aware of the importance of building in quality rather than using extensive testing to “add” quality after the coding.
Leave a Reply