Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Writing Effective User stories
       Presented by Carlo Kruger
            December 2009
What were they thinking?
•Split into teams, with one product owner
•Product owners may only communicate with the team
 thr...
Moka Pot
Dentist Chair
Motorcycle RV
Communication problem
The system must store an address and business phone or mobile phone




1      Address +
   (busines...
Dude, where’s my car?

•Product shall
 •Have a gas engine
 •Four wheels
 •Rubber tire on each wheel
 •Has a steering wheel...
Focus on intention

•As a user I want to
 mow my lawn quickly
 and easily
•As a user I want to
 be comfortable while
 mowi...
So now what?

We make decisions based
                                          ...but we do it often
  on the info we hav...
The Product Backlog iceberg

                               {
    1-2 sprints worth of stories    Stories

               ...
What are epics?


•Large fuzzy requirements
•Lower priority
•May consist of a number of features
What’s a feature?



•A set of requirements which can be grouped
•which deliver value to a group of users
What are user stories?


As a:    <user role or persona>
I want to: <do something, a piece of functionality>
So that: <ach...
The 3 C’s
                     •Stories are traditionally
                      written on note cards
   Card
            ...
But what about the details?
•As a user I want to be able to cancel a reservation so
 that I can get a refund for the trip ...
Acceptance tests
 Given: it is 2 weeks till my flight and I paid $1000 for
 the flight and I am not a frequent traveler
 Whe...
The Happy Path


•Every story should define the default scenario
 •similar to happy path in a use case
 •extend with negati...
Coin Sorting
                 (an exercise)




How long will it take to sort this bag of coins?
Talking to users
•Ask open ended questions
 •closed = “Yes or No”
 •open = “What would you be willing to trade for
  perfo...
Story writing with your
             customers

•Low fidelity prototypes to get the main flows
•Get breadth first
•Use user r...
User Roles

•allow users to vary by
 •what they use the software for
 •how they use the software
 •background
 •familiarit...
Role modelling
• Every product has more than one type of user
 • administrators
 • clerks
 • managers
• when we write with...
An extreme user modelling story
What makes a good story?
                 Independent

                  Negotiable

INVEST            Valuable

         ...
INVEST
•Independent
 • Dependencies lead to prioritisation problems
•Negotiable
 • Stories are not contracts
 • leave the ...
INVEST
•Estimable
 • we plan using user stories so we must be able to estimate them

•Small (sized appropriately)
 • Compo...
What makes a good user story?
•It describes what a user does
•Explicitly states dependencies
•Takes a slice through the sy...
Non-functional requirements
  “...is a requirement that specifies criteria that can be used to judge the operation of a
  s...
Formulate NFR’s as a story

                                    Acceptance Criteria
  Performance Constraint
             ...
Linking to functional
                       requirements

Theme                Functional requirement                Perf...
Technical Stories
• Adding CI, optimising DB, upgrade to latest Oracle, etc.
  • Consider trying to write a user story so ...
Decomposing user stories
• Compound Stories
 • a number of smaller stories / scenarios
 • split into meaningful chunks
• C...
Patterns for splitting stories
• Workflow steps
• Business rule variations
• Major / Minor effort
• Simple / Complex
• Vari...
When do I write stories?

•5-10% of total team effort should be spent on
 preparing for the next sprint

 •i.e. about 50% ...
Story writing workshops
•Include team, users, customers
•Brainstorm to generate ideas
•Write as many as possible
 •Start w...
Story Workshop
                                  ets is
                                         over
                    ...
Story smells

•Too small or too big
•Estimates don’t converge
•No scenarios / acceptance criteria
•Interdependent
•Gold-pl...
More smells
•Too detailed
•UI defined
•Thinking too far ahead
•Splitting too frequently
•Trouble prioritising
•Technical la...
Use cases vs. user stories
•Size
 •User stories much smaller than use cases
•Completeness
 •use cases are exhaustive, user...
References

•Mike Cohn - ‘User Stories Applied’
•Leffingwell & Behrens - ‘A User Story Primer’
•Victoria Hall - ‘Crafting B...
Upcoming SlideShare
Loading in …5
×

Writing Effective User Stories

18,859 views

Published on

Intended as a presentation for scrum product owners and analysts. A crash course in writing good user stories

Published in: Technology
  • Carlo, Very valid point. In most software projects the user (as compared to the admins, managers, help desk who after all are really stakeholders) are usually those called on to contribute to the stories. How do you bring in the other 'users' so that as the features of the product are developed the full set of stories is captured early to avoid recoding to bring the product into line with goals of all stakeholders?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Nice job
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Writing Effective User Stories

  1. 1. Writing Effective User stories Presented by Carlo Kruger December 2009
  2. 2. What were they thinking? •Split into teams, with one product owner •Product owners may only communicate with the team through imperatives (“it must have/do...”) or similes (“it’s like...”) •Cannot use the name of the thing in a sentence (“it must pour tea” for a teapot is not allowed) •Teams cannot ask questions •Teams have 2 minutes to draw the object seen by the PO
  3. 3. Moka Pot
  4. 4. Dentist Chair
  5. 5. Motorcycle RV
  6. 6. Communication problem The system must store an address and business phone or mobile phone 1 Address + (business phone or mobile phone) (Address + business phone) or mobile phone 2
  7. 7. Dude, where’s my car? •Product shall •Have a gas engine •Four wheels •Rubber tire on each wheel •Has a steering wheel •Has a steel body
  8. 8. Focus on intention •As a user I want to mow my lawn quickly and easily •As a user I want to be comfortable while mowing my lawn
  9. 9. So now what? We make decisions based ...but we do it often on the info we have This is where user stories come Rather than make one in ...we spread decision- set of all-encompassing making across the decisions project
  10. 10. The Product Backlog iceberg { 1-2 sprints worth of stories Stories ould sh ed Features ll y a ress ea ll Id xp ies! e e or ti ll b r s t s a su se Epics / Themes
  11. 11. What are epics? •Large fuzzy requirements •Lower priority •May consist of a number of features
  12. 12. What’s a feature? •A set of requirements which can be grouped •which deliver value to a group of users
  13. 13. What are user stories? As a: <user role or persona> I want to: <do something, a piece of functionality> So that: <achieve some business value or statement of intent>
  14. 14. The 3 C’s •Stories are traditionally written on note cards Card •Cards may be annotated with estimates, tests, etc •Details of story come out Conversation during conversations with product owner •Acceptance tests confirm Confirmation the story was coded correctly
  15. 15. But what about the details? •As a user I want to be able to cancel a reservation so that I can get a refund for the trip not taken • Does the user get a full or partial refund? • Is the refund to the credit card or is it a site refund? • How far ahead must the reservation be cancelled? • Is it the same for all hotels? • How about all site visitors? Can frequent travellers cancel later? • Is a confirmation provided to the user? • How do provide this confirmation?
  16. 16. Acceptance tests Given: it is 2 weeks till my flight and I paid $1000 for the flight and I am not a frequent traveler When: I cancel my flight Then: I get a 50% refund ($500) and my flight is cancelled •Describes starting state, event and final state •Use ‘real’ examples with meaningful values
  17. 17. The Happy Path •Every story should define the default scenario •similar to happy path in a use case •extend with negative scenarios and edge cases
  18. 18. Coin Sorting (an exercise) How long will it take to sort this bag of coins?
  19. 19. Talking to users •Ask open ended questions •closed = “Yes or No” •open = “What would you be willing to trade for performance?” •Give user options (“This one or that one?”)
  20. 20. Story writing with your customers •Low fidelity prototypes to get the main flows •Get breadth first •Use user roles / personas to help identify missing stories •Compare against competing products
  21. 21. User Roles •allow users to vary by •what they use the software for •how they use the software •background •familiarity with software / computers
  22. 22. Role modelling • Every product has more than one type of user • administrators • clerks • managers • when we write with only one perspective • we assume all users have the same goal • leads to missing stories
  23. 23. An extreme user modelling story
  24. 24. What makes a good story? Independent Negotiable INVEST Valuable Estimable Small Testable
  25. 25. INVEST •Independent • Dependencies lead to prioritisation problems •Negotiable • Stories are not contracts • leave the team room to manoeuvre •Valuable • to users or customers (rarely if ever developers) • try to rewrite developer stories to reflect value to the customer
  26. 26. INVEST •Estimable • we plan using user stories so we must be able to estimate them •Small (sized appropriately) • Compound stories are multiple stories • Complex stories are intrinsically large •Testable • if you can’t test it, how do you know when you’re done?
  27. 27. What makes a good user story? •It describes what a user does •Explicitly states dependencies •Takes a slice through the system •Ends with a meaningful goal • instead of “a home seeker can maintain her search criteria” • a home seeker can create her search criteria • a home seeker can review the results of a search • a home seeker can change the geographic area of a search
  28. 28. Non-functional requirements “...is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours” - Wikipedia • Security • Usability • Testability • Maintainability • Extensibility • Scalability • Portability • Performance
  29. 29. Formulate NFR’s as a story Acceptance Criteria Performance Constraint •10,000 concurrent R/W transactions take place The system must answer any request in less than 1 second •Each transaction is 500Kb •System config is ‘small enterprise’
  30. 30. Linking to functional requirements Theme Functional requirement Performance Security Robustness As an enterprise user, I want to select a Emailing recipient from my contact list, so that I can X X get the correct address
  31. 31. Technical Stories • Adding CI, optimising DB, upgrade to latest Oracle, etc. • Consider trying to write a user story so that you are forced to define the business value • No user facing functionality, e.g. Rating engine consumes some output • Consider writing as a user story with the engine as the user • e.g: As the rating engine, I want well formed CDR’s so that I can minimise error logging • Don’t hurt yourself trying to force it; sometimes it’s OK not to use the format • Be careful that these aren’t tasks that have been elevated to stories...
  32. 32. Decomposing user stories • Compound Stories • a number of smaller stories / scenarios • split into meaningful chunks • Complex Stories • if it’s largely unknown, consider a spike • try find ‘natural’ seams in the story • Combining stories • stories should be about 2 days work • if too small combine e.g. bugs into one story
  33. 33. Patterns for splitting stories • Workflow steps • Business rule variations • Major / Minor effort • Simple / Complex • Variations in available data • Data entry methods • Defer performance • Operations (e.g. create / update / delete) • Spike
  34. 34. When do I write stories? •5-10% of total team effort should be spent on preparing for the next sprint •i.e. about 50% of analyst’s time in sprint •still need to be available to team (should be answering 80% of queries in <10min) •estimation meetings in off-week
  35. 35. Story writing workshops •Include team, users, customers •Brainstorm to generate ideas •Write as many as possible •Start with epics and iterate •or use mindmaps •Prioritise later
  36. 36. Story Workshop ets is over paid tick rrest eds its I f th R50 e tot 00, t al un wa rrant hen a If a warran rt ued. of a Cops & Fines t of e cou E ach p own re olice sta port of o tion ne verdue tickets be is s en th rrest m ust issue d, th st is the a The viola arr e ed of be set tion mus t be i nform e can master l ist of ve t be link e d to a mus ria l dat Our officers now carry GPS units, so the hicles. W so th at a t co-ordinates of the offence must be the vehi cle manu e also n type (se facturer ee d logged on the ticket. The officer will dan, SUV , colo ur, It wo reg istrat , etc) an login to the mobile app using their ion d uld b phot e so badge number and password ogra cool of th ph o if the e vio r vid show latio eo cl n on n cou ip a Go ld be ogle We would like to ‘name and Map shame’ top offenders on our officer FaceBook page automatically, nnual bo nus of an The a ber of on the 1st of each month is linke d to the nu m s that h ave been violation n d pai d Credit & thanks to Aslam Khan for the stories issue d a
  37. 37. Story smells •Too small or too big •Estimates don’t converge •No scenarios / acceptance criteria •Interdependent •Gold-plating
  38. 38. More smells •Too detailed •UI defined •Thinking too far ahead •Splitting too frequently •Trouble prioritising •Technical language
  39. 39. Use cases vs. user stories •Size •User stories much smaller than use cases •Completeness •use cases are exhaustive, user stories much less detail •Longevity •use cases intended as permanent record, user stories rarely last beyond the sprint
  40. 40. References •Mike Cohn - ‘User Stories Applied’ •Leffingwell & Behrens - ‘A User Story Primer’ •Victoria Hall - ‘Crafting Better Scrum Requirements’ •Mike Cohn - ‘An introduction to user stories’ •Roman Pinchler - ‘Agile Product Management with Scrum’

×