Developers are known to be somewhat imprecise when answering the question “are you done with this feature?”. To be fair, it is an ambiguous question. What a developer first thinks of is “are you done programming?”, when in fact what the question actually means is “how long will it take until it is available for the users?”. This involves other tasks like testing, refactoring, reviewing, deploying, documenting… Here is where the Definition of Done comes into play.

As described by the Agile community, the Definition of Done is an agreed-upon list of the activities necessary to get a product increment to a DONE state by the end of a sprint.

Scrum enthusiasts stand by the belief that the Definition of Done is a requirement for the project’s success. That’s because it serves the team in various ways.

Definition of Done as a way to ensure releasable increments

“Potentially releasable increment” stands for the notion that by the end of an iteration the Product Owner can decide to ship the new changes and end the development for good with no extra work required to leave the product in a consistent state.

As a rule of thumb, if the team needs “hardening iterations” at any point during the development, it might be because they were not building potentially releasable increments. If a team defines and respects the Definition of Done, then it means they will prepare all the necessary configuration and adhere to the project quality standards at every single iteration, so that they don’t need any extra work in order to finally release it.

Definition of Done as a way to improve estimations

A team that is bad at estimating will eventually lose the client’s trust. Period. And it’s tricky because estimating is known to be one of the most difficult tasks surrounding software development. Nobody will argue against the fact that providing estimations that are 100% accurate is simply impossible, but there’s no doubt that there are ways to ensure you are set up to fail. Not having a proper Definition of Done in place is one of them.

Stick with me. In Agile, there’s a technique for estimating features called Poker Planning, where everyone gives a number as their estimation and the highest and lowest developers explain their reasoning. In our experience, most times, the estimation difference is due to the most optimistic developer forgetting about something, whereas in less than a fifth of the cases is because the pessimistic developer over-complicated things in his head. Hence it’s no surprise that the teams with a clear and thorough Definition of Done usually have a reduced gap between them when estimating and, in our experience, they have also proven to provide more accurate ballparks for complete MVPs.

An experienced Agile team estimates while keeping the Definition of Done in mind. As a consequence, they are less likely to be over-optimistic because they consider every part of the process needed to ensure the features built are potentially releasable by the end of the iteration. This doesn’t mean being conservative; it means being exhaustive and transparent about it.

Definition of Done as a way to avoid rework

Work which is only nearly done but deemed “done” is often called “deficit for release” or “work not done”. Although a feature may appear done on the surface, if the team hasn’t really polished all the edges behind the scenes, they will eventually be circling back to those “done” items.

The thing that makes Work Not Done so dangerous is that, similar to Technical Debt, it also comes with an interest rate. Not only can it pile up but also become harder and harder to fix with each sprint.

To make matters worse, unlike Technical Debt, the team might not be circling back whenever they find it most convenient to do so, but at the worst time: right before the release date (as if the stress wasn’t enough already). That’s why some Agilists claim there is a key difference between Tech Debt and Work Not Done, the latter being the one to really avoid at all costs.

Definition of Done as a way to enforce quality

How “quality” is defined varies per project. Not all products have the same non-functional requirements, which are the characteristics of the system that might not add direct business value but without which the product can’t move. The Definition of Done needs to be tailored to enforce them from the start.

For example, if your system is a website to get special discounts, then you need to ensure that some key features are responsive since it is very likely users will open the web from their mobile phones to look for discount codes once they are checking out at a business. So, “being responsive on mobile browsers” is going to be an item on the team’s Definition of Done.

It may seem obvious, but more often than not, it is not. Many teams start coding without thinking about the quality attributes they need to meet in order to make each increment potentially releasable.

They will develop the whole system ignoring these aspects, leading to one of the following outcomes:

  1. They will release a product that does not fulfill the expected quality attributes.
  2. They will have to circle back to address the issues.

To be fair, it’s not all developers’ fault alone. Junior Product Owners often push developers to build features half-through in an attempt to ship faster. But more experienced teams stand for the belief that quality is more important than quantity, meaning they don’t negotiate over quality but over functionality. They will not lower the bar because they know that doing so will come to bite them later on. And the Definition of Done works as a reminder of this.

After all, The Definition of Done is a means to achieve transparency, one of the key pillars of Scrum. It gets all the team speaking in the same language. Sticking to it is a timesaver in the long run since it reduces unnecessary revisions later on and avoids the frustrations that come along with unmet expectations.