LearnWhen is a User Story “Done?”— Acceptance Criteria and the Definition of “Done”

Matt Anthes-Washburn
writes on August 17, 2015

Have you ever worked on a team that struggled with getting things “done?” Not just “pretty much done,” but, “really done.” I mean, the kind of “done” where the work matches the expectations, the code has been tested, bugs have been fixed, and everyone can celebrate by going out for ice cream. One of the most important assets of a high-performing team is a good shared understanding of what it means for a feature or user story to be “done.” In a previous post discussing the Scrum methodology of agile software development, we touched on this question of, “What does it mean to be done?” In Scrum, there are criteria specific to each story, along with a more general definition of what needs to be done for each story. Let’s take a look at some of the ways a team can know when a user story is “done.”

“Done” Starts Early

A Scrum team thinks about “done” from the very early stages of crafting and refining a user story. Here is an example user story:

As a website user,

I need a “home” button

So that I can return to the homepage with a single click or tap.

During the Scrum event of backlog refinement, the team reviews user stories and drafts acceptance criteria, which detail specific characteristics of a solution. These criteria are also sometimes called conditions of acceptance or story requirements. The acceptance criteria should be testable—they are clear enough that each can be evaluated to a simple “yes,” or “no.”

The acceptance criteria are immediately useful in planning the sprint. In constructing the criteria, the team develops a shared understanding of the user story and its scope. With this understanding, the team is able to provide an informed estimate of the effort for the story. The acceptance criteria are also good starting points for task breakdown. Each item provides a hint of one or more tasks that a team member will need to do to accomplish the sprint.

Here are some acceptance criteria that might apply to the above user story:

  • Home button is visible on all pages
  • Clicking the home button returns the user to the homepage
  • Home button is recognizable

“Done” is Testable

As work on a user story begins to wrap up, the team circles back to the acceptance criteria, reviewing each and checking that it has been met. The team tests the working software against the acceptance criteria. Often, test cases are written to cover each item. In the example above, the test cases will verify that the home button is visible on all pages, and that clicking the home button returns the user to the homepage.

How can the team test if the home button is “recognizable?” Is there a design the team has already agreed upon? Will the team carry out user testing, or will they just check that it seems reasonably recognizable to them? With this third item, you can see that testing the acceptance criteria is not always a simple matter. For this reason, I find it’s a good idea for the team to focus particular attention on acceptance criteria during backlog refinement. I encourage team members to imagine themselves ready to test the user story and to think about what they will do to test each of the acceptance criteria. In some cases, we’ll make a note ahead of time as to the test we will use. For example, we might decide to use interviews with users to test the home button.

“Done” is Repeatable

Before finishing a story, it is a good idea for a team to check their work against their shared definition of “done.” The definition of “done” is a set of practices the team has agreed upon for all stories. It’s helpful to have the definition of “done” posted on a wall or easily visible in a team’s workspace.

Below are some examples of practices that might be included in the definition of “done:”

  • Acceptance criteria met
  • Code is reviewed by another development team member
  • Test cases are written
  • Unit tests and UI automation tasks are written
  • Feature is tested for accessibility
  • Feature is tagged for analytics

When the team thinks the story is ready, the Product Owner is asked to review and accept the user story. This is an opportunity to review the acceptance criteria for the story and the definition of “done.” Some teams wait until the end of the sprint for formal acceptance of the story. As a Product Owner, I prefer to review and close stories as the sprint progresses. This allows our team to focus our final efforts on the one or two stories that remain and on preparing for the sprint review demo for stakeholders.

Unlike acceptance criteria, which change for each user story, the definition of “done” stays more or less unchanged over time. When a team initially forms, they should take some time to agree on some of their norms. During this team kickoff or launch, teams work out all the details of how they will do Scrum, such as the scheduling of Scrum events. The team kickoff should also include the first draft of the team’s definition of “done.”

“Done” Takes Practice

Periodically, the team should revisit their definition of “done” and check to see that it still suits their needs. A good time for this is during sprint retrospective. If a particular consideration seems like it is often overlooked, it might be worth adding it to the definition of “done.” For example, our team found that we were often finishing stories, only to find that we had forgotten to tag the story for analytics. We also frequently forgot to tag images so that they would be easily accessible to someone using a text-to-speech screen reader as an accommodation for visual impairment. These invisible details can be easy to overlook during the development and testing of a story, but they are often very important. While these tasks might not take much time when they are done along with the rest of development, when they are overlooked they can become time consuming and such chores can quickly fill a product backlog. As a result, our team added analytics and accessibility to our definition of “done.” Now, when we are ready to close a user story, our team checks to make sure analytics and accessibility have been addressed.

As with many things in Scrum, understanding when something is “done” takes practice. Together, the team works with the tools of acceptance criteria and the definition of “done” to improve their work. The team’s practices should adapt to the particular needs of the team at a given time, and may change over time as the team’s needs shift.

For a deeper dive into agile software development and the Scrum methodology, check out my previous post, How to Get Started with Scrum, or the course, Scrum Basics.

 

 

5 Responses to “When is a User Story “Done?”— Acceptance Criteria and the Definition of “Done””

  1. Home button is visible on all pages >> This might not be tested at the end of the sprint since other parts ( pages) are built later. Is it OK that ‘testable” means testing can only be completed at the end of later sprints?

    • Good question, ngoc.

      Personally, I like to include all the testing for a story in the definition of “done.” The ideal user story describes a single, self-contained unit of value to be delivered to the user through the product. So, we define our story and acceptance criteria in terms of what we expect to have finished and tested by the end of the sprint.

      In this example, if more pages are to be created in later sprints, you can include, “Has a home button,” in the acceptance criteria for the upcoming user stories waiting in the backlog. That way the team remembers to test for a home button at the right time.

      Does that make sense?

  2. Sonali Tiwari on July 22, 2016 at 4:22 am said:

    Thanks for such an exhaustive well-explained article…

  3. octavio on May 3, 2016 at 7:53 am said:

    As a website user,
    I need a “home” button ????

    I would NEVER describe UI in a user story… As a user, I want to be able to go back home would not conditioned the solution…

    • Matt Anthes-Washburn on May 16, 2016 at 6:47 pm said:

      Good point, Octavio. Even the acceptance criteria here are too prescriptive; the wording states that the solution is a home button, which should be up to the team to resolve.

      In this case the problem to be solved is that the user needs to be able to get home. Backing of of the solution and clearly stating the problem makes a better user story. Thanks for pointing that out!

Leave a Reply

Learning to code can be fun!

Get started today with a free trial and discover why thousands of students are choosing Treehouse to learn about web development, design, and business.

Learn more