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 she needs 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 correctly
  • The rolling balance is calculated correctly 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/ )

 

 

Sandy Mamoli – who has written posts on Nomad8.


  • LiNk MaN

    A great to the point description of acceptance criteria. Explained clearly and coincisly without the dribble like most forums. Thankyou very much, found at very useful.

  • David

    Great introduction to acceptance criteria! Thanks! A must read for all my team members.

  • Nicolas

    Good example! and excellent post, It helps me to understand a little more. But I have a question, who is the responsible of creating the Acceptance criteria?
    If you are applying TDD, I think the best person responsible of this would be QA team.

    Thanks.
    Nicolas

    • http://www.nomad8.com/ Sandy Mamoli

      Hi Nicolas,

      Thank you for your nice words :-)

      I think that the person who “owns” the user story is also responsible for the acceptance criteria. If you think about that the acceptance criteria really are the boundaries of the story then they need to be defined by the that same person.

      To make sure that the acceptance criteria are good and phrased in a way that testers can derive acceptance tests from them I think it is very important that test /QA is involved in the creation of acceptance criteria.

      So, I guess in terms of your question: I think the story owner is “responsible” for acceptance criteria and QA are “involved”. QA, however, own the acceptance tests.

      In a cross-functional agile team the story owner would be the product owner and QA would be responsibility of the team. Based on your questions I assume that in your context you have a dev, QA and maybe other teams such as BA. In that case I’d have PO/BA own the acceptance criteria and involve the QA team as early as possible.

      I hope that’s helpful.

      Sandy

http://nomad8.com/wp-content/themes/selecta