Acceptance Criteria For User Story

Purpose Of Acceptance Criteria?


Acceptance criteria*:

Screen Shot 2015-01-21 at 9.55.44 am

Define the boundaries for a user story/feature


Screen Shot 2015-01-21 at 9.57.38 amHelp the product owner answer what they need in order for this feature to provide value (typically these are the minimum functional requirements)


Screen Shot 2015-01-21 at 9.58.54 am

Help the team gain a shared understanding of the story/feature


Screen Shot 2015-01-21 at 10.14.55 am

Help developers and testers to derive tests


Screen Shot 2015-01-21 at 9.59.07 am

Help developers know when to stop adding  more functionality to a story

*The little pictures above are created by Nathanael Coyne (@nathanaelb). 


What are good acceptance criteria?

 Good acceptance criteria:

  • State an intent not a solution (e.g. “The user can choose an account” rather than “The user can select the account from a drop-down”)
  • Are independent of implementation (ideally the phrasing would be the same regardless whether this feature/story would be implemented on e.g. web, mobile or a voice activated system)
  • Are relatively high level (not every detail needs to be in writing)


Can you give a good example?

Example user story:
As an internet banking customer
I want to see a rolling balance for my everyday accounts
so that I know the balance of my account after each transaction is applied

Example acceptance criteria:

  • The rolling balance is displayed
  • The rolling balance is calculated for each transaction
  • The balance is displayed for every transaction for the full period of time transactions are available
  • The balance is not displayed if a filter has been applied


Another example user story:
As a 
Snapper cardholder
I want to be able to pick up my pending credit from MySnapper (Note: MySnapper is a client applications for users to top up their ePurse, check their balance etc)
so that I have money on my ePurse


Example acceptance criteria:

  • I can see on MySnapper that there are pending credit(s) for my card
  • I can choose which credit(s) to pick up
  • I can see my new purse balance when I have chosen to pick up a credit
  • I can’t top up my card or buy a pass when there are pending credits for my card

(Personally, I like the “I”-format for acceptance criteria to keep focus on the user perspective rather than system centric view.)


Where do the details go?

What about details such as e.g.:

  • The column heading is “Balance”
  • The rolling balance format is 99,999,999,999.9 D/CR
  • We should use a dropdown rather than checkboxes


These kind of details normally come up in the conversation about the story with the product owner. This would be at the sprint planning meeting or when the team starts coding this particular story.

The details the team capture before coding go into two places:


1. Team internal documentation
The purpose of team internal documentation is solely to serve as a reminder for (potentially forgetful) team members. How much of the details need to be written down depends on the team and whether people write down any details at all is entirely up to them. (Note that this is different from external documentation such as e.g. a user guide which would be part of scope)


2. Automated acceptance tests
Acceptance criteria can be expressed in (almost) plain English for use by the chosen testing framework. This means that tests provide value as documentation, automated acceptance tests and as a feedback loop for developers doing BDD (An example using Cucumber here: http://cukes.info/ )

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




Leave a Reply

Your email address will not be published. Required fields are marked *