Agile Story Done Criteria Template

As an agile development team lead, I assisted our solution owner by explaining the intent and direction of our backlog stories to the team.  Normally this happened during a weekly team "backlog grooming" session. The purpose of the session was to fully understand the story, scope out the done criteria to match a fairly solid implementation plan and to estimate a story WAG. 

I found that the extra planning and team discussion before the story was accepted at backlog selection a valuable time investment. To help focus the grooming session discussion, I created a standard template for the story Done Criteria section. The concept of the template is to encourage team participation, scope the full expectations of the story, and document important discussions and ideas that will prevent confusion during the implementing sprint.

I'll present my template below and then follow that with a more detailed explanation for each section of the done criteria.

Story Done Criteria Template:

---

User Acceptance:

1. User can save a new map scene composed of a map background layer, a lat/lon center point and a zoom level.
2. User can only delete a map scene if the user was the creator.
3. ...

Team Definition of Done (derived requirements, quality, standards):

1. Approved by UI team
2. Must create a supporting release notes task documenting manual installation steps
3. Remove unused database entries for "system.map.*" properties.
4. ...

Out-of-scope:

1. Users cannot rename map scenes. This is covered by a future backlog story.

Discussion Answers:

1. TBD

---

Template Explanation:

User Acceptance:
User-facing requirements that must be complete for the solution owner to accept the story. Typically thought of as hard requirements that would necessitate direct negotiation with the solution owner (or users) if an problem were discovered during implementation or testing.

Team Definition of Done:
Derived requirements that influence the team's implementation.  These could represent functionality that a user would notice, but that does not impact the user's intent of the story.  This category also encompasses criteria that the implementation team values for internal quality, consistency or project standards reasons. Items in the section can be contributed by anyone on the team: developers, designers or quality control, for example.

Note that these specific criteria typically represent areas of high risk and otherwise important tasks that have not yet become a normal habit of a high performing team. For example, we don't call out typical story tasks such as unit testing, peer reviews or required documentation updates.

Out-of-scope:
This important category complements the positive criteria of the story by documenting good ideas for future backlog stories. Having this section seemed to encourage team members to contribute ideas on stories while allowing a place to record the ideas without bloating the scope of the story being discussed.

The other important reason for this section is that by being explicit here, we can avoid mid-story confusion when someone asks: What is the expected functionality when the user does X? Did we forget to consider this functionality or did we talk about it and arrive at a decision that it was not covered by this story?

Discussion Answers:
This section is for use AFTER the story has been accepted by the team and is under development. If any mid-sprint issues are discovered where the expectations are not clearly covered by user criteria, the team will work out a plan with the solution owner AND record the decision here. All such answers should be recorded here as the source of the requirements. This avoids having important story criteria being discussed in email threads, or on the phone, but not transcribed here for full team visibility.

Typically, these answers will be translated into criteria for user story acceptance tests (USAT) and become part of the official application specification.

Miscellaneous Helpful Ideas:

• The criteria should use numbered bullets for quick, unambiguous verbal reference during the team grooming session.
• Out-of-Scope items should have a POC assigned so that the ideas get translated into new stories or suggested to the users during the sprint review presentation.