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.