20
© SMC 2008 User Stories

User Stories

Embed Size (px)

DESCRIPTION

A short presentation about writing requirements in the form of user stories for use in agile development projects.

Citation preview

Page 1: User Stories

© SMC 2008

User Stories

Page 2: User Stories

© SMC 2008

User Stories

• What Are User Stories?

• Story Format

• Acceptance Criteria

• Sizing Stories

• Questions

Page 3: User Stories

© 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.

Page 4: User Stories

© 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.

Page 5: User Stories

© SMC 2008

A Real Life Story CardStory Title

Story #

Effort Estimate

Acceptance Criteria

Status Indicators•Dev Started•Dev Finished•Tester tested•Customer accepted

Page 6: User Stories

© 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’.

Page 7: User Stories

© 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

Page 8: User Stories

© 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

Page 9: User Stories

© 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.

Page 10: User Stories

© 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…

Page 11: User Stories

© 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

Page 12: User Stories

© 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

Page 13: User Stories

© 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..!

Page 14: User Stories

© 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.

Page 15: User Stories

© 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…

Page 16: User Stories

© SMC 2008

Breaking Stories Down

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

Page 17: User Stories

© 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

Page 18: User Stories

© 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.

Page 19: User Stories

© 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.

Page 20: User Stories

© SMC 2008

Questions?