Reading Time 9 minutes
Acceptance Criteria Definition: Acceptance Criteria defines from an end user’s perspective, how a particular feature could be used. It focuses on business value, establishes the boundary of the feature’s scope and guides development. These are unique to a user story and form the basis of user story acceptance testing which establishes the conditions of success of the feature.
Acceptance criteria could establish boundary that helps to understand what’s included and what’s excluded from the scope of the user story. The criterion of user story acceptance not only informs the product behaviour in happy path scenarios, it also guides the user experience in the case if something doesn’t work as intended. It describes what would be verified by the acceptance tests.
When the product owner verifies particular user story acceptance criteria and the developed feature passes the it, the development of the user story is considered a success. Pass / fail type results allow AC to form the basis of creating tests that can be automated and executed.
Tips for writing Acceptance Criteria
An essential aspect of writing good user story involves writing good acceptance criteria. It is the key to effectively testing the developed functionality. It allows theteam members writing acceptance tests to understand the scope of the user story or Product Backlog Item (PBI).
How to define acceptance criteria? Here are some useful tips for writing AC for user stories. Some of the Scrum teams I’ve worked with preferred to use these ac tips as a checklist for writing good acceptance criteria. Acceptance criteria checklist helped with consistency and acted as training wheels for new team members. I encourage the teams to keep revisiting and revising these tips to fit their need. I would also forewarn to avoid using these tips as fixed rules.
Here are 7 tips for writing acceptance criteria:
- Each product backlog item or user story should have at least one acceptance criteria. Hey don’t take writing acceptance criteria lightly or think of skipping it.
- Acceptance Criteria is written before implementation – this is obvious yet frequently missed by teams. Write acceptance criteria after the implementation and miss the benefits.
- Each acceptance criterion is independently testable. Why shouldn’t it be?
- Acceptance critera has a clear Pass / Fail result. Write complex and long sentences at your own risk.
- It focuses on the end result – What. Not the solution approach – How.
- Include functional as well as non-functional criteria.
- Team members write acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have shared-understanding of the user story.
Who writes acceptance criteria?
Acceptance criteria are usually developed jointly by the development team and the product owner. Who writes the acceptance criteria, or who defines the acceptance criteria is not a matter of rules or convenience.
What matters is – writing acceptance criteria (AC) should help establish and communicate shared understanding between the product owner and the development team about solving a customer’s challenge or building the product capability.
One practice your can try avoiding is where the Product Owner writes all the AC. Why so?
When you encourage the team members write the AC, they must first understand the intended purpose of the feature and the outcome it must generate for the users.
Writing AC clarifies the scope for the team and also allows for the Product Owner to verify if the team and the PO have a shared understanding of the feature.
Acceptance Criteria examples
Example 1: User story and it’s acceptance criteria:
As a credit card holder, I want to view my statement (or account) balance, so that I can pay the balance due.
the acceptance criteria for this story could be:
- Display statement balance upon authentication. Say for example $1560
- Display total balance. For example $3560. Here the balance due from the current period is $2560 and past balance due is $2000.
- Show Minimum payment due. For example $140
- Show Payment due date. For example May 16th of the current month
- Show error message if service not responding or timeout. For example ‘Sorry, something went wrong with the service. Please try again.’
Example 2: User story and it’s acceptance criteria:
As a teacher, I want to generate assessment report, so I can evaluate student performance.
the acceptance criteria for this story could be:
- Show a student’s current assessment score.
- Display past assessment score of the student.
- Provide an option to Print / Save / Share. (By the way, this could be split as a separate user story by itself).
- Display error message if service not responding. (If a team chooses to add the Error Message as their definition of done for all stories – where ever applicable, it could be omitted from the acceptance criteria).
What is the right amount of Acceptance Criteria?
Well, if you’ve too many AC for a single product backlog item (PBI), chances are you could split it into multiple PBIs.
Tip: Have too many criteria as part of one story and chances are you’ll easily run into at least one criteria that isn’t passing.
That delays the delivery of that user story, which delays the feedback, ultimately increasing the risk of failure. I recommend, whenever you have got a chance, please go ahead and split the user story right there. You can thank me later 🙂
Splitting user stories helps in keeping each user story small, improves chances of delivering it early, seeking feedback faster, hence reduces risk. Yes, there is effort involved in splitting the user stories as well.
Hence, the PO and the development team have to identify for each user story, what is a barely sufficient detail of AC. Photo source: Kenny Rubin, Innolution where Ken discusses the pros and cons of adding too many details versus no detail and establishes the need to identify what is barely sufficient detail to get started.
It’s important that your team members spend a little time and get good at writing acceptance criteria. It’s benefits are long lasting and ROI of the effort is simply too high to ignore.
Rule of Thumb: My rule of thumb for number of acceptance criteria is to have between 1-3 per user story. If a user story have between 4-5 of these, I start exploring options to split the story. If there are 6 or more criterion then the chances are the team won’t be able to implement it all in one sprint, definitely this story needs to be split in more than one.
Remember small user stories with lesser scope can be delivered comfortable within a sprint and presented to users for feedback. Early feedback reduces risk and impact of failure.
When to write Acceptance Criteria?
Acceptance criteria (AC) should be written anytime before the user story is deemed ready to enter the Sprint Planning. Usually it is written during the product backlog refinement meeting. AC can be progressively developed and added to a user story during the refinement. However it should not be kept for when the development team start implementing a user story.
“If we write and review the acceptance critera before implementation begins, we’re more likely to capture the customer intent rather than the development reality” writes Steve Povilaitis.
To ensure the AC is defined for each user story upfront, many teams add writing acceptance criteria for User Stories to their User Story Readiness Checklist. User Stories that do not have at least one AC can’t enter the Sprint Planning itself. Well, that shouldn’t prevent the team from exploring the intent or refining the AC after the Sprint Planning / before the implementation when the team members have conversations with the Product Owner.
What you should do now
1. If you’d like us to work with your teams — to dramatically improve your product management, product development, organizational agility, and growth (like we did for many clients from fortune 500s to young startups), then leave your inquiry and claim a free Agile Coaching strategy session. On this free phone consultation, one of our expert coaches will discuss your agility goals and suggest strategies to improve your team and organizational agility.
2. If you’d like to assess your team agility for free, go to our Agile Assessment, where you can instantly evaluate the current agility of your team and identify the gap between their current state and desired state. Or, if you’d like us to build your company’s in-house capabilities to be Agile (not for free), then contact us and we’ll discuss your requirements.
3. If you’d like to read further — see our recent insightful Scrum articles