Let’s assume you are working on developing a user story. At which point can you wrap up and heave a sigh of relief, considering that you have finished with it? When an Agile product is continually evolving, it’s hard to agree upon the exact moment when you can consider that your work on a particular user story, epic or feature is completed, and you can move on to the next one.
Therefore, it’s very important that the team must agree on what can be ‘done’, and the Definition of Done is key to arriving at this consensus.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. — Scrum Guide
Everyone on the team must be on the same page when it comes to what, exactly, qualifies as ‘done’ in different scenarios. To avoid any ambiguity, the team agrees on the Definition of Done— a set of items that must be satisfactorily completed for the user story, feature or even the whole project to be wrapped up. Once these criteria are ticked off, the item moves from being ‘in progress’ to ‘done’.
Each team will have their own list of criteria that should be checked off, and these will differ from project to project. What is important is that these criteria must be clearly documented so that there is no confusion as to whether something is completed or not. This also increases transparency across the board. When one or more boxes are still left unchecked, the team knows what’s left to be done.
While it is the technical department or the Scrum Master who is the lead on creating the Definition of Done, it cannot be defined unilaterally, and must be a collaborative exercise in which the entire team participates. Not just the team, but the product team, quality control team and other stakeholders will also have to give their approval of these criteria.
Once created the team will display this Definition somewhere in the room so that everyone can see it and know the criteria, they must work toward accomplishing.
The image below shows what a team’s Definition of Done could look like, as an example.
Product Managers, even the non-technical ones, realise that the Definition of Done creates transparency and accountability, as it offers a clear understanding of the work that has been completed during the Increment.
For a Product Manager the Definition of Done means that every bit of incremental value created performs within specifications and to expectations and is stable. It also means that code has been peer-reviewed, has been verified with the users and is in a shippable state. Teams could also have listed out their own variants for ‘done’ that include completion of release notes and user documentation, among others.
If there are any open issues at all, then the item does not meet the Definition of Done and is set back to the backlog, to be taken up again in an upcoming sprint. It cannot even be discussed during the Sprint review, and it certainly cannot be released. Such open items will affect the team’s velocity as they cannot be complete.
The Definition of Done is like a To Do checklist that can be used to guide the implementation of code. It helps define the estimates and forms a structure for the design activities.
It cuts through any ambiguity, limiting any rework that could potentially be needed if the team is not clear about what constitutes ‘done’. As a result, costs due to such rework are curtailed.
It adds explicit clarity and articulates the idea of what is considered ‘done’, thereby reducing any confusion and misunderstandings that could otherwise crop in between team members and the PO or stakeholders.
The team should not keep arguing over the list of criteria as it can be counterproductive. It can be agreed upon that the list will have the minimum criteria required for a product increment to be shipped.
Additionally, a feature or story could have its own specific ‘done’ definition, which might be adding something to the general criteria.
A common pitfall is if the Definition is vague and not an explicit contract that is clearly documented. In such cases, team members could start to argue about their own understanding of what ‘done’ meant and the whole concept could turn out to be ineffectual.
As long back as 2002, Bill Wake wrote an article that brought public attention to inconsistencies that arise when the team was not clear about what constituted ‘done’, and each team member used their own terminology for the same.
The very next year, in 2003, Scrum training materials had a slide that was titled “The story of Done”. Later versions of these training materials had exercises that asked trainees to consider about what the definition of done meant for them.
By the year 2007, the “Definition of Done” had been established as a best practice and from then on, the use of the term spread.
A team should, under ideal conditions, look to the Definition of Done at the end of every sprint to see if a unit of work can be counted towards the calculation of Velocity or not. If it is yet to be completed, then it cannot be used for this calculation. On stakeholder request, the team should be able to show that all the criteria listed out in the definition have been met.
The Definition of Done gives the required confidence to the team to wrap up and sign off on an increment as being completed in all respects. However, in Agile projects you’re never really done until the final Ts have been crossed and is have been dotted. If there is any change necessitated due to user feedback or are any changes in business models, the team must be prepared to revisit the definitions set earlier and accept the changes wholeheartedly. After all, that’s what Agile is all about!