Website: https://www.knowledgehut.com
Share
Acceptance Criteria for User Stories: Examples and Best Practices
Read it in 7 Mins
In this article
- What Are Acceptance Criteria?
- Why Do You Need User Story Acceptance Criteria?
- Tips for Writing Acceptance Criteria with Example
- Here are some examples of well-articulated acceptance criteria:
- Who Is Responsible for Writing Acceptance Criteria?
- When Should User Story Acceptance Criteria Be Written?
- How Should You Format User Story Acceptance Criteria?
- Summing up
View All
Let’s think of a scenario where your development team is working on a set of user stories for a product. At the end of a sprint, the developer might have marked one story as complete—but the Product Owner thinks otherwise! The story is pushed to the next sprint for further work, and the team velocity is reduced as a result. This misunderstanding could have been avoided if the developers had a clear, unambiguous understanding of what the Product Owner’s expectations actually were. You need not worry! Below is a discussion on why we need user story acceptance criteria, how to format it, and user stories examples etc.
This is where Acceptance Criteria play an important role. Sometimes called the Definition of Done for a user story, they help to lay out the requirements that must be met to mark the task as being complete in all aspects.
What Are Acceptance Criteria?
Acceptance criteria are the predefined requirements that must be met, taking all possible scenarios into account, to consider a user story to be finished.
In other words, they specify the conditions under which a user story can be said to be ‘done’. When all the criteria are met, the team can set the task aside and move on to the next story.
Know more about agile vs traditional project management.
Why Do You Need User Story Acceptance Criteria?
As our example illustrates, having a properly articulated set of acceptance criteria will remove all ambiguity around the feature that is being developed. The developers will know what the client expects and will be clear about what the expected functionality is.
Acceptance criteria are used to:
- Manage expectations: Acceptance stories clearly define the boundaries of the task. Usually, acceptance criteria are testable, with yes/no or pass/fail results that leave no room for misinterpretation.
- Arrive at a shared understanding with the client: There have been instances where the client might feel that they needed more from the feature, and that it does not meet their requirement in its entirety. Well documented acceptance criteria will address all such ambiguity.
- Spell out the functionality for tests: The defined criteria will help to check whether the system is performing in line with the expectations.
- Work on estimates: When the team is clear about the boundaries of each task, they will be in a position to make accurate estimates.
- Manage scope: Scope creep happens when stakeholders change the requirements midway through the project. One deliverable could suddenly expand to five, and unless the scope is properly defined at the outset the user story will be liable to scope creep, throwing schedules and budgets into free fall.
You can also find it interesting to read about the 5 whys root cause analysis in the agile team.
Tips for Writing Acceptance Criteria with Example
Source Link: productcoalition.com
The image above, which needs no explanation, shows what could happen when the acceptance criteria are not well defined! Each of the outcomes has a tree, a rope and a swing; but they are a far cry from the poor customer’s ask.
So, now that you have understood what acceptance criteria are, and why they are important, here are some recommended best practices for writing good acceptance criteria!
- Make sure that each and every product backlog item or user story has a unique set of acceptance criteria.
- They should be simple, articulated well, and should be easily testable. Each criterion should answer to ‘yes/no or pass/fail.
- Make sure that the acceptance criteria are defined, and frozen, before implementation of the user story. No tweaking allowed!
- Focus on the end result, not the approach. In other words, think of the What and not the How.
- Wherever relevant, include all the non-functional criteria along with the functional aspects, so that there is a clear and complete understanding of what is needed.
- It would be good practice to set up a process where the team members write the acceptance criteria, and the Product Owner signs off on it. The PO holds the product vision, and this way you can be sure that the overall goals are being met.
Here are some examples of well-articulated acceptance criteria:
This is the user story:
As an Agile trainer, I want to print an assessment report, so I can share the details of a student’s performance on the course with her employer.
The acceptance criteria for this story could be:
- Display the student’s assessment scores for each of the tests completed.
- Choose the scores that must be shared with the employer.
- Pick the option to Share the report (other options can be Print or Save).
- Choose the person with whom the report should be shared.
- If there is an incorrect response, display an error message.
- Share the document through email.
Here’s another user story:
As an online shopper, I want to view my cart, so that I can make the payment.
The acceptance criteria for this story might read:
- On clicking ‘view cart’, the cart opens up in a new tab.
- Numbers of each item are displayed and can be changed.
- Total invoice amount is displayed.
- On clicking ‘checkout’ tab, you can select delivery time and address.
- On clicking ‘proceed to payment’, various payment options are displayed.
- Choose between various payment options.
- Set the chosen option as default option, if required.
- On clicking ‘place order and pay’, you can enter account details, and are taken to the bank website for making the payment.
Who Is Responsible for Writing Acceptance Criteria?
There is no allocated responsibility for writing acceptance criteria. While it is usually the product owner or product manager who gets around to defining the functionality, just about anyone on the team could write acceptance criteria for user stories. The writer must be careful to ensure that the acceptance criteria are written from the perspective of the end user, and for this reason the product owner (who is considered to be the voice of the customer) often undertakes this task.
However, it is now common practice to make this a shared activity in which everyone, including developers, testers and QA people, take part; so that there is a 360-degree understanding across the team as to what the feature will entail. The more roles that are involved in this activity, the better — as this gives more opportunities for team collaboration and discussions. Many hands make for better work, and there could be some functionality, dependency or scenario that one person has missed out, but the other person has been able to identify; simply because they are coming at the problem from a different angle.
When Should User Story Acceptance Criteria Be Written?
The acceptance criteria should be written before the user story is moved from the product backlog into the sprint backlog. This usually happens during the backlog grooming session at the end of each sprint (or for the first time, before the first sprint starts).
It is important to write and finalize the criteria before the implementation begins, so that any challenges faced during the actual work do not cloud the definition of the task functionality.
Also—and this is a bit tricky—always ensure that the acceptance criteria are not written too early. As is the nature of Agile projects, priorities keep evolving as requirements change, and they may need to be rewritten.
How Should You Format User Story Acceptance Criteria?
There are two commonly used formats for acceptance criteria:
Given/When/Then
For a user story that typically follows this format:
As a (intended user), I want to (intended action), so that (goal/outcome of action).
…the acceptance criteria would be like this:
Scenario: (explain scenario). Given (how things begin), when (action taken), then (outcome of taking action).
For example:
User story: As an online buyer, I want to add a book to my shopping cart, so that I can purchase it.
Acceptance criteria: Given that I have shortlisted three books in my wish list, when I click on one book, then it gets added to my shopping cart.
Verification List
The team makes a verification checklist, defining a list of pass/fail or yes/no statements that will mark the functionality as complete.
Whatever the format you choose, it should be something that the team is comfortable working with.
Summing up
A user story, on its own, can be interpreted in a hundred different ways. It is only when the acceptance criteria are defined that there is complete clarity on the expected outcomes, and both the customer and the developer are in sync with regard to the functionality that a user story will provide.
By setting up a clear process for defining acceptance criteria and making sure that they are taken seriously, Agile teams can make sure that there is no ambiguity, everyone is on the same page, and the customer gets what they have asked for.
Tags
Want to build a successful career in Agile and Scrum?
Avail your free 1:1 mentorship session.