Definition of Done
What is a Definition of Done?
A Definition of Done is a checklist of activities that add value to the product which must be fully completed before a member of the team can refer to a user story as "done.". Definition of Done is a pre-release checklist. DoD is a checklist of features and activities, for example, writing code, coding comments, unit testing, integration testing, release notes, design documents, etc. that adds or demonstrates value to the product. Focusing on value-added steps allows the team to focus on what must be completed in order to build working software while eliminating wasteful activities that only complicate software development efforts.
According to Scrum Alliance, there are three main types:
Definition of Done for a feature ( user story or product backlog item)
Definition of Done for a sprint (collection of features developed within a sprint)
Definition of Done for a release (potentially shippable state)
Definition of Done checklist for User Story
This is the first and the most basic level is a User Story, where we check compliance with the initial assumptions of a single backlog item, which were described in it. On this stage we also control the quality of written code and check if all necessary elements of our process were carried out, for example:
Produced code for presumed functionalities
Assumptions of User Story met
The project builds without errors
Unit tests are written and passing
The project deployed on the test environment identical to the production platform
Tests on devices/browsers listed in the project assumptions passed
Feature ok-ed by UX designer
QA performed & issues resolved
The feature is tested against acceptance criteria
Feature ok-ed by Product Owner
Refactoring completed
Any configuration or build changes documented
Documentation updated
Peer Code Review performed
Definition of Done checklist for User Story
This is the first and the most basic level is a User Story, where we check compliance with the initial assumptions of a single backlog item, which were described in it. On this stage we also control the quality of written code and check if all necessary elements of our process were carried out, for example:
Produced code for presumed functionalities
Assumptions of User Story met
The project builds without errors
Unit tests are written and passing
The project deployed on the test environment identical to the production platform
Tests on devices/browsers listed in the project assumptions passed
Feature ok-ed by UX designer
QA performed & issues resolved
The feature is tested against acceptance criteria
Feature ok-ed by Product Owner
Refactoring completed
Any configuration or build changes documented
Documentation updated
Peer Code Review performed
FAQ’s On DoD – Definition Of "Done"
1. Do we need everything as a part of DoD?
It depends on the nature of the business that the Product is dealing with.
2. Do we need to have all these parameters from the first Sprint?
Since the product evolves over a period and so do the requirements, it can’t be definitive whether we need all the parameters from Sprint 1. Initially, the team starts with the lean DoD and evolves along with the product and is a more learned approach.
3. Where do we need to have the DoD? Is it at the Product Level/Sprint Level/Story Level?
Because it is the product that gets released to the market, the DoD is always at the Product level.
Meanwhile, since we are working with Sprints, every Sprint must create a releasable Increment of Product and this means that the DoD needs to be met every Sprint to make the Product releasable. The user stories are part of your Sprint deliverables, so to make every story releasable (functional releases) as part of the Product, it must meet the DoD of the Product.
If multiple Scrum teams are working on the same product, then there are chances of each Scrum team having their own DoD. However, the integrated work of all the Scrum Teams put together must meet the DoD of the Product, which means their combined/integrated work must be releasable.
4. How does DoD help in increasing transparency within the Scrum Team?
DoD is a shared understanding with-in the Scrum team on what "Done" increment of Product means and this increases (raises) transparency in the team.
Whereas, if we consider the DoD as a plain checklist for the development team to complete their work, this might end up being a mere checklist document for the sake of having it and this type of DoD hardly evolve or refine which results in low confidence with-in the Scrum team to declare a Product as DONE/RELEASABLE and this also make Increment of low quality and non-releasable with pile-up of UNDONE work.
5. What is the impact if the Definition of "Done" (DoD) is not defined?
There is no transparency if a Product increment is releasable, impact on estimations or unrealistic estimates, inaccurate forecast on Sprint work, difficult for the Product Owner to understand the progress on the Product, inefficient inspection and adaptation at Sprint Review
6. What is UNDONE in context with DoD?
Any work mentioned in the DOD that is required to create a releasable increment; however is not completed is referred to as UNDONE.
7. What is the difference between shippable and releasable Increment of the Product?
Shippable refers to some undone work (mostly related to approvals) which eventually stops the Product Increment release into the market. Therefore, Shippable is like Almost "Done", which can be referred to as Definition of Almost Done (DoAD). In simpler words, it could be understood as, when we are "Done" with the work, whereas the approval is pending from User Acceptance Testing (UAT)/Compliance/Legal/ because of any pending documentation.
In this kind of a scenario, your Product is not releasable, but the team refers to this as shippable, popularly known as "Done" (Shippable) "Done" (Releasable). Whenever we ask, is your work “Done” or “Done Done”, the first one is referred to as Shippable and the later one is referred to as Releasable.