What’s Done is Done: User Stories

The definition of done is a fairly popular (and sometimes emotional) topic in the Agileverse.  It seems everyone has an opinion on the matter ranging from “It depends,” to “Let the teams decide,” to a meticulously designed set of business rules and criteria that account for every possible scenario.  However, as organizations adopt Agile practices (and specifically, Scrum), they seek to leverage guidance from those of us who have already blazed the trail.  Why then is this such a complex topic?

One aspect is that the word “done” is overused.  We must distinguish between different contexts of “done.”  There is “done” at the story level, epic level, release level, product level, etc.  Each of those meanings of “done” has different criteria.   For the purposes of this article, we are only going to look at the done criteria for a user story.

Another aspect of the problem with done is perspective.  The word “done” is often used to mean “complete,” as in a Scrum team saying, “We are DONE with this story.” It’s also used to indicate acceptance, as in a product owner saying, “This story is done.” I typically teach and coach it this way: Don’t say “done.”  Instead, use “complete” and “accepted” for more specific indications of status.  This gives way to defining completion criteria and acceptance criteria (Figure 1). 

 

Click to expand image.

Figure 1.  Done Criteria = Completion Criteria + Acceptance Criteria

The criteria for completion are summarized as follows:

• “Code complete” – as defined by the organization/teams
• “Unit tested” – as defined by the organization/teams
• “Peer reviewed” – as defined by the organization/teams
• “QA complete” – as defined by the organization/teams
• Documented (as needed; determined by the Scrum team through tasking at the beginning of sprint)

The Scrum team determines when the completion criteria have been met with the guidance of the Scrum master.  At that point, the story is considered “complete.”

The criteria for acceptance are summarized as follows:

• The list of expectations for a specific user story as defined by the product owner prior to the beginning of a sprint.
• The product owner may define these alone or with the help of the Scrum team and/or Scrum master.
• For cases where acceptance criteria are not clear, a spike user story will be used to define the problem and acceptance criteria for a user story to be completed in a future sprint.
• The Scrum team must agree to these acceptance criteria at the sprint planning meeting.
• Minor changes to the acceptance criteria once the sprint is underway are acceptable as long as there is formal agreement between the Scrum team, Scrum master, and product owner
• When the Scrum team believes these acceptance criteria have been met, the user story is ready for a product owner review (demo), which occurs throughout the sprint
• The review (Demo) of each user story should NOT be left until the very end of the sprint

The product owner determines when these acceptance criteria have been met.  At that point, the user story is considered “accepted.”

This approach provides a framework that is modular and can be adaptable around the definitions of “code complete,” etc. but clearly delineates the roles and responsibilities associated with delivering and finalizing work.  If a particular organization is striving toward 100% automation of functional tests that become part of a holistic regression test suite, then “creating automated test scripts” would be expressed in the QA complete criteria.

Further, one group might agree on what “peer reviewed” means but not the “QA complete” criteria.  Using this modular definition, each group can customize these definitions to suit their team’s specifications.

As part of this exercise of defining “done,” I have also identified in the following diagram (Figure 2) the different stages at which events occur in terms of the definition of done:

 

Click to expand image.

Figure 2.  Definition of Done Process Mapping

The first column defines the event or phase during which the activity in the second column takes place.  Column three shows who is responsible for the action item in column 2.  In one of the teams I am coaching, there was a highly contentious relationship between the product owner and Scrum team, and this diagram helped sort through who was responsible for what and when.  This, along with a well-defined definition of “done,” set expectations and the conflict was neutralized.

Each organization (and team) must come to a consensus on what the definition of done is for their particular projects/products at various levels (story, sprint, release, etc.)  In the next installment of this series, I will explore what the definition of done is at the sprint level.

Don’t forget to leave your comments below.

---

Daniel James Gullo, PMP. CSP, CSM of Trinacria Consulting is a proven leader in the field of Information Technology and Information Systems who advocates and evangelizes best practices and quality for projects in all areas of business.  Specializes in delivering software development and testing projects which are on-time, under-budget, and high-value. A professional with demonstrated success in Agile and traditional project / program management, business analysis, quality assurance, and consulting services.  A highly praised and recommended consultant with an extensive history of satisfied customers and clients.  Fiscally minded with both local and global experience.  Open to travel both domestically and internationally.  Effectively manages teams and resources around the globe both on-site and remotely.