How to write acceptance criteria that developers love

Start with the story

A user story is a technique for capturing a description of a software feature from the end-user perspective. The user story raises the question of why the user needs this functionality, and how they can interact with it.

Thanks to user stories there is greater alignment in the delivery of this functionality as user story builds a shared understanding of what problem needs to be solved.

What makes them good

• A product owner should not write a story alone. Discussing it with the development team is what surfaces the risks and the overhead before they are baked into a commitment.
• A user story should be concise and straightforward. Avoid confusing terms and focus on what's important.
• A good way to write a story is by role. The goal is the benefit that the user of a specific role wants to achieve or the problem she wants to solve.
• Acceptance criteria are the conditions that have to hold before the story is done, each with a clear pass or fail. They are what makes a story testable, and what stops "done" being a matter of opinion.
• Everyone on the team should be able to state what the story and its criteria mean without checking.
• There are two formats of acceptance criteria that can be mixed or used independently:
  • scenario-oriented (given/when/then) - “given some precondition, when I do some action, then I expect some result”
  • rule-oriented (checklist) - a set of rules that describes the behavior of a system.
• A good user story will contain a few key examples

Example

User Story

As a traveler, I want to see if a tax is included in the room’s price so that I can be more informed about my hotel reservation

Acceptance Criteria

• Given a hotel returns room rates with $0 taxes for 1 night, then when the user hovers over the nightly rate, the window should appear with the details of the nightly rate and say that taxes and fees are “Included“
• Given a hotel returns room rates with $0 taxes for multiple nights, then when the user hovers over the nightly rate, a window should appear with the details of the rate and say that taxes and fees are “Included”
• Given a hotel returns room’s rates with a value for taxes for 1 night, then when the user hovers over the nightly rate, a window should appear with the details of the rate and the actual value of the taxes and fees
• Given a hotel returns room rates with a value for taxes for multiple nights, then when a user hovers over the nightly rate, a window should appear with the details of the rate and the actual value of the taxes and fees.

Lifecycle of a story

1. PM works with the team to define a new story that covers "WHAT" the effect of the Story will be
2. It should be unambiguous and include acceptance criteria (preferably examples)
3. New Stories are placed in backlog without estimates and not groomed
4. Stories are taken from the backlog and investigated by members of the team (from 1 .. team size)
5. The outcome of grooming is a definition of "HOW" the "WHAT" will be implemented along with estimate.
   1. This should leave no questions to be answered by a dev team
   2. The team should be aligned on HOW specific story will be implemented
   3. As "HOW" is defined, the team estimates the story.
6. Groomed and estimated tickets are available to be pulled into a future sprint
7. The sprint executes the HOW, including the automated tests or manual test cases.