User Stories
Post on 28-Nov-2014
5157 Views
Preview:
DESCRIPTION
Transcript
© SMC 2008
User Stories
© SMC 2008
User Stories
• What Are User Stories?
• Story Format
• Acceptance Criteria
• Sizing Stories
• Questions
© SMC 2008
What Are User Stories?
• 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.
© SMC 2008
What Are User Stories?
• 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.
© SMC 2008
A Real Life Story CardStory Title
Story #
Effort Estimate
Acceptance Criteria
Status Indicators•Dev Started•Dev Finished•Tester tested•Customer accepted
© SMC 2008
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’.
© SMC 2008
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
© SMC 2008
A Simple Example
Step Expected Result
1 – Go to the site homepage
See a test banner ad of size 728x90 appear at the top of the page.
2 – Click on the advert. A new window opens displaying the site the advert was linked to
I want a banner ad to appear at the top of the homepage
Marketing Person
© SMC 2008
A Simple Example
Step Expected Result
1 – Go to the site homepage
See a test banner ad of size 728x90 appear at the top of the page.
2 – Click on the advert. A new window opens displaying the site the advert was linked to
So they tell me this is done.. Let’s see..
Step 1 – yep..
Step 2 – okay..
..perfect, I can sign this off.
© SMC 2008
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…
© SMC 2008
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
© SMC 2008
Or More Technical Criteria..
Step Expected Result
1 – Go to the holding area \\server1\temp
Find the weekly delivery zip file e.g. 090107.zip.
2 – Open a command line and run the conversion tool, e.g. makerss <nameofzip>
An XML file entitled DDMMYY.xml appears in the directory.
3 – Examine XML file. The XML file follows the RSS2.0 structure described in the attached document.
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
© SMC 2008
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..!
© SMC 2008
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.
© SMC 2008
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…
© SMC 2008
Breaking Stories Down
• Much too large ‘stories’ are often referred to as ‘epics’. These can always be split into component parts.
© SMC 2008
Breaking Stories Down
• Much too large ‘stories’ are often referred to as ‘epics’. These can always be split into component parts. Show Book TitleShow Cover Image
Show Price
Show Discount
Show Stock Status
© SMC 2008
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.
© SMC 2008
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.
© SMC 2008
Questions?
top related