The definition of done (DoD) is one of the most important and least-understood elements of the Scrum Framework. It is specifically called out in “The Scrum Guide” in what is probably its biggest section, and yet, I’ve seen so-called ‘definitions’ of Scrum that fail to mention it at all.
In this post, we’ll be talking about why, exactly, the DoD is so important.
So, what is the definition of done? Fundamentally, it is the Scrum team’s agreement about the standard of quality that it will apply across the product. This concept is closely related to that of the Potentially Shippable Increment that must be created at the end of each and every sprint. The two words in that phrase that the DoD concerns are “potentially” and “increment.”
While all agile approaches – Scrum included – aspire to “deliver early and deliver often,” this does not mean that a product must be handed over to the customer at the end of every sprint. Whether enough useful value has been accumulated to warrant a product’s release is a business decision, and one that is the product owner’s responsibility to make.
If, however, the product is not of releasable quality, then the product owner is effectively relieved of that responsibility. So, scrum requires that the latest increment — whether it is going to be released or not — is of sufficient quality that it could be handed over.
What the product owner and the development team are agreeing on when they establish the DoD is the quality bar that will determine what can be shown in the sprint review. You may have heard phrases like “done, done” and even “done, done, done” from some agile practitioners, but in the world of Scrum there is only “done” and “not done.”
An increment – and that’s the fundamental level at which the DoD works – is done only if it meets the definition of done and can be demonstrated in the sprint review. If it doesn’t meet that standard, then it cannot be shown to the stakeholders.
At the very least, the DoD should mean that the increment has passed all its tests and is fully integrated with the previous increments. In this way, what is being shown is a quality-assured, small and skinny version of the product.
Clearly, the DoD has implications for governance as well as quality. “The Scrum Guide” says that if there are corporate standards in place then they form the default DoD. My interpretation of this is that if, say, there is a company standard for code quality, then that standard should be incorporated into the development team’s practices as well.
Agilists never trade quality for speed, and so we should never lower that standard. In some cases, however, existing corporate standards might get in the way of efficient development. Organizations that use PRINCE2, for example, will often have a phase gate-based governance approach.
Such an approach might work well in a product development that has a high level of predictability, but where there are many unknowns (as in most software development) an approach that is instead based on feedback and responsiveness is needed.
Because of its reliance on predictability, phase gate governance can kill an agile product development. So, in organisations that use phase gate governance, the Scrum team will need to have a conversation with the wider organisation to find better ways of giving stakeholders confidence.
A DoD which clarifies what is needed for the sprint review and which is enacted by the Scrum team accordingly is the perfect starting point for feedback-based governance. Since there is no one-size-fits-all DoD, what the DoD includes is always going to be situational. But, if we accept that the increment must be fully tested and integrated, then several practices naturally suggest themselves.
First, each PBI which makes up the increment will need to have passed both its acceptance and unit tests. Acceptance tests are specific to each PBI, of course, but the DoD will presumably state the policy that all items must pass their acceptance tests to be accepted.
The entire increment will also need to pass integration testing and, as it is unlikely that all the PBIs will be finished at the same time, each of those will need to be integrated incrementally. Therefore, regression and integration testing is strongly suggested at the PBI level.
In other words, there are implications about workflow embedded in the DoD.
There is yet another aspect to the importance of DoD: the team.
A group of individuals is just that, and can only become a genuine team when it rallies around a common goal. But how can a team meet a goal if they don’t know when their work is finished?
I once interviewed two programmers on the same team and asked them how they dealt with quality. One of them opened up his IDE and showed me the unit and acceptance tests he ran on his code. The other told me it was the QA department’s job to deal with quality – not his. As you can imagine, this product (and the group building it) did not fare well in the end.
Those were two people with the same functional background– imagine having a new development team, with all the different skill sets needed to create the product, and no clear DoD. The result certainly isn’t pretty.
Revisiting the DoD
Scrum teams, for various reasons, may not be able to take product increments to a potentially releasable level every sprint. This might be due to the team’s level of performance (if they are a new team, for example), or because the production environment could not be fully replicated in the team’s development environment.
In this situation, it is important that the DoD clearly indicates where the team’s responsibility ends. Any work that would still be needed to make an increment releasable would be categorized as “undone work” and would need to be listed in the DoD. The DoD would then be retrospected regularly to see what could be moved from the “undone” category into the “done” category as the team takes quality assurance more and more into its own routines.
“Undone” work should not be confused with unfinished work. Work required by the DoD which is unfinished means the item concerned is not “done” and thus cannot go into the review. An item can still be “done” if there is “undone” work.
To understand this, we can think of there being two quality bars: one for the sprint review and one for actual release. The gap between them is the undone work. In committing to any sprint goal, the team is implicitly committing to the DoD as well.
However, it is not committing to do the work listed as undone in every sprint — that work will be done just prior to an actual release The development team’s job is simply to get the increment to “done,” and the product owner then decides whether the PBIs that are part of it can be accepted as complete.
So what happens if an item shown in the sprint review is rejected as not fit for purpose by the customer? The answer is that, since it passed the scrum team’s standards, it remains ‘done.” If the product owner believes the requirement still has value, he or she will put it into the product backlog as a new item and it will be prioritized accordingly. But, of course, the team should still reflect on what has happened, and may well strengthen the DoD to reduce the chances of “done” items being rejected in the future.
So far, we’ve seen that the definition of done is important for:
- Product-wide quality standards
- Workflow and engineering practices
We’ve also seen that Scrum teams need to revisit their current definition of done on a regular basis to strengthen their assurance of the product’s quality.