Definition of Acceptance Criteria in Agile Methodologies for user stories
The terms ‘Conditions of Satisfaction’ and ‘Acceptance Criteria’ used interchangeably.
They can be considered a clear description that will define value proposition, user flow or characteristic of the solution.
Acceptance criteria are acted as a catalyst for test cases and it should be testable. Acceptance criteria provide a detailed scope of the requirement, which help the team to understand the value and help the team to slice the user story horizontally.
The condition of satisfaction help to set expectations within the team as to when a team should consider something done. It helps the team to break down the user stories in task(s), if acceptance criteria are defined in detailed, then the team can provide better effort estimation for a user story, so development cycle can be shorter, resulting in no waste.
How to write acceptance criteria for a User Story in Agile?
The acceptance criteria is a must have ingredient for a user story. Acceptance criteria is a checklist that determine if all the parameters of a User Story and determine when a User Story is completed and working.
Before the developer can mark the User Story as ‘done’. All criteria must be fulfilled so that it is ensured that the User Story works as planned and tested.
The product owner is usually responsible for specifying what the acceptance criteria should be for each of the user stories.
When crafting perfect user story, acceptance criteria make the functionality pretty transparent, it help the product owner to find any missing point and validate the assumption. If any assumption is incorrect it helps to catch a little sooner.
Agile Acceptance Criteria Template
There is no template from the scrum about acceptance criteria, acceptance criteria is a detail description of system or feature put forward by the product owner, it’s a criterion against which the user story should be validated and tested.
What Acceptance criteria should be included
- Negative scenarios of the functionality.
- The impact of a user story to other features.
- UX concerns
- Functional and non-functional use cases
- Performance concerns and guidelines.
- What system/feature intend to do
- System of feature doesn’t do anything, isn’t supposed to do
- End-to-end user flow
What Agile Acceptance Criteria Should Not Include
Do not include following obvious stuff as your acceptance criteria for your user stories
- Code Review was done
- Non-blocker or major issues
- Performance testing performed
- Acceptance and functional testing done
Above checklist need to be included as part of DoD (definition of done), which serve as a checklist for overall sprint process, those shouldn’t be part of acceptance criteria
How to Write User Stories & acceptance Criteria
Acceptance criteria should be expressed very clearly, in simple language, without any ambiguity about the expected outcome. This ensures that the testers will be successful when they take the acceptance criteria and translate it into manual or automated test cases.
Simple and widely accepted format of user story template is
As a ____, I want ___, so that ____
- Please check this blog post, for detail about writing best user stories.
- We also covered 25 user story template in our previous post.
Practical Example of User Story With Acceptance Criteria
Here is the detailed example of our user story with acceptance criteria
Example bellow is an implementation of a new feature called printing. This feature provides the user with printed format of a user story or a bug in presentable format
Practical example of acceptance criteria
“As a user I should have the option to print any item with all the details, comments, and other things. I should get printable view in browser and then should have the option to print into different formats”
- All the item information should be visible including title, ID, description, comments, attachment names, linked items tasks/issues/epics etc, associated items, dependencies etc
- On the preview page, I should option to print, download as
- any other?
All the items type should be printable
- User Story
In case of Epic, we will show the related user stories and show only, ID, Title, Responsible, Status and priority
It should be possible to print the item details from almost anywhere, e.g.,
- From boards widgets under context menu
- In case of Epic or user story, from Epic or Backlog item context menu
- From item detail view
- From pop-up under context menu