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..
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 http://whendoitest.com.
- 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.