Elaborating user stories by using acceptance tests

Elaborating stories using acceptance tests involves defining the criteria for stories before turning them into code. This is the approach we often teach in agile courses.

For example, if I have the story:

As an Iphone user I want to SMS my friends to that I can share my experiences with them

Then the team come up with a series of tests along the lines of “given the user is on the SMS screen, when he/she presses the send button then the SMS will be sent”.

Given When Then
The user is on the SMS screen The user hits the cancel button The Iphone will ask “are you sure”
The user is on the SMS screen The user presses the content section with his/her finger The keypad will be displayed
The date is leprechaun’s birthday The user enters any text The iPhone will convert the text to Leprechaun Gaelic.

These acceptance tests are an excellent way to define the solution space for the developer and are often used in conjunction with any or the remaining approaches I will describe.

More often than not, teams use acceptance tests as a base but provide more information for stories.

Generally speaking I would add a simple “narrative” if the subject matter expert is not sitting with the developer. This is a short summary of the context of the story (one or two paragraphs of text).

I also find a simple sketch or model (with comments) to be of real value to capture some of the understanding, rather than listing everything in acceptance tests.


In addition to this, sometimes I find that some complex business rules end up as 28 acceptance tests when one decision table (or diagram) can cover the same information. So I replace several of the tests (which would otherwise be in “Given … When … Then…” format with a decision table like the following one:

User setting Refuse to send SMS Attach location settings Create audit record Confirm send
Child emergency use only and number entered is not parents Yes Yes Yes No
Novice No Yes Yes Yes
Undercover cop or criminal No No No No
Otherwise No Yes No No

It is not the role of any one person to create the acceptance tests. Rather, they are created through the collaboration of the tester, business analyst, subject matter expert and developer.

If the same test keeps appearing then convert it to a standard, so that it is taken into account by default when coding or testing.

When doing acceptance tests in conjunction with other information, do the tests first and then see if any can be added when other approaches to elaboration have been completed. Doing the tests first often clarifies understanding quickly and saves work in narratives, etc.

Watch out for

Acceptance tests are not a contract. The developer should question and add to the tests during development as questions and decisions emerge.

Acceptance tests are hard and very useful. If you are finding it hard to create them then skipping them will often result in development and testing taking longer rather than saving time.

The above list is not a finite list of information to provide. Teams should feel free to create data models, lists of constraints and risks, references to development standards etc. The acceptance tests are the framework for understanding not the complete understanding.

Some teams start to fall into what I call “panic waterfall” where developers expect every nuance to be documented. But the rule of sum should be to only document what cannot be reliably communicated through a conversation while the developer is working. That’s why I like the acceptance test approach – it allows the team to think about the outcomes before starting on the code, while leaving room for exploration by the developer while creating the code.


5 thoughts on “Elaborating user stories by using acceptance tests

  1. Nice post. Do you have any thoughts on who should write user stories and acceptance tests down? Michael Cohn suggests that the conversation between product owner and team is most important. (Who does the writing is less important.)

    Did you have any thoughts on this from your experience?

  2. Pingback: Scrum – Definition of Done (DoD) | O'Mara Consulting Associates

  3. Pingback: Confluence: Engineering

  4. Pingback: Some comments on story collaboration sessions | James King

  5. Pingback: Writing User Stories within IBM Rational Team Concert – Strongback Consulting

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s