—Aristotle

Done criteria are clearly stated conditions that a user story must meet for the functionality to be deemed complete and shippable for release. Done criteria supports the Agile principle of technical excellence, by which team members apply continuous attention to engineering practices and techniques focused on building a quality product.

Done criteria set the tone and create a habit on what it means to be done. These criteria should be readily viewable by the team as a reminder as it makes its transition toward Agile. Done criteria confer the following benefits:

• They help set team’s expectations of what it means to build the story functionality so that it is potentially shippable.
• They help identify the engineering activities and expectations that must occur to build a quality product.
• They can increase the level of product quality and limit the amount of rework due to defects found in the field.
• They are an input for team sizing user stories during Sprint Planning and ensure all of the work described in the team’s done criteria is considered.

This sounds simple enough. But if you are transitioning from a traditional waterfall world, done may have meant “I am done with development so therefore the work is done”—and the team now has to expand the meaning to include other engineering disciplines such as testing. In pre-Agile worlds, there is often a separation between development and testing. When you transition to an Agile mindset, done criteria imply that we are bringing development and testing and all of the associated disciplines together.

I suggest that done criteria are one of the most critical techniques that must be discussed and implemented to ensure that what gets built is made with quality. You can think of done criteria as a form of team-based quality control applied when a team builds product functionality.

Done Criteria Starter Kit

As a readiness activity within the RICH model, it is critical to establish done criteria prior to building the product. This ensures that the team has the opportunity to discuss the quality steps and understand how they are applied. This also ensures the team begins with done criteria that helps infuse quality into building the product right at the beginning.

I usually bring a starter kit of typical disciplines to get a story to done. This helps initiate an active team discussion prior to Sprint 1 so that each team member understands the various elements of the done criteria, what disciplines we expect to follow when building a user story, and what elements we are agreeing to as a team. Here is my done criteria starter kit:

• Design: Specify design tools, design type(s), and modeling the team uses. This extends to practices such as user interface (UI) and user experience (UX). This may include crafting user cases for stories or epics and specifying usability and sustainability goals.
• Development: Specify development programming tools, techniques, and coding standards. This done criterion may include building a story in an incremental manner to allow for iteration between development and testing.
• Documentation: Specify the level of documentation completion we expect when user stories have a documentation component, such as user guides and the nonfunctional requirements associated with them.
• Unit tests: Specify the tools and percentage of unit tests we expect to see executed. When there are no unit tests in place, specify the level of focus on constructing unit tests as part of the story construction.
• Version control: Specify the expected use of version control, private user workspaces (including check-out/check-in), continuous integration needs, and when to branch and when to merge.
• Local builds: Specify the build tools and the expected use of applying incremental local builds, such as continuous builds within the private user workspace.
• Code reviews: Specify when to apply code reviews and the percentage of code reviews being applied (all code changes or a particular type of code change). Discuss if pair programming is being applied and if this displaces code reviews.
• Testing: Specify the test tools and testing types—such as functional, system, integration, performance, or load—being applied to a user story. When there are no tests in place, specify the level of focus on constructing tests as part of the story construction.
• Defects: Specify the appropriate severity-level defects (severity 1 and 2 only or all severities) that must be resolved and verified prior to completing a story.
• Acceptance criteria: Prior to indicating that a story is complete, all acceptance criteria must be complete as well. Although acceptance criteria are separate from done criteria, for a story to be deemed done, it must subsume the acceptance criteria (Chapter 18).

At this point, the team discusses these elements, adapts the criteria to their current level of discipline, and establishes a common definition of done for the stories. You may need to further adapt your done criteria for the following reasons:

• Align with compliance standards that must be met.
• Enhance with technical best practices of an organization.
• Consider the inclusion of establishing automation activities for streamlining testing and build processes.

Once the team agrees to done criteria, they become a cornerstone for velocity and so have a direct effect on the sizing of stories. During Sprint Planning events, the done criteria should be highlighted as a reminder of the level and detail of work needed to complete the story and as an input to sizing the work. When done criteria are established, post them in a visible place to remind the team.

You should expect done criteria to evolve over time. You may want to periodically review them during the Sprint Retrospective events to determine if they need improvement. Also, some of the effort associated with your done criteria is dependent on the tools, infrastructure, and automation that currently exist and on your vision of these areas.

Definition of Done and Done-Done

You may encounter various synonyms for the term done criteria. Some prefer the term definition of done (DoD). Others define done in Agile as done-done. This is meant to imply that you are finished not only with development (the first done) but also with testing (the second done).

The question is, how many dones do you need? Figure 20-1 illustrates the humor of having multiple dones. If your definition of done has ten key disciplines, as I outline in the done criteria starter kit, then maybe it should be called done-done-done-done-done-done-done-done-done-done criteria. This is why I suggest that just one done is enough.

Are We Done Yet?

Done criteria are critical to a team following Agile—and indeed to any team that is developing software. They help a team understand the Agile principles of technical excellence and adapt their mindset to what it really means to be complete when building the functionality specified within a user story. It helps ensure that the user stories are built to include the necessary engineering activities and quality criteria to get to an effective and demonstrable piece of functionality ready for release.

Once a team has established its done criteria, the criteria should evolve over time based on what is learned during the retrospective and as the team increases its level of discipline with the benefit of a quality and releasable product. So the next time someone on your team says, “Are we done yet?”, make sure that the questioner means, “Have we built our stories with the appropriate engineering disciplines and quality criteria that allow us to build value with high quality?”