It might seem weird to discuss what "done" could mean. but I assure you that it is a topic that is really worth it

By definition :

"Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." - The Scrum Guide

One key concept in Scrum that help teams and organizations generate value is the Definition of Done.

Image removed.

"It's done, but..."

You may probably have heard this, from a Scrum Master, a developer, or even a Product Owner. The stakeholders and managers love to see things moving forward (normal, right?). They often ask these typical question to Scrum Teams like "when will you be done". It will be difficult to answer to the question, if you don't even know what done means for you and your team.

Done can also be understood differently, depending on people perspective :

  • A developer may consider a feature done when he has completed the coding part
  • A tester may consider done when his/her test criteria are met
  • A product owner may consider done when the feature is working, even if it's on the local machine
  • The stakeholders may consider that done means ready to be handed on to customers

What about the product or the feature itself? is it completed, yes or no?!

We can clearly see the misalignment between all these actors. This lack of transparency can be deadly when dealing with complex work such as product development.


The solution provided by Scrum : The Definition of Done.

What is the Definition of Done (DoD)?

One way to think about the Definition of Done is as a checklist of items or criteria that must be completed before a product or feature can be considered "done." This might include things like testing, documentation, user acceptance, deployment, non functional requirements, etc.

Having a clear Definition of Done :

  • Helps align everyone on what "done" actually means when building the product
  • Provides everyone a shared understanding of what work was completed as part of the Increment
  • Increases the transparency of the increment, so everyone knows the actual state of the product, and what needs to be built next in the backlog
  • Reduces the risk of delivering poor quality increments
  • Eliminate waste of re-working on items that are considered not "done" based on undefined expectations
  • Creates focus for the Scrum Team, so they build increments that meets only the criteria they agreed on, no more, no less!
  • Ensures that the built product meets the desired level of quality and meets the needs of the customer.

Who creates it?

The Definition of Done should be created and agreed upon by the entire Scrum team, including the developers, the product owner, and the Scrum master.

If the organization has a defined DoD, the Scrum Team should then follow it as a minimum.

They should apply it consistently throughout the sprints. They can review it and update it as needed (during Sprint Retrospective for instance) to ensure that it continues to reflect the quality needs and goals of the product.

How to use it?

The Scrum Team should commit to its Definition of Done and build only increments that meet the defined DoD. By doing so, they increase the transparency and help them and their stakeholders assess and inspect the actual state of the product, rather than discussing features or items (let's say User Stories to make it simple for some people) that needs to be worked on later on to make it fully complete.

In other words, Done in Scrum means :

  • The US is completed and meets the criteria defined in the Team or Organization Definition of Done
  • It means 100% done, not 50, or 70, or even 99%...

If a US is not fully completed during the Sprint, It means that it's not "done" yet. Simple!

And that US is not considered as part of your increment, and thus should not even be discussed during the Sprint Review.


Definition of DONE and the increment

In summary, the Definition of Done is a very important part of Scrum Framework. Every Scrum Team should have its Definition of Done, maintain it continuously to meet the product quality requirements. By establishing clear expectations and applying them consistently throughout the sprints, Scrum teams can deliver high-quality products and deliver value to the organization and its customers.