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.

Tips

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.