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.
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.
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:
You can also find it interesting to read about the 5 whys root cause analysis in the agile team.
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!
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:
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:
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.
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.
There are two commonly used formats for acceptance criteria:
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).
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.
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.
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.
Project Manager Vs Product Owner: Key Differences
Why Managers are averse to Agile?
Boosting Business excellence through Business Analytics
03 Dec 2022
01 Dec 2022
01 Dec 2022
01 Dec 2022
01 Dec 2022
01 Dec 2022