On Acceptance criteria for user stories

One of the teams I have recently coached quickly got a grasp of how to phrase user stories but found it hard to relate to the concept of acceptance criteria.

I wrote this short FAQ as an attempt to make it easier for my team to work with acceptance criteria and hope that other teams might find this useful too:

What’s the purpose of acceptance criteria?

Acceptance criteria*:

• Define the boundaries for a user story/feature
• Help the product owner answer what they need in order for this feature to provide value (typically these are the minimum functional requirements)
• Help the team gain a shared understanding of the story/feature
• Help developers and testers to derive tests
• Help developers know when to stop adding more functionality to a story

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/ )