The Importance of Sharing the Same ‘Definition of Done’
Those performing the work and those inspecting the resulting increment must share a common definition of “Done”. — The Scrum Guide
Although this may vary significantly for every Scrum Team, members must have a shared understanding of what it means for work to be completed and to ensure transparency. This is the definition of ‘Done’ for the Scrum Team and it is used to assess when work is complete on the product Increment
Transparency
Scrum requires participants to develop a shared understanding of the process. This is called Transparency. And for a team to function well its work principles must be aligned.
Having transparency over “Done” also provides the benefit that the level of quality attained becomes clear, and so does it provide a good indicator of a team’s capabilities and its dependencies.
“A shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team. “ — Scrum Glossary
The definitions of “Done” generally refer to the Product Increment. Criteria that only apply to a single Product Backlog item are generally referred to as test descriptions. An example of a definition of “Done” is that a Product Backlog item should pass all tests according to its test descriptions.
It wouldn’t be an exaggeration in telling that everything in this universe that is meant for delivery will have DoD. Let us take a look at the below questions.
- What does it take for the Rocket to launch?
- What does it take for the service engineer to call the customer for the delivery of his/her vehicle?
- What does it take for a Doctor to say ‘The Surgery is a Success?’
- What does it take for the Development team to put the Product into Production?
and many more questions that come across in our day to day lives.
Specifically, when we talk about Product Development (considering the system/software/solution), the DoD consists of 3 main components:
- Business or Functional requirements
- Quality
- Non-Functional Requirements
Why is it important to use a Definition of Done?
The main reason for using a definition of done is to ensure that all team members and stakeholders agree on what work needs to be completed before a story is considered shippable. In addition to this, there are a few more subtle advantages:
- Code is ready to be deployed to production at any time. Because the stakeholders and product owner can decide to deploy completed stories to production at any time, it is critical that all stories that are “done” are at a production-ready level of completeness. This is a shared responsibility of all the members of the Scrum team. The list of requirements ensures that everyone on the team has the same understanding of what needs to be completed before a user story or feature can be finished, and is ready to go to production.
- Minimizes last-minute delays. We have all had experiences of putting out a new release only to find that someone forgot to do a key step. The release is delayed so someone can frantically resolve the issue. Working quickly, the person may create further issues that need to be resolved before the new version can be released. These types of last-minute delays can be minimized if a good definition of done is being used on every single user story.
- The team understands how much work it is to truly complete a story. If everyone on the team understands all the moving parts that need to be completed, in order to call a story “done”, the team has a true understanding of where each story stands and where the product stands overall. This knowledge is also highly valuable when estimating the effort required to complete future stories.
- It is to ensure that you achieve a consistent, reliable level of fidelity of a product backlog item that you deliver
“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” — The Scrum Guide
You ‘bout done?!
So we covered that at the very least when the Product Increment is considered “Done”, the Product Increment
- Is potentially useful;
- Is in a useable condition;
- Is potentially releasable;
- Is inspectable;
- Is thoroughly tested;
- Supports empiricism at the end of the Sprint;
- Is not in conflict with product or organizational standards;
A definition of “Done” helps teams to
- stay real: realistic planning
- learn and adapt quickly
- create transparency between the team and stakeholders
- stimulate team alignment/unity/harmony
- stimulate improvement
- improve on earlier states
- improve quality (standards)
- safeguard that what works stays in working condition
Different definitions can apply to different types of work. In a software product “Done” could for example mean :
- that the code is clean,
- the code has been reviewed by at least one other person than the one who wrote it,
- unit tests pass,
- all test definitions pass,
- the interface complies with guidelines as per Style Guide
- release notes have been written, reviewed, and confirmed to be complete,
- it passes the performance-, security- and stress-tests
- it passes the build,
- it passes the user acceptance test where its functionality has been reviewed.
- its usage is being researched
- user satisfaction is being researched (UX)
- learnings through its development have been registered and shared, its complexities have been made transparent.
- the Scrum team had the opportunity to review and is still able to review
- stakeholders are able to review
“Great things are not done by impulse, but by a series of small things brought together.” — Vincent Van Gogh
FAQ’s On DoD — Definition Of “Done”
Do we need everything as a part of DoD?
It depends on the nature of the business that the Product is dealing with.
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.
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.
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 a pile-up of UNDONE work.
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
