This blog is the second post in a series about leveraging user stories to improve product outcomes. In this post, we will explore how acceptance criteria can be used to define the scope and requirements of user stories.
What are Acceptance Criteria?
Acceptance criteria, or AC, are the minimum level of expectations that need to be met to mark a user story as complete. It contains the situations, triggers, expected outcomes and the user role. In a way, they are an extension of the user story, which helps to clarify the expected outcome before development work begins.
Why is Acceptance Criteria Important?
As a Product Owner, acceptance criteria are a valuable tool for effectively communicating the expectations of a user story when working with cross-functional teams. An AC helps the developers and testers understand what needs to be accomplished, while the user story provides the original business and user context. Developing an AC allows you to think in absolute terms, almost like system instructions, to give developers the necessary context to execute a user story. This eliminates any ambiguity and helps both developers and testers understand what is expected.
Adding acceptance criteria increases transparency between a business scenario and the desired outcome. It sets the basis for what is expected to be tested. It is important to note that acceptance criteria are not the same as test cases, however, they can be used to inform test cases.
How to Format Acceptance Criteria
Similar to writing user stories, practice makes perfect. Agile provides frameworks and guidelines that can be used as the building blocks of a successful acceptance criteria. These are great as starting points, but it is important to adapt the framework to the unique needs of your organization and teams.
The Gherkin method, as demonstrated below, is the most common approach to creating acceptance criteria.
GIVEN a certain scenario/context,
WHEN a certain trigger/action is taken,
THEN an outcome must be observed.
For example:
GIVEN a user is in any step after step 2 in the payment flow,
WHEN the user clicks on the exit button
THEN the system will display a confirmation prompt to confirm if the user wants to proceed.
The other options to capture AC are:
- “The system shall…” format, for example, The system shall display a confirmation prompt when the user clicks on the “Cancel” button.
- Supplemental requirement statements, for example,
- The confirmation prompt must have the following UI components:
- Two options for the user
- To continue with the selected action
- Cancel the selected action
- The prompt must follow the branding guidelines of the organization as in the Market.
- The UI must follow the web accessibility standards as outlined in the Accessibility Document <insert hyperlink>.
- Two options for the user
- The confirmation prompt must have the following UI components:
Acceptance Criteria Best Practices
Here are some best practices for creating acceptance criteria that make an impact:
- Be as specific, precise and concise as possible.
- Try to check if the steps you have described are indeed testable.
- Use visual flows, if it makes sense, to help readers understand the larger picture.
- Use references to relevant documentation or user stories you are building on. For example, business value, if it is not already obvious.
As with any other agile documentation or ceremony, collaboration yields the highest quality output. A Product Owner may be responsible for building out the initial draft of the AC’s, but reviewing with the rest of the team during grooming or refinement or one-off ceremonies is a good practice.
It is also important to note that most of user stories will be approved or signed off by the Product Owner, so it is in the best interest of a Product Owner to thoroughly understand the expectation, impact and risk associated with the user stories and how they will test the ACs. In some cases, the PO may not be the person to sign off should make sure the right stakeholders are looped in.
Conclusion
Developing acceptance criteria is an essential step in the product lifecycle to define the scope and requirements of your user stories. It provides the necessary context to approach the user story from a different perspective, to ensure all expectations have been clearly communicated.
The next blog post in this series will dive into additional tips on user stories.
Perficient has built innovative digital product solutions for Fortune 500 enterprises for over 25 years. Contact us today to learn more about or Innovation + Product Development consulting services.
