In Scrum, the intention is to have a potentially releasable product after évery sprint. To achieve this with a sustainable quality, the team does not only need to fulfill the acceptance criteria of the story but must also assure that the quality of the developed product is high enough (I say high “enough” since it must always fulfill the predefined balance between scope, cost and quality). Since the team itself is responsible for the quality, it will wish to set itself some standards before it declares a story as “done”. This standard is what we call “Definition of Done” (DoD).
This report that something is done is called Sashimi after a sushi dishes that is not just a red fish but is a complete exclusive meal. When a product increment is Sashimi, then it is perfect.
The DoD is usually described as a list of value-adding actions that need to be taken before a story is considered finished. It is team and possibly project specific and is not considered static but should evolve with the project/team.
Isn’t the acceptance criteria enough? In a story the acceptance criteria describes the behavior of the product in specific situations. This usually sets some expectations on the external behavior of the product, in fact something that can be verified by black box testing of the product. In case you develop a product in a modular way this may also set the expectation on the individual modules. In any way, what the Product Owner describes in the acceptance criteria will seldom describe the inner parts of the software. This is where the DoD plays its main role. The DoD is not in any way intended to replace, but to extend the acceptance criteria. The DoD is what the team internally agrees that must be fulfilled before the story may at all be presented in a sprint review.
The team’s “marketing department” would say: When we deliver something, you can always be certain it fulfills your acceptance criteria and our definition of quality.
In the ideal world, the DoD is not necessary at all, as the optimal team member fulfills the criteria anyway. The DoD is a checklist that can be used as we are all far from perfect…
How to create a DoD
The team is the owner and user of the DoD, therefore it must have influence on the content of the DoD. If you don’t have the buy-in of the team on the DoD, you have totally missed the point.
Still, there are situations when you wish to influence the team to fulfill a basic set of DoD. One such could be if the organization has a global DoD (which certainly could make sense in a multi-cultural organization) to set a quality standard.
Who should decide on the DoD
Developers, developers, developers… well, that is not the entire truth.
Clearly the team should be part of the decision on the DoD.
In the end, the Product Owner is the “single wringable neck” and he is the one responsible for the cost of the project. I can think of many ways to improve the quality of the product, but not all of them are efficient and suitable for every project. Therefore the Product Owner is obviously to take part in the definition of the DoD.
Should also chickens be allowed to attend the finding of the DoD? No, they may of course use their influence on the Product Owner, but should not take place in such discussions.
Since you usually have a self-sustaining team in scrum, you should have both quality assurance and e.g. UI designers represented in the team. They all have the same possibility to vote on the DoD.
It should not be necessary to say that the Scrum Master should attend the meeting, as he will probably facilitate it just like all other scrum meetings.
Objectives for a DoD
The individual items of the DoD should be specific, measurable and attainable. When creating the items, you can lean back on e.g. the SMART(ER) rule that is often used when creating or analyzing goals.
The DoD should not overlap with the acceptance criteria of a story (it should be orthogonal to the acceptance criteria). Topics that are always part of the acceptance criteria could instead be handled as a DoD item assuming the team agrees on this.
The items in the DoD should be applicable and equivalent to (almost) any implementation story.
The items in the DoD can be applicable on single tasks, stories, sprints or even releases. It should be clear from the checklist for which scope the item is applicable. It may be useful to keep different checklists for each scope.
Please assure that your DoD list does not get too long, that would only confuse the team and reduce the performance or even lead to the DoD being ignored as “it is not possible to fulfill anyway”.
In some cases it also makes sense to not use a check box for each item, but in addition also a text field. For example we have made good experience with keeping the number of new tests as a number to show how many new tests were created. This is also a good sales argument in the sprint review. Similar, you may wish to keep the code coverage of your tests as a percentage.
A DoD workshop
There are many good ways to keep a workshop, googling will help you on the way… The main importance is that you involve the entire team.
Never stop learning
The DoD you have created in the first place is a good start, but you should not stop improving (don’t forget the fundamentals of scrum). You will probably want to inspect and adapt the DoD every once in a while, the sprint retrospective is a good place to discuss this.
As discussed below, the team should grow and get to the next level of the DoD quite soon (if not already done).
What could be part of DoD
We recently had a sprint review where a developer claimed that a task was finished (we did not verify it in the review but took it for true). When checking this afterwards, we found out that it was not yet committed to the source repository. Such issues may only happen once and should in a team of mature developers not occur at all. This example just shows that in some cases, even the fundamentals below would make sense as a part of a DoD.
Every organization and every team have its own maturity grade and will therefore want to define its own DoD. Further, every different industrial sector will have its own specifics that should be defined in the DoD. Nevertheless, it may be useful with some examples of topics that could be part of a DoD. Below is a non-comprehensive list of such topics that may be part of your DoD.
| |
Implementation |
User Experience |
Quality Assurance |
Documentation |
| Beginners |
|
|
|
|
| Checked in |
X |
|
|
|
| Builds without errors or warnings |
X |
|
|
|
| Installed and demoed at test machine |
X |
|
X |
|
| Tested |
|
|
X |
|
| No known bugs – and no regression bugs |
X |
X |
X |
X |
| Documentation updated |
|
|
|
X |
| |
|
|
|
|
| Intermediate |
|
|
|
|
| Coding guidelines fulfilled |
X |
X |
|
|
| OS guidelines fulfilled |
X |
X |
|
|
| Tests with defined code coverage |
X |
|
X |
|
| Code peer reviewed (or pair programmed) |
X |
|
|
|
| Applicable test plans created |
X |
|
X |
|
| Required refactoring done |
X |
|
X |
|
| Other rules fulfilled (e.g. SRP, DRY, KISS etc.) |
X |
|
|
|
How to verify “done”
As already mentioned, you should assure that the DoD should be measurable. To assure that you get a rapid feedback during the sprint, there is no way around an integration server. The integration server should at least build the project and run the unit tests. At build errors (or better: warnings) or failing tests, the team is informed about this.
In the sprint review, you could also show that you fulfill the DoD by checkmarks on each DoD item for every backlog item. This could be used in case you wish to “sell” that you provide high quality.
Some final thoughts
If the team is comprised by beginners, it will probably just contain a few basic items. As the team grows, it will add more items to the DoD and possibly remove the basic ones as they are taken for granted. When the team has evolved further, it may not even discuss the DoD any longer as its fulfillment is taken for granted.
Just like the team discusses a Definition of Done, it will sooner or later notice that the Product Owner should have had one as well… Often the stories in the product backlog are not mature enough to be taken by the team. In such a case you will start thinking about the “Definition of Startable”, the criteria to be fulfilled before a story is taken by the team for a sprint.
