Definition of Done in Agile

The Definition of Done is an agreed set of criteria that must be completed before a user story can be considered complete or ‘done ‘. Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts.

The Scrum Guide states that:

“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.”

Done on this level means that the Product Owner has reviewed and accepted the user story. Once accepted, the “done” user story will?contribute to the team's velocity. Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity.

Benefits of the Agile Definition of Done

Implementing the Agile definition of done offers some key advantages:

• Transparency: The moment one starts working in a team, it is important to create a shared understanding around multiple things including what ‘Done’ means for the team. Everyone on the Scrum team has a clear understanding of what constitutes “done.” This eliminates confusion and potential clashes of opinion because there is a pre-defined set of rules for what the product should look like when complete.
• Learning: Continuous evaluation of each step following the DoD checklist enables thorough oversight before releasing a product to end users and acts as a security gate. It allows the team to focus on speed and delivery, encouraging self-driven innovation without hesitation.
• Iteration: Delivering features that can be implemented quickly with the appropriate levels of quality assurance and delivered to end users is another key agile principle. Quick learning and iteration also foster confidence within the product development teams to create innovation while maintaining quality assurance during delivery.
• Sizing and Planning: When the scrum team understands the expected amount of testing, documentation, and deployments involved with a backlog item, they have fewer uncertainties to consider when sizing backlog items. The team also will be aware of many of the tasks that are necessary to deliver a user story so they can plan accordingly.
• Avoiding repetitive conversations: When a team have a clear definition of done, they don't have to spend a lot of time deciding what testing they should do, whether they should update documentation, and what environments to go to. They have an agreement to fall back on. The team can in fact quickly determine if a backlog item is done by just comparing what activities have been completed with what the team agreed to.
• Reduces rework: The definition of done limits the cost of rework once a backlog item is accepted as “done”.?

When is the Definition of Done created?

It is always recommended that agile teams create their definitions of done as early as possible and at the latest prior to the first sprint planning. Without a shared understanding of what “done” means it is basically impossible to align on how much work a team can pull into a sprint and how they’ll measure their success in any given sprint.

If a team is not willing to create a Definition of Done prior to the first sprint planning they will realize during the sprint or at the latest in the sprint review that the quality of features they have been deploying may not be consistent, and most likely does not meet stakeholder expectations.

Who creates the Definition of Done in Scrum?

Multiple parties are involved in the creation of the Definition of Done. Ultimately it is the responsibility of the Scrum Team to create this shared understanding. The Team always considers input from various stakeholders in order to meet their expectations. The DoD checklist should normally reflect whether the scrum team has met every requirement and quality standard for all the user stories. DoD should also act as an official gatekeeping mechanism for stories to move from in-progress to done, ensuring quality and consistency along the way.

User Story DoD Examples:

• Unit tests passed
• Code reviewed
• Acceptance criteria met
• Functional tests passed
• Non-Functional requirements met
• Product Owner accepts the User Story

The difference between the Definition of Done and the Definition of Ready

The Definition of Done refers to an item being fully developed i.e. finished. Contrary to that, the Definition of Ready describes the requirement of a product backlog item being good enough so that the Agile team can start working on it.

Also, the Definition of Done is mentioned in the Scrum Framework, whereas the Definition of Ready is not. This is rather an artefact that teams can add on their own to help streamline what criteria must be satisfied before a user story is ready to be prioritised for inclusion in the next sprint/increment, and also help to measure the team’s success success. The objective of a definition of ready is to avoid confusion and blockers and increase efficiency when working on a user story.

It's imperative to make sure there’s a shared understanding of the definition of done within the agile team. If the definition of done is merely written on a wall but not followed it’s of no use. Likewise, if different members of your team interpret aspects of the definition of done differently. A large part of the benefit of a definition of done is that everyone on the team shares the same understanding about the items on the definition of done and follows them.

Are you working in a Scrum Team? If yes, I would highly recommend you try and encourage your team to have Definition of Done (DoD) and observe the benefits for yourself. Have you tried to have a set of Definition of Done before in your team? How beneficial did you find them? Please let me know your thoughts.