.png)
This blog is an adaptation of a recent workshop with a current client.
Imagine you are at the final stage of a big product release. You’ve got all the user stories and the code promoted into the staging (testing) environment, and you do the big swap to get the code into production. It’s there. It’s live. It’s in the user’s hands. You’ve done it! Onto the next big feature.
But. The users don’t adopt your new features. It’s buggy. They don’t know how to access it. So, are you done? The answer is no. What went wrong? This is why having a good definition of done is so essential.
The definition of done for a team seems simple enough but is actually quite complex when done well.
“The Definition of Done is an agreed-upon set of items that must be completed before a project or user story can be considered complete. It is applied consistently and serves as an official gate separating things from being “in progress” to “done”.
There should also be an element of transparency since everything can be tied back to that done-ness checklist. If a release or feature hasn’t checked off all the boxes, then it can’t move forward and everyone knows why."
- ProductPlan
When looking at this definition, many people focus on the word “done” or “list”, but the most important word is actually “agreed”. While a good definition of done has a checklist of conditions that must be considered and met to mark a user story as done, the most important emphasis is on the agreement for the items that are on the checklist itself. If a team isn’t aligned on what components make up a good definition of done, then they may view the list as unimportant, be uninvested in checking the items off the list, or even view them as entirely optional. In fact, a definition of done will allow your team to know that you’re putting quality value into the hands of your users, and provide a clear picture of what is most important.
.png)
Here are a few examples of the value of a good definition of done:
.png)
.png)
While the definition of done is important for agile teams, it can apply to much more. Here are a few tips to make any definition of done useful for any team:
When that aforementioned checklist is handed down by one person, it feels much more like a box to check rather than a set of tasks to complete that measure success and completeness. Let everyone on your team have a voice in building the definition.
This becomes burdensome for them, and it feels like a checklist of doing their job. A definition of done contains items that hold the responsibility of many functions. For software, this can look like the designer running a UI review, the PM testing and accepting a story, and marketing submitting their updated materials.
As you get more comfortable checking off the items, coordinate with your team. What can you automate? What can we add or remove? This should stay fluid over time. Don’t be afraid to speak up when the “definition” needs updating.
The easiest way to forget something is if it’s out of sight. Plan to check in your team’s definition of done frequently, and confer with your team on what constitutes Doneness.
Regardless of whether you’re part of a software team, marketing, operations, or HR, the definition of done can help you define success and clear your mind to begin a new task. Remember that every time you complete this list, you get to celebrate a win. And don’t forget it’s adaptable!
Your definition of done should fit the needs of your organization and team, not someone else's. So you can rest easy knowing that checking off your list gets you one step closer to your product goals. And finishing up that house cleaning.
Resources:
Check out these other posts from our team.
Engineering Coach
.png)
.png)
Business & Acquisition Coach
Engineering Coach
