Definition of Done
The Definition of Done (DoD) is not only a checklist that has to be executed to get a piece of work delivered. In fact the DoD and the path to its determination opens a space for agile thinking and acting which can actively be leveraged by the delivery team and the surrounding organization. It is a great entry point for agile delivery and it can be used in Scrum, Kanban or any other procedure with iterated delivery.
To answer the simple question „When is a work item done?“ will produce insights into the flow of work. At first, this question should be discussed and negotiated by the team who wants to get the work done. The perspective is general for all items that are to be delivered - normally the team has only one DoD that will be used for all of those work items. That means the team will think about the general good flow of the majority of work items and not about every exception that may occur or every specialized work item that needs some other work steps.
For a start, the chain of work steps is of interest. Collect the steps for example on sticky notes and put them on a wall or a white board. This will show unnecessary, missing or insufficient steps. Do it among the members of the delivery team - when leveraging Scrum with the entire Scrum Team, including Scrum Product Owner. It does not take a lot of time and it is a good exercise to bring the people together. The produced result is something that the members of the team can identify with and that can later be referred to.
E.g. a short list of possible steps that are needed to get a piece of software done might be:
|Requirement in User Story syntax|
|Discussion about solution|
|Acceptance criteria met|
|Automated unit tests|
The team has to discuss, negotiate and conclude on the suitable work steps. As a result the team earns a clear understanding of “done” software in the specific context. This is an important contract to ensure not to break the product during iterated delivery and to have defined quality for any “done” piece of software in each iteration.
Write down your current Definition of Done and provide it somewhere so that anyone can immediatly access it. Make it explicit. Stick to it.
The contract of the Definition of Done can be modified by the team after each iteration. These discussions have a huge impact on making the flow of work visible, to see if the work can be done by the team and to unhide bottlenecks. But be aware not to make the DoD so thin that at the end a piece of work that fulfills your DoD is actually not done. Remember, almost done is easy, but that is not done.
This will show very soon if the right people with the right skills to deliver are in the team and what the interfaces and dependencies to the teams outside world are.
If some work steps can not be performed by the team, it needs to be decided if the team has to reshape with different team members or if interface contracts with external providers are to be concluded on. The definition of interfaces will anchor the team inside the surrounding organization. This not only makes clear the external dependencies of the team, but also gives a lever to change the organization. Many external interfaces give a hint that the team structure is not optimal to get the work done.
The delivery team as a whole is responsible to perform the work steps and to deliver “done” work. Albeit, usually for some tasks specialized skills are needed and only some of the team members are able to perform these tasks. This is backed up with some good reasons. E.g. the appropriation of the relevant knowledge takes a lot of time and energy - sometimes a work life - or because the task is so complex that interdisciplinary collaboration of different team members is required. To understand team responsibility in terms of everyone in the team can do everything is an error in reasoning. Instead the team should focus on fearless communication and leverage different talents. Use the differences and find ways to come together. Heterogenous tasks demand for heterogenous teams. Keep up the professions because the work ethics that typically come along with a profession will enhance the teams capabilities.
I do not speak for total specialization with only one specialist for each work step. Where ever possible, work should be performed by the next team member who has capacity to do it. Everyone should be prepared to help out each other. But to demand everyone in the team being able to do the same things, in my impression would mean that the team can do only average work. Talents in their specific area of competency are able to perform better and achieve more.
Sometimes it is of help to write down some professional roles that are needed to fulfill the tasks. The list with the work steps could be extended by writing suitable skill sets or roles beside the work steps.
|Requirement in User Story syntax||Domain expert|
|Discussion about solution||Domain expert and team|
|Test cases developed||Test expert and domain expert|
|Acceptance criteria met||Developer and domain expert|
|Database changes||Developer and database admin|
|Automated unit tests||Developer|
|Translations||Translator and domain expert|
|User tests||Test expert|
|Documented||Editor and domain expert|
If some roles can not be filled by members of the team - because of a lack of skills or because no member will take over the responsibility that comes with the role - you may have found an organizational dysfunction. It is worth to identify the root cause. Why is role so difficult to fill? What can be changed?
The Definition of Done is a list that is of help for the Scrum Product Owner to validate work results at the end of a Sprint and to decide if work will be accepted or rejected. At the same time the Scrum Development Team is aware from the start what needs to be done to get a piece of work accepted by the Product Owner. For strategic estimation of Scrum User Stories with Story Points it is also important for the Development Team to know what work steps are to perform in general.
Start where you are now. The Definition of Done can be the first step of your agile journey. Stick to your DoD and deliver.