You might have heard the term acceptance criteria and user stories in the context of agile software development. In this series of two articles we provide you the guide to both topics. Today we tackle acceptance criteria. Having worked with multiple complex projects for our clients, we have seen the benefits of acceptance criteria when these are well defined. They contribute to making the project better by facilitating division of tasks. When they are misused, they can negatively impact the software development team, creating confusion about deliverables.
What is acceptance criteria?
In agile methodologies, acceptance criteria refers to a set of pre-defined requirements that must be met in order to mark a user story complete. But don’t take our word for it. Here is how some tech giants define acceptance criteria.
- Microsoft: “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.”
- Google: “Pre-established standards or requirements a product or project must meet.”
Why do you need acceptance criteria?
After getting around to understanding what acceptance criteria is, your (and your team’s) next question will be why do you need it? In fact, acceptance criteria serve several purposes for cross-functional teams, including:
- Managing expectations
- Defining scope and reducing ambiguity
- Establishing testing criteria for QA
- Defending against scope creep mid sprint
Who is responsible for writing acceptance criteria?
Great, now you want to put acceptance criteria in place, who should be responsible for it? Virtually anyone on a team could write acceptance criteria 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. However, it is widely recommended to make writing acceptance criteria a group activity that includes both dev and QA representatives.
When should acceptance criteria be written?
Many teams choose to write acceptance criteria during backlog grooming sessions. At the very latest, acceptance criteria should be defined before development begins. It’s also worth noting that writing acceptance criteria too early can backfire as well.
How should you format acceptance criteria?
We recommend using the format of Given/When/Then.
- “As a (intended user), I want to (intended action), so that (goal/outcome of action).”
- “Scenario: (explain scenario). Given (how things begin), when (action taken), then (outcome of taking action).”
Here is an example:
As a product manager.
I want to score potential ideas.
So that I can decide what to include on my product roadmap.
Scenario: The product manager adds potential ideas and ranks the best ideas based on benefit versus cost (Given) that I have added two or more ideas and scored (When) I click the Rank button (Then) ideas are sorted with the top-scoring ideas at the top.
Main challenges and best practices
We hope this quick guide provided a bit of clarity around this topic. We want to share a few more considerations.
- Acceptance criteria should be testable. This will allow testers and developers to verify that all requirements were met.
- Criteria should be clear and concise. Don’t make criteria too narrow.
- Keep your criteria achievable. Everyone must understand your acceptance criteria.
- Avoid technical details. Acceptance criteria should provide user perspective.
Thanks for taking the time to read our blog post. Let us know if you have any suggestions for acceptance criteria and their implementation in software development projects. Tune it to learn more in our second article on user stories.
Need help with some of your projects ? Contact us.
Photo credit: Anton Maksimov juvnsky
