User Stories

User Stories
What Are User Stories?
Story Format
Acceptance Criteria
Sizing Stories
Questions

They are a way of capturing requirements that works well for agile development.
They’re a simple description of a discrete bit of functionality which can be implemented inside one iteration.
They’re written on index cards for use in planning or development.

They comprise a description of the bit of functionality in question, supporting information such as UI snippets, and a set of acceptance tests.
The literature gives various ‘templates’ for how stories should be written. Most teams will evolve their own format which works for them.

A Real Life Story Card Story Title Story # Effort Estimate Acceptance Criteria
Status Indicators
Dev Started
Dev Finished
Tester tested
Customer accepted

Story Format
A number and simple descriptive title.
The standard format has a description like:
As a <type of actor> I want to be able to <do something> so that I <reason for doing>.
E.g. As a site administrator I want to be able to edit the homepage so that I can update the marketing promotions .
It’s useful to think about why and for whom you want to do things, but it gets a bit cumbersome. In practice this description might get condensed to ‘ Edit Homepage ’.

Acceptance Criteria
Most of the detail in stories comes in the ‘acceptance criteria’.
These are written from the perspective of the person requesting the functionality.
They describe what the person had in mind, and allow the team to determine when the story is done .
They’re effectively a little UAT script

A Simple Example I want a banner ad to appear at the top of the homepage Marketing Person A new window opens displaying the site the advert was linked to 2 – Click on the advert. See a test banner ad of size 728x90 appear at the top of the page. 1 – Go to the site homepage Expected Result Step

A Simple Example So they tell me this is done.. Let’s see.. Step 1 – yep.. Step 2 – okay.. ..perfect, I can sign this off. A new window opens displaying the site the advert was linked to 2 – Click on the advert. See a test banner ad of size 728x90 appear at the top of the page. 1 – Go to the site homepage Expected Result Step

Acceptance Criteria
Whatever the ‘bit of functionality’ is, it’s being done for a reason. It delivers value to someone:
End user (proxied by product team)
Developers
Site Administrator
Architect
Etc
Identify who is asking for the functionality, and hence who will sign it off. They define the acceptance criteria…

What About Technical Stories? I want to move the login code to the new controller framework… so my acceptance criteria are that I swap out the code and all the existing tests still pass! A Developer

Or More Technical Criteria.. I want to be able to produce an RSS feed out of the manifest XML that arrives as part of a data delivery. Format spec <rss> <channel> </channel> <item> … </rss> Note that it doesn’t say – “run x file through xsl stylesheet and..” – the person signing off can’t see that and doesn’t care how it works. Production Guy The XML file follows the RSS2.0 structure described in the attached document. 3 – Examine XML file. An XML file entitled DDMMYY.xml appears in the directory. 2 – Open a command line and run the conversion tool, e.g. makerss <nameofzip> Find the weekly delivery zip file e.g. 090107.zip. 1 – Go to the holding area erver1 emp Expected Result Step

Acceptance Criteria vs Testing
Acceptance criteria should include general error scenarios:
“ Attempt to submit the form with an invalid username - see client side error x.”
But a product owner is not a professional tester and stories will not cover every possible detailed issue.
What happens if I enter an &? Or quotes? Or a Chinese character? Break, damn you..!

How Big Should Stories Be?
Stories should describe a discrete, logical piece of functionality.
They should be the right size for your iteration lengths – they must be developed, tested and signed off within one iteration.
Smaller is usually better. Smaller stories are easier to write, easier to estimate and easier to test.

Judging Story Size
With experience you get a feel for how big a story is likely to be. If in doubt, ask the advice of the developers.
Too-large stories can almost invariably be split up. Again the developers can help identify logical breaks.
I want a banner advert at the top of the homepage. If a user logs in I want it targeted by their country of origin, and by their special interests. I want an admin system so that I can set up the ad. I want a…

Breaking Stories Down
Much too large ‘stories’ are often referred to as ‘epics’. These can always be split into component parts.

Breaking Stories Down
Much too large ‘stories’ are often referred to as ‘epics’. These can always be split into component parts.
Show Book Title Show Cover Image Show Price Show Discount Show Stock Status

Questions These type of “requirements” miss loads of detail. What about…? They aren’t meant to capture every conceivable detail. Remember this is an agile project. If something is missing you go ask.. And the customer has to give you an immediate answer. It’s all about conversation.

Questions Won’t a product designed this way be an incoherent collection of tiny pieces? That can happen, if you don’t do it properly. It is very important to keep thinking about your overall product vision and how each story contributes to the whole.

Questions?

http://www.slideshare.net	26
http://www.jaffamonkey.co.uk	5
http://static.slidesharecdn.com	1
http://www.lmodules.com	1

User Stories

by scornelius

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 33

Statistics

User Stories Presentation Transcript