I recently prepared a workshop with a colleague. In terms of content, we quickly agreed on what it should be about, all that was missing was a Powerpoint presentation. In order to be able to work on the presentation as efficiently as possible, we divided it thematically. When we sat down to talk through the finished draft, a major problem emerged: We had very different ideas about what a "finished draft" actually was.
This problem can also arise with agile scrum teams. A team can come to the end of the sprint after two weeks, but could still be at a disagreement as to whether the product can already be finished, and moved from “in progress” to “done”. This disagreement leads to discussions, which in turn could negatively affect the climate in the team. To prevent these discussions and to protect effective teamwork, there is an artifact in the scrum world called “Definition of Done” (DoD).
What is a definition of done?
Literally, as well as in agile, the definition of done means “what it means for something to be finished”. So it's about a team agreement on what needs to be done for a feature to be considered finished. In practice, the definition of done can be presented as a kind of checklist, which is used during the sprint and especially at the end to check whether certain completion criteria have been met. For software development teams, these criteria could include the following:
- Documentation was created.
- The code is fully implemented and annotated.
- A code review was carried out.
- ...
Why is a definition of done important?
The fact that setting goals is of enormous importance for performance is not particularly new knowledge. Goal setting is a highly researched topic in psychology (cf. Locke & Latham, 2006). It has been shown that performance is at its highest when goals are formulated as specifically as possible, and challenging without appearing unattainable. However, the definition of done is not a method of goal setting (but if you need support with goal setting , we are here to help); it is rather about criteria that must be met in order to achieve your goal.
These criteria are important in order to create a common understanding within the team. An understanding of what each team member has to do to achieve a common goal. So it's about individual achievements that ultimately combine to form a team effort.
If you look at the topic of DoD from the perspective of a product owner, completely different problems emerge. If it is not clearly defined when a product increment is considered finished, there may be inconsistencies when the product is presented to the client. If this happens and an incomplete product is presented, it is unlikely that you can get feedback form your client anymore.
Continuous improvement
Since a definition of done is not a static concept, i.e. it can and should be continuously developed or changed, it also offers the team the opportunity to learn. If the team notices at the end of a sprint that they could not meet the criteria of their original definition of done, the team members can either adjust the final definition to accommodate their performance, or draw conclusions to begin their next sprint and change their way of working.
The team should carry out these "definition of done" reflections as part of the retrospective. Possible echometer itemsthat can be queried in the preparation stages are:
We have clear definitions of done for our requirements.
I usually know where we are in achieving our common goals.
My goals are aligned with the goals of my colleagues.
The team covers all the skills we need to achieve our goal.
They not only question whether there is a definition of done in the team at all, but also how transparency, autonomy and role clarity are in the team.
You can find the complete item pool in our Retro tool.
How can our team define "done"? An example of a workshop
We showed you what a definition of done is, and why it is important for effective collaboration in scrum teams. However, if your team has not yet created a DoD, you may still be wondering how it works.
In principle it is important that the team spends quality time on the setup. At the end, a document should be created with which each team member can identify, and which is not only seen as a necessary evil. That is why we recommend a workshop-like format with a scrum master as moderator. Each team member should think about which criteria are important for the completion of the product, and the team can summarize these thoughts together. Similarly, we have developed a workshop format for goal setting. Take a look hereto get ideas for your definition-of-done workshop!
The completed DoD can be used in retrospectives, for example in the form of the definition of done traffic light:
- Write down your criteria for the definition of done as a list.
- Draw a red, a yellow and a green field next to each criteria.
- For each point of the definition of done, each team member marks whether it was implemented well in the last sprint, average or badly.
- Discuss the three with the most frequent answers in the red area.
- If necessary, adjust your definition of done.
Conclusion - done?
Using few words to conclude: there is no such thing as “finished” in an agile environment. Done simply means that something is ready for the time being, but further adjustments and improvements can and should follow at any time. That is one of the many beautiful aspects of agile work: continuous improvement.
What can be particularly suspenseful is that sometimes points are “done,” until the client then questions the whole solution and shakes up your foundation of assumptions about customer needs. In such situations, it can be seen whether the team has really prioritized customer benefits over progress in the ticket system.
A clear definition of done can avoid conflicts and increase your performance. If you are interested in other ways to achieve this goal, you should also check out our article "the amazing truth behind the agile mindset" . Or enrich your retrospectives by taking into account the latest scientific findings from the field of psychology.
It was with this promise that we developed our retro tool Echometer. If you are interested in how (and whether) Echometer works, please read Holger's experience with our tool:
Do you want to take your team to a performance level? Our retro tool can help you. Here are Holger's experiences with it:
References
Locke, EA, & Latham, GP (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15 (5), 265-268. https://doi.org/10.1111/j.1467-8721.2006.00449.x
