Jory MacKay on May 28, 2020 5 Steps to Find Your Definition of Done (With Examples and Workflows)
There’s a saying in the music industry that the easiest way to ruin a song is to keep working on it. Add enough effects, extra guitar parts, or more cowbell, and you’ll turn Woody Guthrie into Guns N’ Roses.
Knowing when a piece of art is “done” is subjective and often difficult to define. But that can’t be the case with your project.
Without a clear definition of done, your development team doesn’t know what they’re working towards, your stakeholders are free to increase the scope, and your users most likely end up with a product that’s cluttered, confusing, and unusable.
On the other end, a clear Definition of Done (DoD) is one of the most important elements of Agile product development. If the goal of Agile is to ship usable software, then you need to know what that looks like before you can even start.
Jump to a Section:
Starting at the end—by defining what needs to be “done” before you can ship—brings clarity to the entire process, provides a shared language, and creates a clear threshold of quality (to guard you from both project apathy and perfectionism).
So how do you come up with a Definition of Done that works for everyone? In this guide, we’re going to cover exactly what a DoD is (and isn’t) and how you can develop, track, and update them as a team.
What is a Definition of Done (DoD)?
Asking a developer if they’re “done” with a feature can sometimes be about as productive as asking a politician for a straight-forward answer. “Done” in this sense, could mean finished programming, testing, deploying, documenting, or any combination of these.
The same goes for your product or feature. Is “done” finishing an MVP? Shipping pixel-perfect features? Or is it something completely different that only you know?
For your team to move forward, hit your goals, and ship usable software, you need to know exactly where things are in the product development process and where you’re aiming for. That’s where your definition of done comes into play.
According to Scrum.org, a definition of done (DoD) is a shared understanding of expectations that the current sprint (or increment) must meet in order to be released to users.
In other words, what quality level is your team striving to hit with this current sprint? And, maybe more importantly, how will you measure it?
With this as our definition, we can think of the goals of a definition of done as:
- Building a common understanding within the team about quality and completeness. This is especially important during the sprint planning process as you need to know what you’re working towards.
- Providing a checklist of criteria to check user stories against. This can be a huge timesaver in the future as work won’t (hopefully) need to be redone or updated to meet user’ needs.
- Ensuring that the increment shipped at the end of the spring meets the quality level that your team and the project owner agreed upon. Not only does this keep everyone happy, but it protects you against scope creep. If a request is outside the definition of done, it’s much easier to set expectations and move it into your product backlog or a future sprint.
Most of all, a definition of done lets your team actually finish what they’re doing and move on. A clear definition of done is the X on your treasure map. Without it you have no idea the right time to stop
Without a clear goal post, unfinished work easily piles up and you end up with a stack of “work debt” that needs to be repaid before you can move forward.
Definition of Done vs. acceptance criteria
Where people often get confused is in thinking that their definition of done is a quality control issue and not a project management one. Why not just use your acceptance criteria to determine when a project is “done?”
While both acceptance criteria and your definition of done help determine when a piece of your project is finished, there are key differences in how and where they’re used.
A simple way to differentiate the two is that a definition of done is universal. It relates to everything your engineering team is shipping in the current sprint.
On the other hand, acceptance criteria is unique to the user story, feature, or issue in question.
Here’s how this might look in practice.
One of the most common areas where you’ll use a definition of done is when shipping a user story. As a quick reminder, a user story is a short, simple feature description told from the perspective of your users and customers. For example:
“As a [type of user] I want [some particular feature] so that [some benefit] is received.”
In order for a user story to be deemed “done” you need to check off a number of items:
- Unit test passed
- Code reviewed
- Acceptance criteria for each issue met
- Functional tests passed
- Non-functional requirements met
- Product owner accepts the User Story
Only once all of these criteria are met can the user story be called “done”. However, in order to reach that, each issue needs to meet its individual acceptance criteria.
Think of these as different layers of specificity. A definition of done applies to all the user stories in your sprint, whereas each one will have its own unique acceptance criteria it needs to pass in order to be deemed ready to ship.
The same goes for other levels of development. For example, your definition of done for a feature will most likely include additional requirements such as it being integrated and deployed into a clean build.
How to create a definition of done for your feature, project, or task in 5 steps
People often have different ideas of what needs to be done, and getting your entire team on the same page isn’t always easy. But even more difficult than deciding on a definition of done is keeping people accountable to the contract.
Asking a developer if they’re “done” with a feature can be about as productive as asking a politician for a straight-forward answer.
So how can you ensure your team respects the DoD and acceptance criteria you’ve agreed upon?
It starts with engaging your entire team in the process and then making the requirements clear, actionable, and always available.
1. Decide on your definition of done as a team
Who defines “done” for your user story/feature/project?
While defining “done” should include input from the product team, quality control, and relevant stakeholders, it’s ultimately up to the technical team to decide what it means.
However, this has to be a collaborative process. Without input from other teams you won’t get the support you need to ship a feature. You’ll also be stuck dealing with stakeholders who have different expectations or are confused as to why a feature hasn’t shipped.
To help this along, it’s essential that your definition of done is available to everyone and that there is transparency around why those are the requirements you chose. This way, everyone knows why a release or feature is held up and what needs to be done to move it forward.
Different companies and development teams will decide on what “done” means to them. However, in most cases, “done” comes back to the same golden rule: The code does what it’s supposed to and doesn’t break anything else in the process.
That’s a bit vague. So let’s look at some basic examples of definition of done criteria to help clarify what this looks like in practice:
- Code is written. The most basic thing that needs to be completed for any user story or issue to be “done” is that it’s built.
- Code is documented. At this level, you most likely want to have some developer documentation finished and made accessible. Depending on the size of the project, you might also want to create some form of help documentation for the handoff to support (who will be answering questions about the release to users).
- Code review has been completed. As part of your sprint, you’ll want to get your code ready for review with clear metrics (and acceptance criteria) set. To be “done”, the code needs to be checked by your team for any issues or bugs.
- Build has been made and deployed on a testing environment. Your definition of done needs to expand beyond just the scope of writing code. By including a deploy in it, you’ll help keep your sprints on track and also keep the end goal in mind for developers.
- Tests have been passed. Does it work? Before you can be done, you need to make sure you’ve gone through your test plan and make sure you didn’t break anything else in the meantime.
2. Create a checklist template for your definition of done
With a clear definition of done in place, you need to ensure that these rules apply to every applicable task or issue in your sprint. Whether it’s a huge feature release or a bug fix, it needs to go through your “done-ness” checklist.
This is where many teams fail.
In the pressure to get through a sprint, it’s easy to ignore the larger definition of done and focus only on the acceptance criteria for each issue or feature. And while this might give you a bunch of functional pieces, they won’t come together into a finished whole.
Most of this comes down to awareness. How can you make sure your team always has the definition of done front and center while they’re working?
The answer is simple: embed it into their workflow. And what better place for this than in your project management tool?
Here’s a great example. With Planio checklists, you can create a template for your Definition of Done items as well as acceptance criteria to be used on each user story.
To do this, head to your Planio account, and in the Administration section select Settings → Checklist templates and create a new global checklist template. This can also be done for specific projects within the Settings for that project.
Choose a name that makes sense for the checklist and then choose whether you want it visible to only you or all users. You can then choose the tracker you want it associated with and then add all the items that should be included.
Lastly, you can set this checklist to default on each issue. This way, whenever your team is working on an issue, they’re reminded of what they’re working towards. With a checklist like this, your DoD items are always front and center and your team doesn’t get sucked into tunnel vision.
3. Don’t obsess over the list of criteria
As your team decides on their definition of done, it can be easy to get carried away with thinking through what an ideal version looks like. And while this is a good exercise, you have to be realistic with what you include in your criteria.
Earlier, we called the definition of done a “shared understanding” between the development team and the product owner. But too many DoD items will split your team’s attention. They’ll have too many different factors on their mind, which will lead to one of two outcomes:
- They’ll only work on a small subset of DoD items
- They’ll try to do everything (and most likely fail)
A good rule of thumb is to think of your definition of done as the minimum work required to meet your agreed-upon quality level.
In the words of award-winning film director James Cameron, this is making sure you’re doing the “right” things:
“People call me a perfectionist, but I’m not. I’m a rightist. I do something until it’s right, and then I move on to the next thing.”
What “right” means might change over time. Which means that you should be managing your definition of done over time and reviewing it to see if you can remove criteria.
In the end, done is always better than perfect.
4. Make sure each individual task has its own specific acceptance criteria
We talked before about the difference between acceptance criteria and your definition of done and how both are needed in order to successfully finish your sprint or call a user story complete.
As you work through your sprint planning process, make sure each issue includes relevant information and acceptance criteria. Again, this is a great place to use Planio checklists.
Not only does this make sure your team knows what they need to be working on, but it makes it that much easier to clearly tick off the “acceptance criteria met” portion of your definition of done.
5. Check your DoD against organizational needs
In pretty much all cases, the definition of done should be set by the entire scrum team. In Agile, your team is solely responsible for turning your product backlog into sprints and usable software.
However, the problem is when you get too focused on the task at hand and forget about the larger goals, needs, and conventions of your company. A definition of done will occasionally need to be checked against your core values and principles to make sure no glaring issues are being missed.
Here’s an example that Agile coach Willem-Jan Ageling uses of a product team tasked with building a new app for a financial institution.
“The app was a success but it shipped with a security breach.” Always make sure your definition of done is checked against your core values and compliance issues.
While the app itself was a success (based on the development team’s definition of done and user feedback), it shipped with a security breach that showed sensitive user information. Not good.
But just how could an app get shipped without checking these compliance issues?
Even though the company execs wanted to believe everyone shared and understood the company’s values, that’s not always reflected in a definition of done. The technical team’s focus is on building usable software not worrying about compliance issues.
As you’re defining the criteria and checklist for your DoD, make sure to take a step back from just the technical aspects and think about the company as a whole.
Speak with your stakeholders or the project owner and ask if there are other issues that will stop this increment from being truly “done” that you aren’t thinking about.
When can the development team change the definition of done (and how should they do it?)
One of the best things about Agile is just how quickly it allows your team and your product to adapt to the user's needs. However, one thing that doesn’t change as easily is what’s considered “done.”
Shifting your definition of done constantly can kill the benefits it brings and add confusion to your sprints. But what if some important factor changes or your team matures and realizes your DoD needs to as well?
While there’s no precise answer to when the development team can change the definition of done, this section from the Scrum Guide gives a bit of guidance:
“During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of ‘Done’, if appropriate and not in conflict with product or organizational standards.”
A good rule of thumb, is to be open to discussions about your DoD during the sprint but leave any changes for during either your sprint planning phase or during your retrospective.
In the end, a Definition of Done is all about trust
There’s one final reason you should care about a definition of done: It builds trust across your team and your entire organization. A shared, open, and honest vision of what quality software looks like puts everyone on the same page and avoids the headache of hearing “But I thought we were building [X]!”
Collaborate as a group to define what “done” looks like, use checklists and project management tools like Planio to keep it front and center, and your team will be well on the path to continuously building higher quality software.
