The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.

Today we are going to talk about the one of these terms in the Scrum Glossary: Definition of Done. The glossary has the following description:

Definition of Done: a shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.

So the Definition of Done says something about what we consider is needed for an Increment to be able to be releasable. Commonly this is made transparent through it being available in a listed format publicly available to both Scrum Team and stakeholders. Let’s see what the statement is actually saying here:

a shared understanding of expectations

Although the Scrum Glossary is not explicit in who needs to share this understanding it should be for anyone involved in the Product Development effort. More simply this means at the very least that the entire Scrum Team and the stakeholders should have a shared understanding. These expectations are based on a discussion between what is feasible (Development Team), what is a customer wish (stakeholders) and what is cost-conscious (Product Owner). You might want to have a car that can go 200000KM’s without need for any maintenance. However, cost-wise and feasibility-wise this might be an unrealistic and/or very expensive quality wish. On the other hand maintenance every 200KM might be cheap and easy to build but way below customer expectations of the product quality-wise. 20000KM before maintenance might be a good cost-conscious, feasible, but still according to customer-needs choice. The importance of a shared understanding is that stakeholders and Scrum Team both know now that any Increment of the car is expected to be able to drive 20000KM without maintenance, not 200000 and not 200 either. This helps in determining effort to create a next Increment as well, because it fills in a lot of the work that needs to be done to create new Product Backlog items.

that the Increment must live up to in order to be releasable into production

Deciding on 20000KM before maintenance as a quality standard for every single Increment created means more than you might guess. It more explicitly means that every time the team adds features or does anything at all to the product they are creating it should still be uphold this standard for the re-iterated latest version of the product they just created. This is because every Increment in Scrum should be potentially releasable, meaning to be able to be put live, in production or in any other way released to the end-user population if the Product Owner decides to do so. Without any extra work needed to do so. If you have a team that is not able to release into production their latest Increment at any time without effort, this is an antipattern if it’s not your top-most priority to fix this. Scrum works through empiricism and you are not able to do Product Development empirically without potentially done Increments to apply it to.

Managed by the Development Team.

This final part of the description clarifies a common misunderstanding again. The Definition of Done is a Development Team effort. This makes sense when you look at their accountability. Since the Definition of Done says something about quality and not about the value of the product Increment. And who is accountable for the creation of product Increments? That’s right, the Development Team. Part of this accountability is managing quality of the Increment they are creating. This concretely means they should maintain their Definition of Done by spending time during a Sprint Retrospective to update it to reflect current understanding of quality standards needed and agreed to be part of the Increment. The input can come from more than just the Development Team. As we saw mentioned previously in this article it could be from stakeholders, the Product Owner and the Development Team. What isn’t mentioned yet is the Development Organisation. Often bigger organisations have set quality standards for any product created in the company. You could think of architectural standards, coding conventions or even obligatory corporate branding needing to be incorporated in any created product. Often this organisational quality standard could be considered as a minimum Definition of Done for the Scrum Team on which they can add more.

Conclusion

The Definition of Done is an important part of Scrum that I unfortunately often find unused by Scrum Teams. Confusion, discussion and simply broken products can all be led back to lack of common understanding about what it means to be done. The Scrum Glossary is pretty clear on what it is in my opinion and it helps to set these misconceptions straight, although it unfortunately eludes its importance.

Does your team have a Definition of Done? Does the Development Team actually manage it? Let me know in the comments what you think. Next time: The Development Team.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*