Acceptance Criteria For User Story

Purpose Of Acceptance Criteria?

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

*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 customerI want to see a rolling balance for my everyday accountsso 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 cardholderI 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 documentationThe 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 testsAcceptance 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