Definition of Done – User Stories
The “Definition of Done” is a fairly popular (and sometimes emotional) topic out in the Agileverse. It seems everyone has an opinion on the matter, ranging from “it depends” to “let the teams decide” to a meticulously designed set of business rules and criteria that account for every possible scenario. And as more organizations adopt Agile practices (and, specifically, Scrum), they seek to leverage guidance on this topic from those who have already blazed the trail.
Why is this such a complex topic? One reason is that the word “done” is overused. We must distinguish between different contexts of “done,” which can be applied at the story level, epic level, release level, product level, and so on. In each case, the meaning of “done” has different criteria. For the purposes of this article, we are only going to look at the “done criteria” for a Product Backlog Item (aka PBI or User Story).
Another aspect of the problem with done is perspective. The word “done” is often used to mean “complete” as in the Development Team saying: “We are done with this story.” It is also used to indicate “acceptance” as in the Product Owner saying “This story is done.” I typically teach and coach it this way: Don’t say “done.” Instead, use “complete” and “accepted” for more specific indications of status.
Thus, we define two aspects of the Definition of Done – Completion Criteria and Acceptance Criteria:
The Completion Criteria are summarized as follows:
- “Code Complete” – as defined by the organization/teams
- “Unit Tested” – as defined by the organization/teams
- “Peer Reviewed” – as defined by the organization/teams
- “QA Complete” – as defined by the organization/teams
- Documented (As needed; determined by the Scrum Team through tasking at beginning of Sprint)
The Development Team determines when the Completion Criteria have been met with the guidance of the ScrumMaster. At that point, the story is considered “complete.”
The Acceptance Criteria can be summarized as follows:
- The list of expectations for a specific Product Backlog Item as defined by the Product Owner prior to the beginning of a Sprint
- The Product Owner may initially define these alone but eventually enlists the help of the Development Team and ScrumMaster
- For cases where Acceptance Criteria are not clear, a Spike User Story will be used to define the problem and Acceptance Criteria for a Product Backlog Item to be completed in a future Sprint
- The entire Scrum Team must agree to these Acceptance Criteria by the end of the Sprint Planning meeting
- Minor changes to the Acceptance Criteria once the Sprint is underway as long as there is formal agreement between the Development Team, ScrumMaster, and Product Owner
- When the Development Team believes these Acceptance Criteria have been met, the Product Backlog Item is ready for a Product Owner review (Demo), which occurs throughout the Sprint
- The review (Demo) of each PBI should not be left until the very end of the Sprint
The Product Owner officially determines when these Acceptance Criteria have been met. At that point, the User Story is considered “accepted.”
This approach provides a framework that is modular and can be adaptable around the definitions of “Code Complete”, etc., but clearly delineates the roles and responsibilities associated with delivering and finalizing work on features.
If a particular organization is striving toward 100% automation of functional tests that become part of a holistic regression test suite, then “creating automated test scripts” would be expressed in the “QA Complete” criteria.
Further, one group might agree on what “peer reviewed” means but not the “QA complete” criteria. Using this modular definition, each group can customize these definitions to suit their team’s specifications.
As part of this exercise of defining “Done” I have also identified the different stages at which events occur in terms of the Definition of Done:
The first column defines the Scrum Activity during which the action item in Column 2 takes place. Column 3 identifies which role(s) are chiefly responsible for the action item.
On many of the teams I have coached, where there was a highly contentious relationship between the Product Owner and Development Team, this diagram has helped to sort through who was responsible for what and when. This, along with a well-defined definition of “Done”, set expectations and the conflict was neutralized.
Each organization (and team) must come to consensus on what the “Definition of Done” means for their particular projects/products at various levels (story, sprint, release, etc.). In the next installment of this series, I will explore what the “Definition of Done” means at the Sprint level.