What is the Definition of Done
A Scrum Team must decide on and document its DoD
The Definition of Done (DoD) is a clear and concise list of requirements Stories must meet to be “done” (i.e., ready for Sprint Review). The Product Owner and the Development Team come to an agreement on that list of requirements and document it in their DoD. The Scrum Master facilitates the process but does not vote on the DoD.
When a Story is completed, the Scrum Master validates that the Story has met DoD before it is presented to the Product Owner. The Product Owner has the authority to accept or reject a completed Story and uses the DoD to make that determination.
The DoD will vary from Development Team to Development Team. The final DoD for a Scrum Team should be posted and used to determine acceptance of a completed Story. If multiple Scrum Teams work on the same product, then all Teams should mutually create the DoD.
It is important that everyone have the same understanding of DoD:
“Done” is not enough—done is different to different individuals.
DoD is what makes a Story ready for Sprint Review.
Scrum Team (Development Team and Product Owner) decide on DoD. The Scrum Master facilitates the process but does not vote on DoD. It is the Scrum Master’s duty to validate with the Development Team upon Story completion that the Story has met DoD before presenting it to the Product Owner. The Product Owner will use the DoD to determine if a completed Story is accepted or rejected. The Product Owner has the authority to accept or reject a completed Story.
Common Criteria of Definition of Done
- Development is complete.
- Code review is complete.
- All testing has been successfully completed and any defects have been addressed or added as new stories in the Backlog.
- User story has been accepted by the Product Owner.
Steps to create Definition of Done
This is one way to create a Definition of Done. The important thing is to think through what done means and for the Team to come to an agreement.
Suggested steps to create the Definition of Done:
- Brainstorm: Write down everything essential for delivering on a feature, Iteration/Sprint, and Release; for example, code is complete and checked in, Product Owner signoff, and updated release notes might all be essential pieces of delivering on a feature. Write one item per sticky note. As you brainstorm, think about what it means for that feature to be shippable to ensure that you catch everything that is essential for delivery. Think also about each of the different roles—done for a tester might bring up different items than done for a developer.
2. Identify items that can’t be checked every Iteration or Sprint: Look at each of the items on the sticky notes and identify whether or not they can be done at every Iteration/Sprint for each feature being delivered. If they can’t be, remove them from your Definition of Done.
3. Capture impediments: For each item that cannot be checked every Iteration or Sprint, discuss the obstacles that keep the Team from delivering this each Iteration or Sprint deliverable. Frequently, these obstacles create issues such as having an unpredictable release period after the last feature is added. Even if the obstacles can’t be removed right away, over time, they can be removed and the item can be included in the Team’s Definition of Done.
4. Commitment: Get a consensus on the Definition of Done. Go through each item that is completed each Iteration or Sprint.
Difference between DOD and Acceptance Criteria
Acceptance Criteria describes the correct behavior of functionality, proving it works. Acceptance Criteria emerge during conversations with the Product Owner and Stakeholders and apply to only one Story. Because the Product Owner owns the User Story, the Product Owner has the final say on the Acceptance Criteria.
That’s great for the User Stories, but how do we know we’re really done? That’s where the Definition of Done (DoD) comes in. DoD is created prior to the first Sprint. It describes the minimum software quality standard and should eventually represent a Releasable Increment standard. DoD applies to all Stories and is continuously improved over time and during the Sprint Retrospective.
Definition of Done
Describes a minimum software quality standard.
Applies to all Stories.
Decided/created by the Scrum Team. Created prior to Sprint 1.
Should eventually represent a “Releasable Increment” standard.
Continuously improved over time and during Sprint Retrospective
Acceptance Criteria
Describes correct behavior of functionality—proving it works.
Applies to only one Story.
The product Owner has the final say.
Created during refinement sessions.
Definition of Done is a Commitment of Product Increment
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
For more posts like this follow Agile Digest social Pages or subscribe our newsletter:
Wesbite: https://agiledigest.com/
Facebook: https://www.facebook.com/agiledigest/
LinkedIn : https://www.linkedin.com/company/agiledigest/
Youtube: https://www.youtube.com/@AgileDigest
