Have you ever found yourself embroiled in a discussion (or perhaps argument) with your team about whether something is done?
Does the answer to the question “is it done?” differ depending on whether you ask a designer, developer, or tester?
Do have the same conversation over and over again about what testing and document you need to do for a backlog item?
If you answered “yes” to one or more of these questions, your team needs a definition of done.
In agile, the definition of done is an agreement between a product team on the set of conditions that must be true in order to consider backlog items truly done.
Product teams use a definition of done to bring consistency to the activities they perform for every backlog item. As a result, a clear definition of done can be used to get a feel for a team’s software development approach.
A definition of done usually clarifies how much testing your team plans to do as part of developing a backlog item. Does your team only unit test backlog items, or do they unit test, functional test, and even perform regression testing for each backlog item? The testing question can generate a lot of concern within your team. To address those concerns, establish an initial set of tests, try them out, and then see how things turn out. Your team can then adjust your level of testing and revise your definition of done accordingly.
A definition of done helps your team decide how to address documentation. Does your team update any relevant documentation with each backlog item, or do they plan to update documentation in one fell swoop in the infamous “later”?
A definition of done may address who — if anyone — needs to sign off, or at least provide feedback on the work your team did. If there is some signoff needed, who do you need it from?
A definition of done may identify to which environments your team deploys the code for each backlog item. Some teams include deployment to production in their definition of done. Other teams that are not in a position to deploy to production at the end of each iteration may include deployment to a preproduction environment instead and have a separate set of release criteria that indicate what needs to be true before releasing code to production. These release criteria are often applied to the results of multiple iterations.
The definition of done is not intended to be exhaustive, nor is it intended to be a set of rigid rules where all the criteria absolutely have to be done for each item no matter what.
Your team should discuss what must be true in order for them to consider a backlog item satisfied and establish that as their definition of done. The list is not final, and your team may find occasion to review and revise it at a retrospective.
Aid sizing and planning
When your product team understands the expected amount of testing, documentation, and deployments involved with a backlog item, they have fewer uncertainties to consider when sizing backlog items.
Your team also knows many of the tasks that are necessary to deliver a backlog item so they can plan accordingly.
Avoid repetitive conversations amongst your team
When you have a clear definition of done, your team doesn’t have to spend a lot of time deciding what testing they should do, whether they should update documentation, and what environments to go to. They have an agreement to fall back on.
You also can avoid long, drawn-out discussions about whether a backlog item is done or not. When you want to know if a backlog item is done, just compare what activities have been completed with what your team agreed to.
Provides insight into your team’s development approach
A well-crafted definition of done is in effect a summary of your team’s development approach. Establishing the definition of done helps structure the conversation your team has to initially establish their approach. You can review and improve that approach by reviewing and approving your definition of done.
Reduces rework
The definition of done limits the cost of rework once a backlog item is accepted as “done”. If you have an explicit contract for done, you can limit the risk of misunderstanding and conflict between you and the rest of the product team that leads to errors.
As alluded to above, the definition of done summarizes your product team’s approach to product development, and does it in a way that is meaningful to people without in-depth technical understanding.
When you understand what the items on the definition of done mean, you know what you can expect your product team to do for each backlog item. That provides certainty around how thoroughly you can expect a particular item to have been tested and you also know whether to expect documentation.
A solid definition of done also allows you to focus on the problem a backlog item is trying to solve and related acceptance criteria. You don’t have to repeatedly discuss what testing or documentation should be done for a particular backlog item.
You can use the definition of done to establish expectations about your involvement with backlog items as they are being developed. Are you expected to sign off on the work done for a backlog item? Do you need to line people up for testing purposes? If your team is updating technical documentation for each backlog item, are you going to do the same thing for marketing and sales documentation as well? When you clearly understand what the team expects you to do for each backlog item, you can plan your time accordingly.
Here’s a definition of done you may expect a team working on a new product to have:
Gather the team together and explain that you want to agree on the activities that must happen for a backlog item to be considered done. If you are able to meet in person, gather the team together at a whiteboard and make sure everyone has a pad of sticky notes and a marker. If you have to meet remotely, share a Google Doc or some other tool that supports virtual collaboration.
Identify items that they think the team should do when delivering a backlog item. If you’re face to face, have everyone write their ideas on sticky notes, one item per note. If you’re remote, have everyone type their thoughts into the collaboration space.
Once the energy for adding new items seems to die down, go back and review the list. Ask the team to consider whether it’s reasonable to expect all of the items they suggested for every backlog item. You’ll want to group any duplicates together and clarify items that someone wrote and there is uncertainty around.
Continue revising the list until the team feels comfortable with the resulting list, which will generally be shorter than the first one. This final list forms the team’s initial definition of done.
On an ongoing basis, use the definition of done as a check to determine whether a backlog item can be delivered to stakeholders.
Don’t create a definition of done that is not practical.
An excessively long definition of done can be counter-productive. The list needs to define the minimum work generally required to finish a backlog item. There may be some types of backlog items that have additional “done” criteria in addition to the general criteria. Don’t weigh down some backlog items with extraneous items in your definition of done.
Make sure there’s a shared understanding of the definition of done
If the definition of done is merely written on a wall but not followed it’s of no use. Likewise, if different members of your team interpret aspects of the definition of done differently. A large part of the benefit of a definition of done is that everyone on the team shares the same understanding about the items on the definition of done and follows them.
