What are the acceptance criteria
What are the acceptance criteria As a product manager or product owner, you may be responsible for writing acceptance criteria for the stories in your product backlog? In this article, we’ll define, look at a few examples, and explore some best practices for writing it.
In agile methodologies, refer to a set of predefined requirements that must be met in order to mark a user story complete.
They are a form of agile requirements documentation. As with most things agile, there are varying definitions of it.
- Acceptance Criteria Definition 1: “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.” (via Microsoft Press)
- Acceptance Criteria Definition 2: “Pre-established standards or requirements a product or project must meet.” (via Google)
Are also sometimes called the “definition of done” because they define the scope and requirements of user stories. They give developers the context needed to execute on a user story.
Here are a few traits of effective acceptance criteria:
- Acceptance criteria should be testable. Since these requirements help formulate the definition of done for your engineers, they need to be easy to test. And the results of these tests must leave no room for interpretation. Tests should reveal straightforward yes/no or pass/fail results.
- The criteria should be clear and concise. You aren’t writing comprehensive documentation here. Keep your criteria as simple and straightforward as possible.
- Everyone must understand your acceptance criteria. Your criteria are useless if your developers can’t understand it. If you’re unsure about whether something is clear, take the time to ask and make adjustments until things are clear.
- Acceptance criteria should provide a user perspective. is a means of looking at the problem at hand from a customer’s standpoint. It should be written in the context of a real user’s experience.
Why do you need user story acceptance criteria?
Acceptance criteria serves several purposes for cross-functional teams.
- Managing expectations
- Defining scope and reducing ambiguity
- Establishing testing criteria for QA
- Defending against scope creep mid-sprint
Let’s dive in a little more into the benefits.
A user story on its own leaves a lot of room for interpretation.clarify the expected outcome(s) of a user story in a concrete manner.
It also gives developers and QA a clear-cut way to determine whether a story is “done.”
You want to incorporate these requirements into your process for many reasons. First of all, when you define your desired outcome before development begins, you help promote alignment and shared understanding.
This understanding helps reduce the likelihood of surprises down the line.
In addition to helping product people set and manage expectations, they are also helpful for developers. Not only does the added context reduce ambiguity, but it also creates a great defense against scope creep.
If a requirement isn’t defined and set at the beginning of a sprint, it’s more difficult to sneak it in midway through. Finally, acceptance criteria often define the fail/pass testing that will be done to determine whether a user story is complete.
WHEN TO DEFINE OUR ACCEPTANCE CRITERIA?
A trap that I encourage my teams to avoid is writing after development has started. This leads to merely verifying that the functionality built works rather than verifying that the functionality meets user needs and expectations.
If we write and review the criteria before implementation begins, we’re more likely to capture the customer intent rather than the development reality.
WHAT MAKES GOOD ACCEPTANCE CRITERIA?
it defines when a work item is complete and working as expected. Express criteria clearly, in simple language the customer would use, without ambiguity regarding the expected outcome.
This sets our testers up for success since they will be taking our criteria and translating them into automated test cases to run as part of our continuous integration build.
Who is responsible for writing acceptance criteria?
Virtually anyone on the cross-functional team could write for user stories. Usually, it’s the product owner or manager who is responsible for writing acceptance criteria or at least facilitating the discussion about it.
The idea behind that is to ensure that the requirements are written with customer needs in mind, and who better to understand customer needs than a product person?
Involving developers and QA as you define it has several benefits. For one, it gives you another opportunity to communicate with developers about product strategy and vision.
Secondly, developers and QA staff can help point out any missing pieces or identify dependencies that may not have been clear before.
Finally, these discussions can help you as the product owner better understand what your user stories look like through the eyes of developers. So whenever possible, define done together.