Quality issues? Focus on this.
Why is the Definition of Done important? How much harm can a poor or non-existent DoD do? How to build and evolve a good DoD? What’s a DoD got to do with optimizing your workflow? Adam Okruhlica, our co-CEO, explains all of it in this post.
Which part of Scrum deals with quality? I see this question pop-up quite often. It’s the Definition of Done, believe it or not. While many teams see the DoD as a second-class Scrum citizen, this can’t be further from the truth. The Definition of Done is fundamental to Scrum and must be one of the first things to set up.
Without a quality DoD:
You can never confidently say your increment is done.
Your forecasts (estimations) have limited value.
Your velocity is always zero.
You will keep running into the “one more thing” type of issues from all directions.
You will be more prone to acquiring technical debt.
Your workflows might be suboptimal and generic (and you won’t even notice).
The Definition of Done is a quality-enforcing tool
Quoting Scrum.org, “a Definition of ‘Done’ for the Scrum Team is used to assess when work is complete on the product Increment’. That means anything that’s got something to do with quality, usability, and usefulness of any qualifiable product increment fits in.
Each team will have a different DoD and that’s okay. It depends on their environment, maturity, and product. For starters, think along the following four basic categories and then add the obvious things — organizational standards and the natural good practices your team agrees on.
a) Usefulness (functional fitness)
Can include things like:
All acceptance criteria for individual PBIs (”tasks”) are passed (you can elaborate on your functional test strategies here).
No new breaking changes have been introduced.
System-wide tests have been executed.
b) Usability
Can include things like:
Integration has been completed into a “releasable” state.
Proof of performance testing, migration testing, vulnerability scans, or any other test you enjoy.
c) Quality of outputs:
Can include things like:
Peer reviews have been conducted.
Adherence to coding standards set forth by the team is validated.
Test coverage is within the agreed limits.
Technical debt is kept within the agreed limits.
Documentation is updated.
d) Compliance
Can include things like:
Adherence to brand guidelines is validated.
Adherence to regulatory standards is validated.
If needed, necessary sign-offs have been acquited.
Take this as an illustrative example, and feel free to create your own structure. Just start simple and evolve your DoD each couple of sprints. The more mature your team gets, the more quality it will be able to instill, as defined and dictated by your Definition of Done.
But don’t leave anything out! “Let’s skip the compliance requirements to not make the DoD too heavy”. That’s a no-no! Once something is mandatory, you’ll need to adhere to it eventually. Ignoring it is the worst of all lies! (Lying to yourself.)
More importantly, though, it just kicks you back into waterfall — pushing parts of work “for later” means you aren’t producing valuable, releasable, and “testable” increments frequently enough.
Keep in mind, though: Definition of Done is not the same thing as Acceptance criteria (short video)
The DoD foreshadows your workflow
Once you know what it means to have a quality output, it’s time to actually get there. Luckily, with a clear and comprehensive DoD, potential workflows emerge naturally.
You might start with an “industry-standard” workflow and keep going through your DoD, identifying the proper steps in the workflow to ensure adherence. You’ll see when additional workflow steps are needed, whether any are redundant, can be combined, or need to be split. At any rate, by the end of this exercise, your DoD and workflow will be in check.
Final tip: Keep evolving your workflow and DoD hand-in-hand
As your DoD evolves over time, it might be necessary to tweak the workflow as well. Methodically evolving these two things in tandem shows you hidden opportunities for delivering Done increments more efficiently.
Here’s an example to illustrate what I mean:
You were tasked to get a sign-off from your compliance team for each build. So, you put it into your DoD. You start out by “water-falling” the process, handing off items to the compliance team once they make it to the test environment. But you’re smart, so you make a note to revisit the process two sprints later in a retrospective.
By the time of the retro, you notice that your initial tactic prolongs the workflow and so reduces the amount of work your team is able to ship. You inspect the workflow with the team and decide to bring the compliance team into your refinement sessions. You make them mark the PBIs that will need compliance checks before they even get built.
You figure that such PBIs can either be validated upfront by complementing their acceptance criteria or need to be fast-tracked in the sprint backlog; either way, it increases your overall throughput.
Well, great job! You just optimized your workflow by finding a better way to adhere to your DoD!
When your team diligently revisits their DoD once in a few retrospectives, you will keep stumbling upon process improvements like these. Just keep in mind that each criterion of your DoD must have an identifiable place in your workflow where it is instilled and, ideally, also inspected.
I hope I’ve convinced you that a Definition of Done is important. Don’t be one of those teams that rush to implement complementary practices like user stories, story points, and velocities without the critical foundational pieces in place. Be a professional Scrum team and have a high-quality DoD!
The 5 takeaways
I’ve made some notes for you:
Gather your team and create a Definition of Done as early as possible.
Start small and grow and maintain it every few sprints at the sprint retrospective.
Ensure your DoD is visible to all team members and stakeholders to obtain a shared understanding of being “done”.
Don’t ignore mandatory steps in your DoD to defer them “to a later phase” — you will shove the incremental benefits of Scrum into the gutter.
Evolve your workflows along with your DoD.
