You’re starting a new Scrum team. Before you start working, you decide on your roles. You decide on your events. You start planning out your backlog. And you create your Definition of Done (DoD).
Sound familiar?
It did for me too. And then I found a different way.
What is a Definition of Done?
Scrum Guide definition: a formal description of the state of the Increment when it meets the quality measures required for the product.
My definition: a set of criteria that must usually be met for each piece of work to be considered complete.
On teams I’ve worked with, we’ve included things like, “passes code review,” “passes unit tests,” “has been design reviewed,” or even, “team agrees it’s done.” It’s going to be different for every team.
Definition of Done vs. Acceptance Criteria
Definition of Done is a Scrum concept, while Acceptance Criteria comes from Extreme Programming (XP).
The Definition of Done is a persistent set of criteria that can be met by most pieces of work for the work to be considered complete. It applies to every single product backlog item.
Acceptance criteria – or conditions of satisfaction – are different for each product backlog item. Examples include, “measures 3′ x 6′,” “flashes twice,” “has been reviewed by Legal.” You don’t need every piece of work to do these things. Just this specific one.
How do I create one?
As a Scrum Master, I used to create the Definition of Done as part of a Liftoff exercise for new teams or teams who were just getting started with Scrum. We’d get together as a team and think of all the things that we possibly needed to do to complete any piece of work.
Looking back, that doesn’t make a whole lot of sense to me. We hadn’t even started doing any work yet. How could we know what we needed for it to be done?
Now, I create a Definition of Done incrementally. As we start working together as a team, “should”s start coming up in conversation. “We should make sure all tests pass.” “We should have the code reviewed by two team members.” “We should be sure all of the acceptance criteria is met.”
I listen for the “should”s and I bring them up to the team. “This sounds like something that might be useful for our Definition of Done. What do you think?” If the team agrees, I add what we talked about to the DoD which I keep transparent and readily available, usually on a team’s Confluence page.
Updating the DoD
A team’s DoD is iterative, meaning you add to it as you go along, modify the language, and take out anything that isn’t serving the team.
For example, if having code reviewed by two team members is slowing the team down, the team may discuss changing the review to one person.
Not every criterion in the DoD will apply to every story. Not all work will involve coding or design or needing to be reviewed by certain people or teams. If it’s important enough to at least be considered before work is completed, it should remain in the DoD.
How do you DoD?
Waiting until we’ve actually started work to come up with how work is considered done has helped me in saving time and guesswork. And there’s no “right way” to come up with a Definition of Done.
How do you DoD?
Photo by Eden Constantino on Unsplash
FOR ONCE some one agrees with me (and I love that as I’m always right. 😀 ) Over and over I’ve been told DoD doesn’t change, like it’s a fixed absolute that if interrupted will damage the time/space continuum. Using simple design sprints, you can (as Eric Ries states) “Fail Early, Fail Often.” You start, fail and learn as you are trying to find the true direction of your product. Assuming you know everything up front is rather BDUF and is, as we know, almost always wrong. In the beginning, your product is an idea and all you can show your customer is proposed stuff which may fail. But it’s OK as the idea is to get feedback. So in the beginning, DoD should be “Up and Staggering”. As the product direction starts evolving and you have more solid ground to build a product closer to the customers stated feedback, DoD will become more complete, making sure the product aims for greater stability and that quality code is delivered.