If you’ve heard of Scrum you’ve probably heard of something called the Definition of Done. If you’ve worked in a Scrum team, it’s next to impossible that you haven’t. Yet, I’ve found so many teams struggling to find a common understanding of what it actually is. This is my attempt at increasing the software community’s awareness of the concept and to offer a chance for Scrum teams to reflect on what I am writing about and how that maps to their context.
Let’s start by taking a quick look at what Scrum says about the Definition of Done and, perhaps most importantly, why we should pay attention to such a thing in the first place.
What Scrum Says and Why We Should Have It
Scrum doesn’t really say anything – it’s a method – but there is a clear definition for what the term means in the context of Scrum. You can read Ken Schwaber’s view on page 20 of the Scrum Guide. Please do read that page – it’s going to be 2 minutes well spent.
To summarize the perspective of the community-at-large, the Definition of Done is a joint agreement between the team and their Product Owner about what it means for a Product Backlog Item to be “done”.
“When someone describes something as done, everyone must understand what done means.”
The simple value proposition of having a Definition of Done is to avoid misunderstandings, flawed assumptions and the resulting aftermath of nasty surprises and broken trust. By agreeing on what we actually have when we’ve done something all parties have a common frame of reference: this is what has been done and everything else is still to be done before the release.
With an explicit Definition of Done the Product Owner can prepare for the upcoming release, trade show, etc. as he has an idea of what remains to be done before the sufficient level of quality has been ensured and the necessary bits and pieces are all in place. “Updating the online help isn’t in the Definition of Done? OK, I’ll set aside some time before the release for getting that stuff done.”
For the teams themselves the Definition of Done provides a simple way of knowing when to move on. If the Definition of Done is fulfilled, it’s time to move this story card over to “done” and start working on something else. An explicitly agreed definition also gives the team members a formal and social permission to nag if someone isn’t complying with the joint agreement.
Who Should Define It
The “DoD” is a joint agreement between the team and their Product Owner. Therefore, both parties should be involved in defining what “done” means for us. In the end, the Definition of Done represents our current capability of delivering potentially shippable increments. Hopefully our capability improves over time and the Definition of Done should reflect that development. It’s not something you carve in stone.
We’re not talking about a wish list or a day dream, however. We’re talking about a matter of fact style truth in all of its ugliness. “This is how much we can feasibly do for a backlog item within a sprint.” If we’re really good, we can deliver a high quality increment to production 5 minutes before the sprint ends and forget about it. If we’re not so good, we have a parallel “staggered sprint” that works for two weeks to take what we’ve churned out and get it into good enough shape that it can be deployed to production – because we hadn’t tested it much.
It’s worth noting that there’s a bit of a trade-off involved here. To certain degree we are capable of doing more extensive work, adopt a more extensive Definition of Done, by taking on fewer user stories into our sprints. Or we can churn out more stuff in a sprint by cutting back on the level of scrutiny. I suggest, however, that it’s better to err towards a more extensive definition as I’ve found that it tends to correlate with less inventory and a higher throughput. We all know how productive we are when the code base is full of crap, ridden with bugs, everybody working on their own feature in parallel, and the whole project devoid of any test automation whatsoever.
We should have a Definition of Done from the beginning. A practice that’s become more or less the norm with our software delivery projects at Reaktor is to start every new project with a “Ways of Working” workshop where the team(s) and the Product Owner(s) agree on, among other things, their Definition of Done. Sometimes we fail and end up agreeing on it later on, realizing that we do indeed need one.
What Should Be In It
The Definition of Done should describe what we have and what we’ve done by the time we say we’re “done”.
Do we have end user documentation for the feature, user story or scenario in question? Do we have automated regression tests for it? How many of them? With what kind of coverage? Developer tests? System tests? Integration tests? Have we reviewed or pair programmed all code written for the feature? Has the UX guy taken a look at it and given his blessing? Have we showed it to the Product Owner and gotten his blessing that it’s OK?
In essence, the Definition of Done is a description of what kind of scrutiny have we put our work through and what kind of work still needs to be done before we push the yellow button labeled “Deploy to Production”.
In the end, we need to be able to tell whether we’ve fulfilled the Definition of Done or not. That is why we should strive to formulate our definition in clear terms that facilitate a binary yes/no answer to “have we done this?”
It’s a potential trade-off, however, once again. A common subject that leads to such trade-off is unit testing. Most teams agree that unit testing should be done but many teams are also quick to point out that in their context it doesn’t make sense to require unit tests for everything. In such cases, it might make sense to let go of having a binary criteria for “everything being unit tested” and settling for a less ambitious standard such as agreeing that the overall test coverage must remain above 90% or, compromising our ability to objectively verify our compliance to our agreed standards, agreeing that everything is “sufficiently unit tested”.
How Is This Different From Acceptance Criteria
We sometimes mix terms such as the Definition of Done and Acceptance Criteria rather liberally in conversations, using them interchangeably. That is a mistake, however, as there is a clear difference between these two concepts.
As we’ve established, the Definition of Done describes the level of scrutiny and activity towards a given Product Backlog Item. This is about process and quality. Acceptance Criteria, however, are all about functionality and requirements. Whereas the Definition of Done might include stuff like “at least one automated system test is in place and passing”, the Acceptance Criteria for a backlog item might include stuff like “Non-numeric input is rejected and results in the transaction being canceled.”
There is a relation between the two concepts, though, in the sense that fulfilling a Product Backlog Item’s Acceptance Criteria is (at least implicitly) the very first element of the Definition of Done. After all, if we haven’t built the right functionality it’s somewhat irrelevant whether or not the code was peer reviewed.
As the Definition of Done is about process and quality, it’s also a product or project level global standard. Everything we do we do abiding by that definition. There is no “definition of done for user story 145.” As the Acceptance Criteria is about the functionality and requirements it’s a backlog item level definition. In other words, each Product Backlog Item has its own Acceptance Criteria.
Summary
Definition of Done is a joint agreement between the team and their Product Owner about what it means for a Product Backlog Item to be “done.” This common understanding is necessary for us to be able to prepare for the work that remains “undone” – the work that is not included in our Definition of Done. It also tells us when we should move on with our sprint work and creates a social contract between team members, making it easier for the team to hold themselves accountable for their agreed-upon behavior.
For these reasons, the Definition of Done should be as unambiguous and clear as possible so that it’s trivial to verify whether we’ve followed through with our agreed behavior, i.e. whether we’ve given our work the kind of scrutiny we’ve set as our standard.
Is there anything that you find confusing? Is there anything that you feel should’ve been addressed? How does your Definition of Done look like?