We Haven’t Defined “Done”

Many teams struggle to create a definition of done. Without such a definition, the team loses transparency into the product increment, and all sorts of problems can arise:

• The product owner won’t understand the level of completeness of each feature or how much time the team needs to release the features to customers.

• The development team will struggle to measure its velocity or progress within a sprint due to increasing technical debt and an incomplete understanding of what “done’’ means.

• The product backlog is likely incomplete because the Scrum team isn’t sharing and frequently reviewing testing requirements, nonfunctional requirements, and organizational standards.

• The development team won’t know how many product backlog items to select during sprint planning. Product backlog items that seem simple could cause big problems that remain hidden until late in the sprint. Testing and integrations can significantly increase complexity.

• The stakeholders won’t understand what could potentially be released to customers.

These are just a few examples of how a Scrum team can lose transparency without a shared understanding of what done means. Without transparency, inspection and adaptation mean nothing. When the Scrum team isn’t working toward done, they lose sight of the Scrum values.

Here’s a format that many teams use to facilitate creating a definition of done. You’ll need a whiteboard, sticky notes, and markers. Follow these steps to give your team a great starting point that they can use, learn from, and improve over time.

1. Consider when certain tasks need to be done. For example, it might make sense to list tasks that are completed at the product backlog item, sprint, and release levels. Decide as a team which categories make sense for you.

2. Using your categories from step 1, create areas on the whiteboard where your team can brainstorm tasks that fit into each category.

3. Give each team member a stack of sticky notes and a marker. Ask them to spend five minutes writing down as many tasks as they can think of for each category. At the end of the five minutes, ask each person to place their sticky note in the space designated for each category.

4. Work with the team to eliminate duplicates and to clarify what each note means. Consider giving team members a chance to move sticky notes and create new ones. This can help keep everyone engaged and interested in the discussion.

5. Make sure the team is considering more than just coding activities. (Your product owner can help with this.) For example, did the team consider business issues? Are service-level agreements in place? What about company standards and policies? Considering these aspects helps ensure that you have a holistic definition of done.

6. Once you have consensus and a shared understanding about each sticky note, ask the Scrum team to walk around the room and put a dot on any of the sticky notes that they believe will be difficult or even impossible to finish during a sprint. Remind the team that all the items they place in the definition of “done” must be completed by the conclusion of each sprint. If that’s not a possibility, then remove items to create a less strict definition of “done.”

7. Discuss the sticky notes that accumulated the most dots and find ways to compromise on those tasks without sacrificing overall quality. You’ll likely discover many possible process and development improvements the Scrum team will need to address over the next few sprints.

8. Decide which sticky notes will survive and become part of your Definition of “done.”

This is the team’s first crack at creating such a definition. But this definition can—and should—change over time. Your team should regularly inspect its definition of done during sprint retrospectives. How often it makes sense to do this depends on your specific circumstances.

So what does a definition of “done” look like? Here’s an example:

• All code has been developed.

• It meets the team’s coding standards.

• Unit tests are written and passing.

• Code has been checked into the source control repository.

• Acceptance criteria have been met and confirmed by a development team member who didn’t write the code.

• The continuous integration build is passing.

• The product owner has seen the product (increment).

• All code has been deployed to the staging environment.

The preceding example is from a development team that Todd worked with that strived to always have an increment that was in a releasable state. This team could release features to production whenever the product owner needed new features to go live. When the development team said they were “done,” it was clear to the product owner what state the completed work was in. Having the code always in a releasable state gave the product owner a lot of flexibility in choosing when to release. In many organizations, there are many impediments that must be removed before teams can release products on demand. As the Scrum master, it’s your job to abolish those impediments.

As we mentioned, this is just an example. Use it. Modify it. Better yet, brainstorm with your team to create your own definition of done! Scrum requires that every increment be releasable, so work with your team to create a definition of done that makes that possible.

Being contextual, the definition of done changes along the way. See how things go. During your next sprint retrospective, you’ll have the opportunity to inspect how things went and adapt your definition of done, if needed.