Definition of Done

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 job done. The perspective is general for all items that are to be delivered – usually, 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 specific 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 whiteboard. 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 an excellent 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:

The team has to discuss, negotiate and conclude on the proper work steps. As a result, the team earns a clear understanding of „done“ software in a 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 immediately access it. Make it explicit. Stick to it.

The team can modify the contract of the Definition of Done after each iteration. These discussions have a significant impact on making the flow of work visible, on seeing if the team can do the work 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 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 the team cannot perform some work steps, 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 provide a hint that the team structure is not optimal to get the work done.

The delivery team as a whole is responsible for performing the work steps and for delivering „done“ work. Albeit, usually for some tasks specialized skills are needed, and only some of the team members can 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 the 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 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 can 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 can 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 proper skill sets or roles beside the work steps.

If members of the team cannot fill some roles – because of a lack of skills or because no member will take over the responsibility coming along with the role – you may have found an organizational dysfunction. Identifying the root cause is worth it. Why is the 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 approved by the Product Owner. For strategic estimation of Scrum User Stories with Story Points it is also crucial 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.