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.