Another post on the web about user stories

A few weeks ago we had a discussion about user stories, tasks and acceptance criteria. The aim was to discuss stories and acceptance criteria, how to format them and agree on a common language and understanding for these artefacts within our organisation.

User stories (and tasks)

At the moment we rely on stories written on post its to manage our development iterations. The detail of these stories isn’t as high as most would desire, leaving us with ambiguous, one or two word descriptions of a more complex requirement. As such tasks exist which try to fill a gap from an implementation perspective.

Mike Cohn defines a story as one thing a customer wants the system to do; others have also added that it should be something that can be scoped, agreed on, estimated and tested against. While our current story writing isn’t impeding us, and one or two words may suffice to communicate a common understanding amongst teams, there are benefits to fleshing out a story in the right format.

A good story should include the user’s perspective, a description of the requirement and the business benefit:

Title: E-mail results page
As a user looking to perform a comparison of different products
I want to email myself the results of my comparison
So that I can view my results offline (and speak to / argue with my missus about the best deal).

This is just one variation of the format. Others include In order to.., As a.., I want to..

And tasks?

For us, tasks evolved from somewhere and refer to implementation, which for something that should be accessible to the business is bad. While it isn’t criminal to think about implementation, especially for estimating complexity, those details are best left on your notepad rather than your story/kanban wall. Just because you’ve created your website and got it talking to your database doesn’t mean your story of making a blog is complete. Tasks don’t let us measure progress or describe testability; stories demonstrating business value and use cases do.

User stories? Check. Burnt all those tasks? Check. What next?

Acceptance criteria, baby! Each story should have a number of acceptance criteria that describe a specific scenario or example. These will guide development, form the basis of your testing and ultimately indicate release-ability of the story. E.g. done, or done-done, or if youíre still kidding yourself, done-done-done-done (coded-testedhuh?tested?brokenfixed-retested-live).

Acceptance criteria look like:

Scenario 1: Clicking the link on the results page to enter my email address
Given I am on the results page
When I click on the link reading ‘E-mail yourself these results’
Then I should see a pop-up box asking for my name and email address

Secnario 2: Sending my results to a valid email address
Given I am on the results page
And I’ve clicked on the link to send the results to myself
When I enter a valid name and email address and hit the send button
Then The email should be sent
And A message should appear telling me so

The Given and the Then part can have extra And statements. The scenarios and examples covered in the criteria should include not only happy-paths but obscure, yet plausible routes through the system, e.g. what defines a valid name and email address?

From a development point of view, the behaviour described in well-written acceptance criteria will provide us with a starting point for BDD. Being an outside-in approach, you can drill down further and further to a unit level.

From a testing perspective, each acceptance criteria provides us with a minimum baseline to test for. Baseline because there’s all the other testing to do too, like integration (when you get more and more criteria and stories complete), browser compatibility, usability, exploratory etc. See

Further discussion:

  • How does this fit in with kanban? (Minimum Marketable Features…)
  • How do you write stories and criteria when thinking about slices?
  • Where should estimation fit in, per story?
  • When do we write the acceptance criteria, in spec workshops? On demand?
  • Can we make the acceptance criteria executable? Mmmmwwwwahaha now you’re talking!

I’ll try discuss some of the above soon.


4 Responses to “Another post on the web about user stories”

  1. 1 Jen 23 April, 2009 at 6:00 pm

    Done-done-done-done-done aside (how about done squared and done cubed!), how do you tell when you are done writing user stories? Or is it an iterative approach? In my experience there is always something you miss so having the ability to go back and thrash it out again is going to be useful. (that ’emailing the results’ thing is what got me thinking about how complicated simple stories can be!).

  2. 2 Hemal Kuntawala 23 April, 2009 at 7:45 pm

    You should know when you’re done writing a story, it should describe a piece of functionality – I’m guessing you meant acceptance criteria. So, start with the happy paths and and go from there…

  1. 1 How we build quality software « Hemal: Developer In Test Trackback on 15 August, 2009 at 3:36 pm
  2. 2 From bug hunting to bug prevention « Hemal, Developer in Test Trackback on 27 January, 2010 at 10:38 am

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: