Definition of Done: User Stories

Added to Process

definition-of-done-user-storiesThe “Definition of Done” is a fairly popular (and sometimes emotional) topic out 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. And as more organizations adopt Agile practices (and, specifically, Scrum), they seek to leverage guidance on this topic from those who have already blazed the trail.

Why is this such a complex topic? One reason is that the word “done” is overused. We must distinguish between different contexts of “done,” which can be applied at the story level, epic story level, release level, product level, and so on. In each case, the meaning of “done” has different criteria. For the purposes of this article, we are only going to look at the “done criteria” for a Product Backlog Item (aka PBI or User Story).

Another aspect of the problem with done is perspective. The word “done” is often used to mean “complete” as in the Development Team saying: “We are done with this story.” It is also used to indicate “acceptance” as in the 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.

Thus, we define two aspects of the Definition of Done – Completion Criteria and Acceptance Criteria:

Completion criteria and acceptance criteria for user stories

The Completion Criteria 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 beginning of Sprint)

The Development Team determines when the Completion Criteria have been met with the guidance of the ScrumMaster.  At that point, the story is considered “complete.”

The Acceptance Criteria can be summarized as follows:

  • The list of expectations for a specific Product Backlog Item as defined by the Product Owner prior to the beginning of a Sprint
  • The Product Owner may initially define these alone but eventually enlists the help of the Development Team and ScrumMaster
  • For cases where Acceptance Criteria are not clear, a Spike User Story will be used to define the problem and Acceptance Criteria for a Product Backlog Item to be completed in a future Sprint
  • The entire Scrum Team must agree to these Acceptance Criteria by the end of the Sprint Planning meeting
  • Minor changes to the Acceptance Criteria once the Sprint is underway as long as there is formal agreement between the Development Team, ScrumMaster, and Product Owner
  • When the Development Team believes these Acceptance Criteria have been met, the Product Backlog Item is ready for a Product Owner review (Demo), which occurs throughout the Sprint
  • The review (Demo) of each PBI should not be left until the very end of the Sprint

The Product Owner officially 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 on features.

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 the different stages at which events occur in terms of the Definition of Done:

User story definition of done

The first column defines the Scrum Activity during which the action item in Column 2 takes place. Column 3 identifies which role(s) are chiefly responsible for the action item.

On many of the teams I have coached, where there was a highly contentious relationship between the Product Owner and Development Team, this diagram has helped to 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 consensus on what the “Definition of Done” means for their particular projects/products at various levels (story, sprint, release, etc.).

Daniel GulloDaniel Gullo is the owner/principal at Apple Brook Consulting. For more than 25 years, he has been teaching, coaching, and consulting for organizations of many sizes -- from startups to multi-national enterprises.

Daniel has led large-scale Agile adoption initiatives for organizations in Financial Services, Education, Health Care, Bio-tech, Pharma, Information Technology Consulting, Professional Associations, and Federal Government.





About the Author

Daniel has been a well-known and highly regarded stalwart of the Agile community for many years. His tireless dedication and effort has earned him the distinction of The Most Valuable Agile Professional award for 2015.

As founder and principal of Apple Brook Consulting®, he has first hand experience about what it takes to make business work. A lifelong entrepreneur, Daniel’s portfolio of clients is long and distinguished: ING Direct (CapitalOne), NAVTEQ, IRS, PayPal, ADP, US Postal Service, GM, US Treasury Department, T. Rowe Price, GE, and many other high-profile organizations.

He is the founder of and chief advisor to Agile Delaware and a frequent reviewer, volunteer, and speaker for the Scrum Alliance, Agile Alliance, PMI and other organizations. His experience includes delivering keynote addresses for conferences such as Scrum Gathering – India; Scrum Gathering – Rio; Scrum Gathering – China; et al.

Daniel was Conference Chair for the 2015 Scrum Gathering in Phoenix. He was also the Conference Chair for the 2013 Scrum Gathering in Las Vegas, which makes him the only individual in the community to serve twice in this capacity. He has coached other conference chairs for both Scrum Gatherings and Agile Alliance events and is one of the administrators of the submission review system for Scrum Gatherings.

Daniel serves on the Trainer Acceptance Committee (TAC) for the Certified Scrum Trainer (CST) certification program. He is also a reviewer of Certified Scrum Coach (CSC) applications. Daniel is a founding member of the Scrum Coaching Retreat Planning Committee; host of Coaches Clinic events; and facilitator of Open Space Events, including the Scrum Alliance's largest Open Space ever at the Scrum Gathering in Berlin (with over 500 people) and the Open Space at Scrum Gathering – Shanghai.

Daniel is a prolific contributor to a vast array of online forums, blogs, and other social media including a network of over 5500 connections on LinkedIn and 25,000 followers on Twitter.

Daniel has given much of his free time to mentoring and coaching candidates for CST and CSC and has received accolades for his efforts from the individuals whom he has mentored, as well as, his colleagues in the training and coaching community.

Daniel is a trusted advisor to staff and management of the Scrum Alliance on matters related to policy, strategy, and vision; including but not limited to the Global Events program, CST program, CSC program, and other community outreach efforts.

As an Impact Partner and Investor for Fresco Capital, Daniel is passionate about enabling small companies with big ideas to live up to their full potential and achieve success.

Daniel’s book “Real World Agility” will be released in Fall of 2015 by Pearson Technology Group and includes practical, real world answers to practical, real world questions from his students and clients.

Financial Services
Federal Government
Consulting Services
and many others...

CapitalOne (ING Direct)
General Motors (GM)
US Treasury Dept.
Federal Reserve Bank
PMI GOC (Global Operations Center)
NAVTEQ (Nokia)
US Postal Service
Credit Acceptance Corp
T. Rowe Price
Starwood Hotels
Wyeth Pharmaceuticals (Pfizer)
Independence Blue Cross
Bank of America
and many others...


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.