DoD: The basics

The Definition of Done (DoD) includes the conditions and criteria that a software solution or feature has to meet in order to be accepted by the customer. When something is done – this means that it can be released without any further work or testing.

Of course, DoD varies per project and is something that should be discussed and agreed upon by all parties involved. It depends on a lot of variables, such as the unique processes, goals and setups for a project, and is pretty important in the final stages of software development. Why? Because DoD helps to prevent technical debt from being unwittingly accumulated and creates a common understanding of what is considered to be done. This helps us avoid a lot of potential conflicts and confusion, or waste too much time overdoing things. Plus, DoD allows us to maintain control over the development process by making it more predictable and improving the quality of the outcomes.

Done: How to define it?

If you want to define what it means for something to be done – there are 3 steps to follow:

• Create a general Definition of Done for your company that can be applied to any project.
  This will help you clarify more specific criteria later on, whenever a new project is about to begin. For example: “The code has been written, documented and reviewed. The code works – it has been tested and doesn’t break anything along the way”. A broad statement like this is a good starting point for the next step, allowing you to work on your DoD in the right order, from general to specific.
  
  
• Create detailed checklists for your team.
  Every checklist has to cover a different area of software development, so it’s important to assign all the specific points to the right categories. The checklists have to be clear for everyone involved and adjusted to each project. However, you will quickly discover that the vast majority of points can be reused over and over again. Once you have the basics covered, it’s always easier to define “done” for other projects, too.
  
  
• Check your DoD against the project goals, requirements and values.
  DoD always has to be in line with your client’s needs, which is why it needs to be verified. This way, you can be sure that you will deliver to your client’s expectations, which is the most important criteria for success.

And please note that the Definition of Done shouldn’t be forced upon. It is quite the opposite – the best way to come up with DoD for your Scrum team (including Product Owner, Quality Assurance specialists, and developers) is to sit and figure this out together.

DoD: The areas that need to be covered

There are a few areas that certainly need to be addressed whenever you are preparing checklists for your team. You have to ask yourselves a number of questions in order to make sure the lists are comprehensive, without involving any unnecessary conditions or creating additional acceptance criteria. Try to keep it simple and don’t overcomplicate the process – but don’t allow yourself to overlook anything either.

To get an idea of which areas should be covered and what kinds of questions should be asked, look at the examples below:

Area: Development

• Is the code enough or do we need to write the tests as well?
  
• What kind of tests do we need to write?
  
• Do we need to test everything or just a few selected areas of development?
  
• Do we need to have a code review?
  
• Who should do the code review?
  
• Do we need documentation?

Area: Testing

• Do we need to test this feature?
  
• What kind of tests do we need to run?
  
• What exactly should be automated in the tests?
  
• Can we leave any specific bugs?

Area: Continuous Integration/Deployment

• Do we need to validate changes by creating a build and running automated tests?
  
• Do we need to run static code analysis?
  
• Do we need to deploy this feature to certain environments?

DoD: the checklist

Once you have all the answers that you need, it’s time to prepare the developer’s checklists. These should include clear, concise and very specific points that are totally unambiguous so that they don’t create any confusion.

Those checklists may include points such as:

• Unit tests have been created.
  
• Code Review is done; conditions:
  – 2 developers need to accept the pull request,
  – at least one senior developer needs to accept the pull request.
  
• The user story has been tested by quality assurance.
  
• There are no high severity bugs linked to that story.
  
• Automated tests have been created, if applicable.
  
• Backlog items have been verified in the Test environment (including non-functional requirements, etc.).
  
• Product owner review is complete.
  
• Code has been implemented according to the technical concept.
  
• Acceptance criteria have been fulfilled.
  
• US code is “non-breakable” (rollback is possible).
  
• UX check is done.
  
• [If required] automated tests have been implemented – GUI tests, contract tests.
  
• [If required] non-functional tests have been completed – performance tests, security tests.

As you can see, these points are crystal clear and leave no room for any confusion. Every team member will understand them in the exact same way, so whenever a piece of software or feature is considered to be done – it’s indisputable.

Conclusions

The Definition of Done is a tool that you should use to maintain full control over the development process; it helps reduce the risk of prematurely releasing something that is not quite ready to be presented at your next Sprint Review — or to your client.

When defining what “done” is, you should always follow a few good practices:

• Go from general to specific.
  
• Keep things clear and simple.
  
• Make your definition as comprehensive as possible.
  
• Don’t overcomplicate things.
  
• Bear in mind your client’s needs and expectations.

This is probably the simplest guide to the Definition of Done that we can give you. If you still have any questions or doubts – don’t hesitate and contact us, so that we can be of assistance!