How to Create and Understand the Definition of Done

The year is 2023 and the world is a terrible place, but few things are scarier than a team that misses deadlines. 

Even worse, imagine one thing (one thing to scare them all), a team not understanding what it means for tasks to be completed.. What if they’re discovering similar bugs over and over again. 

One by one, a team of excellent developers fell to the power of a bad Definition of Done (DoD). Nightmare, right?

Don’t panic and stay calm! If this type of dystopian scenery is happening in your company, then you are in the right place my friend. 

In this article, we’re going to talk about how to understand and create a Definition of Done which is a building block of organization in software development. 

So, keep reading to really understand what it means to have a DoD for different stages of product development.

What is a DoD?

A DoD is a set of criteria that Product Backlog Items must meet in order to be included in the Product Increment, and later released to end customers. An item is “Done” if and only if all of these criteria are met. 

Important element of a good DoD is its clarity. The end of each task needs to be crystal clear to all involved. If a DoD is not clear to all participants, its application will not be successful.

There are two potential situations: A team may already have a DoD, but they are not using it. Another scenario is when you need to design a DoD from scratch in the absence of an existing one so that the team can use it.

Understand the Current DoD 

First and foremost – you need to understand the current DoD. The DoD must be understandable to the point where it can be verified. 

The application of a good DoD to any feature is a straightforward test. Any feature item should have a clear “yes” or “no” response from you.  If you’re not able to verify it in this manner, something is still vague with your DoD.

The checklist should be publicly documented and available, just like my diary. Jokes aside, use GDrive or any other cloud space easily available to the team. 

As you start your engagement with the team, make sure they are focused on the DoD. You’ll want to get to the definition of ready (DoR) but your complete focus, for now, should be on the DoD. 

Create the DoD

In a case where there is no DoD, you should prepare to completely reorient your team towards creating one and towards value. A team without a DoD is like.. a team without a DoD (I am really bad with comparisons).

DoD is created for the purposes of creating an aligned team statement on what delivering in quality manner means. It’s a way of getting one universally accepted interpretation of tasks and what it means to finish them. 

This is why writing everything down in a clear and precise manner is a way to avoid such problems. 

Since the DoD needs to be universally accepted and known to all involved in the process, we can break it on different levels, starting from the lowest.

For a development team, the most important things are bugs, user stories and PRs.

Sprint and release are slightly more advanced concepts that integrate user stories and PRs that are more fundamental in nature.

DoD for PR (Pull Request)

PR is the smallest unit of work or a single change in a task (it can be a single change of code in a code base, for example). Here is an example of how a PR is made:

A developer needs to download the current version of the code on his PC. After he adds the appropriate changes, tests it and makes sure that everything works, the developer creates a PR. When a PR is approved it enters our code base.

A good PR needs to refer to a feature it relates to. It should not be sent for a code that only served the developing purposes, with working comments, etc.

PR can also be used as a unit for code review. DoD for PRs  is a list of minimum code quality standards that a developer needs to adhere to in order for a PR to be considered acceptable to be added into the product increment and merged to the product codebase. Once the list is done, the minimum is satisfied and we can go further. 

You don’t want to start with a DoD of 50 checks because time is limited and the earth is flat (what?). In simple terms, each PR needs to be checked, so you should be mindful of effort being invested by the team and the value being reaped from the mentioned activity. Instead, focus on highest value checks first and grow your checklist gradually as you raise the quality bar for your team.  

When checking DoD on every PR becomes a standard and familiar work, and you are satisfied with the consistency and level of quality you as a team are producing, only then you can start looking into creating further efficiency, through automating some (if not all) of the checks.

PR DoD also needs to be transparent and developers need to know all the things that need to be reviewed before presenting PR. At the end of the day, nobody wants a returned PR any more than they want to see Elon Musk without a shirt (I will try to delete that image from my mind).

Why? Because each correction after the review process is wasting the time of the whole team. The optimal process here is the one where all problems are identified and corrected before the formal review.

Finally, each team needs to find its balance in terms of the number of PRs. 

DoD for User Story

User story is a story from the perspective of the user. It follows this structure: “As a user, I want to create a facebook-like app to make 100 quadrillion dollars.” 

Apart from this ridiculous example, the purpose of the User story is to describe the functionality from the user point of view.

User story also has acceptance criteria. The purpose of acceptance criteria is to help us to understand which features are needed from a business side. I.e. which criteria must be met so that you as a business owner/product owner can accept it. 

Acceptance criteria are behaviors that we expect from a system as a response to a certain combination of user actions (a.k.a user scenario)). If those behaviors are missing or are inadequate, the acceptance criteria are not met. 

In a project, we have a checklist of requirements for each feature. This way, everyone knows  what needs to be done for each feature. 

Make sure that the first check in your User Story DoD is  “are all acceptance criteria fulfilled?”.  While DoD serves as a general quality guideline for all user stories,acc criteria are specific to each user story and are a mandatory first step before any further DoD checks should take place. 

The rest of the DoD checks are there to  ensure that each user story  will correctly fit in the bigger context of a business as a whole. In other words, acceptance criteria specify what each task’s intended business outcome should be. DoD is a safety net to ensure that  it will actually work.

You might want to verify that an application has been tested on the proper platforms, browsers, screen resolutions, etc.

Bugs

Bugs are a normal part of software development. In our company, we recognize two types of bugs. 

There is an existing bug (it’s already in the production which is why it impacts the end user) and it’s in the same level as user stories.

There is also a new bug. New bugs arise when we’re working on a new feature. It’s still in a testing environment and not in production.

Bugs are not new requirements, new business scenarios and have no acceptance criteria. They only point to the fact that there are problems with existing features.

They have expected behavior and actual behavior (just like my knees after one basketball game). A tester provides you with a report detailing what was done as well as the outcomes.

For example, if there was a bug with automated scripts, there is a chance that you need to change/update the automated scripts.

Similar to User stories, bugs also need to pass the list of tests defined in the DoD in order to be deemed done.

DoD for Increment

Sprint refers to a single iteration of work items that needs to be completed by the development team. A product increment is created as a result of a sprint.

Each team is creating their time frame for an optimal sprint. To have a successful sprint, we need to decide on a DoD. This means, having a statement for DoD for a successful increment.

Each sprint consists of n tasks. For example, you want to create a feature, improve an existing feature, fix the bug, etc. It doesn’t matter, here we want a product increment to go to production. To achieve this, we need to ensure that all changes are successfully implemented. 

For example, we want to ensure that our change in code didn’t break any of the integrations with other systems. We also want to ensure that the system as a whole, after a new increment is added, is still performant, secured, etc.

In order to achieve this, we need to have a full list of tests that need to be defined for checking if the product increment is actually done (similar to user stories). You may need to test on different environments, see if regression happened, run automated integration tests, etc.

DoD for increment is highly relevant for distributed teams, i.e. systems with many instances. There can be a co-located team that works on a single code base and owns the product. 

Another option is a single team with distributed members that are working on a single code base and own the product. 

Finally, there are distributed teams (several teams with distributed members), all working on the same product. Each team is working on their own code base. Each team works as a standalone team, while owning only their part of the product. 

When it comes to building a successful product, the main thing is to align team members and integrate new features so our new product increments don’t break any of the existing functionalities. 

Since a feature needs to be tested on different environments, there needs to be a checklist for ensuring that the final product behaves as we expect it would behave.

In some cases, a team that developed a feature is not the same as the one who puts the code in production. Here, release notes are crucial. In release notes, developers write important information for each feature, how it behaves, what needs to be done, etc.

For a complex system, the things are much more complex and you need a more detailed checklist for ensuring that everything is checked before the release. 

The Bottom Line

This is the end of the article (and I hope not the end of the world as we know it) so, if you’re here that means you are ready to improve the overall quality of your team and that WW3 is avoided.

I hope your understanding of DoD and its applications is improved. So, stop blaming God (or gods, polytheism is still out there) and start implementing the newly acquired knowledge about the DoD.