What Scrum Master needs to know: Definition of Done
“Are we done with this?”. In the ever-changing software volatile, uncertain, complex, and ambiguous world it is often quite a challenge to answer this question. There are always opportunities to ship code that isn't yet finished - which means we can't just assume anything is done at first glance.
This why it's crucial for teams to come together and define what constitutes done on every project, initiative, or feature. All it takes is some common vocabulary - if people don't speak the same language then there will surely be plenty of confusion, frustration, and mixed signals caused by a lack of cohesion between stakeholders. To avoid this problem altogether, product teams should take the time to craft with their engineering counterparts how to define 'done' work.
Let’s make a walkthrough with the analysis of the Scrum Guide (2020 edition) as the one source of truth in the industry. There are 16 mentions in ‘Definition of Done’ and I propose to review them by clusters four clusters:
Increment
Defining Increment as a concrete stepping stone toward the Product Goal there is no surprise that it is the most DoD-heavy part of a Scrum guide and work cannot be considered part of an Increment unless it meets the Definition of Done.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
Things to be considered in this: What are the qualities we can actually measure? What is our toolset? How these metrics can be gathered and clusterized? From my hands-on experience, the most challenge with this part is defining in a simple and explicit way the answer to the questions listed above.
The moment a Product Backlog item meets the Definition of Done, an Increment is born. That’s a simple way to resolve a Gordian knot in delivery question: is that Increment or not? The answer is boolean - if it passed the agreed pipeline, whenever is finished - it’s part of the increment.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
So next time showing going up to show at Review a ‘not tested yet’ or ‘work only at dev’ product - remember those words above. It’s also might be a good idea to make some JQL queries that show Done via ruthless algebra-logical expressions to determine what is a candidate to show commitments versus actual, segregated to several buckets. It might be a ratio for Done/WIP/ToDo (in the simplest case) for at least several sprints.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriately for the product.?
With nuances of scaling, I would also add having this ‘golden standard in a short form with clean points that is mandatory (and optional if needed) at some visual and easy-to-find canvas. If that’s office - pinned to a corkboard in a decision-making place.
"The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done." Each team working with the same product regardless way to scale up (SAFe, Nexus, LeSS…) can expand common DoD, but not cut them.
Roles
Developers are always accountable for:
“Instilling quality by adhering to a Definition of Done.”
That’s directly related to Increment - we always want to have not only products that do the right things, but also products that are designed, developed, and deployed in the right way.
That is also part of Scrum Master’s accountabilities after 2020:
“Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done”. I believe that is one of the most valuable functions that a modern agile leaders can do for a team.
领英推荐
Artifacts
There are three artifacts in our beautiful framework.
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
Nevertheless, ask your sponsor what is the most relevant for the business. I’d bet that no one needs the first two without a delivered increment.
Events
Planning
The one section that doesn’t contain DoD is only the ‘Why part’, where we have to answer the qualitative question -? “Why is this Sprint valuable”. Then we smoothly go to topic number two.
What can be Done this Sprint?
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
Here we should carefully pick the real scope of work and adjust the granularity of the items to be done. If PBIs are too large - the trend of rolled-over items will lead to a long time-to-market. If PBIs are too small - customers and/or users won’t see a lot of difference and potential administrative and technical overheads can beat the actual value to be delivered.?
Topic Three: How will the chosen work get done?
For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
Here is a recommendation to set the size of subtasks to the level ‘the smaller, the better’. It leads us to a lean-kanban principle, where we don’t want to overload buffers and keep the amount of WIP PBIs in the bay so that lead time and cycle time are better. Even if there are chunks of very vague work, it’s reasonable to time-frame investigations and gathers finding rather daily, than weeks.
Retrospectives
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.
As an external facilitator, I’m very likely can find an elephant in the room doing this in the very first retrospective. Usually, stable teams discuss processes and environments, so I call you to try this approach ‘by the book’ and do it by matching Increment with DoD, if not all steps are fully automated in your’s CI/CD and covered by proper robot-gatekeeping, from code coverage in early staged, to sophisticated tests in the middle and health-checks after go-to-prod.