In software development, having a Definition of Done ensures that transparency and quality of the completed work fit the purpose of the product and the overall goal. A good DoD gives us the feeling that the potentially deployable software increment meets the standards in terms of quality and usability. DoD is one of the most important elements of Agile software development. If the goal of Agile is to ship usable software, then you need to know what that looks like before you can even start.
The question is how to create a good Definition of Done that helps to assess when work is completed on the product increment. In this article, you will find out how to do it well in 5 steps. But first things first, we need to understand what the Definition of Done is and why it is crucial to have one.
What is the Definition of Done (DoD)?
According to the latest (2020) Scrum Guide, “the Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product”. Work cannot be completed without meeting the criteria of Definition of Done and cannot be considered part of an Increment unless it meets DoD. This version states that DoD is created by the Scrum Team, while in the past, this responsibility was explicitly owned by the Development Team. The shift results from the greater emphasis put on the importance of the Scrum Team working together towards a common goal introduced in the 2020 Scrum Guide update. If you want to know more about the changes in the latest Scrum Guide and their impact on the Development Teams, feel free to read my article Scrum Guide 2020 Update: Key Changes And Their Impact On Development Teams.
What is the purpose of the Definition of Done?
The Definition of Done is crucial to high-performance Agile Teams as it helps them to develop best practices and behaviour that drive quality, transparency and consistency in software development. More about how to build highly functioning Agile Teams can be found in the post How To Build High Performance Agile Teams.
Without a clear DoD, your development team doesn’t know exactly what is expected from them and what they are working towards. A well-defined Definition of Done gives us the feeling that the potentially deployable software increment meets the standards in terms of quality and usability.
It does not matter what project we work on or whether we implement functional or non-functional requirements. We should apply the acceptance criteria to each of them and check whether the result of work in the current Sprint, i.e. its Increment, meets the requirements that we have defined ourselves. This is important for the correctness and quality of the software increment as we cannot allow a situation in which individual parts of the product meet different acceptance criteria.
The benefits of adopting the Definition of Done are:
- Clear responsibility - everybody knows what to do and what is expected from them,
- Timely delivers - no gaps in the project delivery, the necessary work is delivered on time,
- Accurate estimates - clear definitions ensure what is required to finish the project,
- Explicit handovers - everybody knows what is the final product, how it should be delivered and tested and who delivers it,
- Precision - the team knows exactly when the development ends without the need to work overtime.
How to create the Definition of Done?
If any production standards already exist in your organization, it is worth using them as a starting point. However, if you do not have them, or for some reason, do not want to use them for a new product, it is worth following the advice below.
First, you need to answer a couple of questions yourself:
- what it means that the product can be used,
- in what environment it must be working well,
- what tests it has to pass before it happens,
- what documentation it must have.
Second, you need to establish the exact conditions:
- what specific tests do you perform on the project,
- what type of tests and at what level,
- what particular effect of testing satisfies you?
Then, you need to define what it means that the work of the individual team members has been integrated into one product. How will you check it and where? It is important to stick to common nomenclature in terms of both code writing and documentation.
1. Decide on your Definition of Done as a team
The team is the creator of the criteria. The most important thing is that the list of criteria does not include those that no one wants to follow or that will take a long time. Let's face it, if the criteria we define are difficult or impossible to comply with, nobody will do it.
Certainly, it should include elements that allow you to gain the internal conviction that the finished piece of growth meets the requirements and therefore, it can be implemented in the production environment with a clear conscience. The golden rule for many companies assumes that if the code does what it is supposed to and does not break anything else.
2. Create a checklist template
Definition of Done is a set of criteria that the requirement must meet in order to be considered complete. This is sort of a checklist with some elements to be checked before indicating the Increment as done. Ensure that these rules apply to every task or issue within the sprint. Many teams often focus only on the criteria for small features or issues while forgetting the larger definition of done. A good idea is to embed the DoD into the workflow.
3. Sharpen the criteria
The most common element of Definition of Done is the need to perform manual tests and write automated tests. Equally often, a set of criteria includes the requirement to write unit tests. Sometimes there are also requirements for updated documentation and preparation of an implementation manual or scripts used for updates.
When defining the completion criteria, make sure that they are clear and "sharp" to all participants in the process. There is nothing worse than "Requirement will be complete after all tasks in Jira have been completed" or "Unit testing should cover enough classes".
Tip: a good way to think of the DoD is as the minimum work required to meet your quality level. However, it is possible that the requirements change over time so it is crucial to review them in the future.
4. Assign acceptance criteria to each individual task
To successfully complete your sprint you need acceptance criteria and a well-defined Definition of Done. The best thing to do is to assign them to each individual task to avoid any confusion or neglect. Make sure each issue includes relevant information - it makes it easier for the team to figure out what they need to be working on and tick off the right acceptance criteria as the development progresses.
5. Update the Definition of Done when needed
The definition of Done grows with the product. New criteria probably will be added to it, and the existing ones will be more strict. That is why its shape is regularly inspected and adapted, like all Scrum elements; a good time to change the DoD is the Sprint Retrospective - then the new Definition of Done is valid from the beginning of a new Sprint.
Keep in mind that being a part of a large project where you work on different layers of the application, developing one DoD for all teams may be difficult, and sometimes even impossible. In such a situation, you will be left to make use of common sense. Where possible, you can introduce a common list of completion criteria. Leave it liberal enough so that all software development layers (e.g. front-end, back-end) and teams can fit in it. In other areas, however, you must make it clear that each team has its own additional acceptance criteria, extending the official Definition of Done.
Summary
In the Scrum Guide, the Definition of Done is rigidly attached to the Increment. Without the Definition of Done, we cannot say whether there is a Product Increment or only the unrelated results of some work on the requirements. Thus, the Definition of Done is an essential transparency tool: zero-one determines what has been done and can be used, and what else cannot be used because it has not been completed).
Creating a clear Definition of Done which will be used by the Developers in practice is a timesaver in the long run since it reduces unnecessary revisions and works later on. When the code meets the acceptance criteria, everyone can be sure that it is ready to create a Product Increment. We must meet the Definition of Done criteria in order to ensure quality. It will prevent features that don’t meet the DoD from being delivered to the customer or user, so it will increase customer satisfaction and product quality
If you are looking for a development team with years of experience working with Agile methodologies, fill out the contact form to schedule a call.
