Definition of done

The Power of Definition of Done

The concept of Definition of Done always seems to me very simple. But for some reason, many organizations are struggling with it. So, let’s check it out. Definition of Done is an agreement among Scrum team about when we are internally done, ready for a Sprint review. It’s like a quality checklist of what needs to be done before we show it to the customers. The weakest definition of done is “It works on my computer”. You can do better than that. Usually, it would include automated testing, peer review, creating documentation, and agreement on which environment it needs to run like a test environment, production, etc.

Keep in mind that the more strict your Definition of Done is, the more expensive it is to build a feature. So, it depends on what kind of business you’re in. If you’re a life critical or mission critical product, you need a higher Definition of Done then if you’re just building Facebook games. If you have a bistro on the corner, you have a lower Definition of Done than if you plan to have a Michelin star restaurant. The quality costs you. And actually the lack of quality costs you even more. So you need to find a balance.

Now, what happens if you don’t have a Definition of Done defined at all? In general, it’s a mess because you don’t know what is working. You don’t know what still needs to be done. Having a Definition of Done brings predictability and define quality. So spending a time and making clear agreement with your team will pay back.

Definition of Done (DoD) is a simple thing, although people are often struggling with it. It only defines what “done” means. It brings consistency into the product delivery. It sets the bar of quality we all keep the same. People often mix it with the acceptance criteria and are confused. So let me summarize it. Definition of Done shall be the same for all Product Backlog Items, as we need consistency, we need to know which quality standards are kept. Definition of Done is created as an agreement between Product Owner and Development Team, so it contains both technical and business quality requirements. It shall be stable for the product and not change Sprint to Sprint. Eventually, we can improve it, but we aim for consistency so we keep it stable. Definition of Done is the same for all teams who work on the Product Backlog to keep that consistency.

So how can such Definition of done look?

Coded
Tested
Reviewed
Documented
Running on test server
Accepted by Product Owner

You can make it more specific:

Coded according to Product Backlog Item (User Story) definition
Automated tests (unit, functional)
Reviewed (by different team member)
Documented (internal)
Running on test server
Accepted by Product Owner

Eventually, in some time we may improve it for example as follows:

Coded
Tested
Reviewed
Documented
User documentation
Translated to Chinese, French and German
Running on production
Contains business measures how users used it
Accepted by Product Owner

In this case, we achieved continuous delivery within our Sprint. We release each Backlog item to our users directly whenever it’s done. We need to translate it as a part of that otherwise we can’t be able to release. And we have to add some business measures to know if we are getting the expected impact or not and get fast feedback. As you might see, the more the organization is Agile and teams cross-functional, the wider is their Definition of Done.

Definition of Done shall be visible so everybody can see it. Never compromise. The User Story is either done or not. Any other state only brings chaos and makes any release completely unpredictable.

Undone Organization

Agile and Scrum transformation is not any easy and it takes time. For a big organization, such time can easily be counted in years. During those years you would be dealing with so-called undone organization. Scrum itself only knows three roles – ScrumMaster, Product Owner, and Development Team. That’s all we need to deliver value to the customer. The other roles are ultimately not needed.

However, at the beginning of our journey, the undone organization might be bigger than the Scrum part of our organization. As our Definition of Done is extending, the teams are getting more and more cross-functional, we are able to embrace those people and make them part of the team. The more the team extends its cross-functionality, the closer we get to the production quality and real-time feedback.

For example Architect and UX people are often at the beginning of the Scrum journey outside of the team but as the team is getting better and learn, teams are able to take it over and make it part of the Definition of Done and separate Architect and UX roles disappear and people move into teams. At first, it sounds unrealistic but in some time this is exactly what needs to happen in order to optimize for fast value delivery and feedback.