Writing User Stories (04/2012)

8,759 views

Published on

Presented at Macmillan Cancer Support in London on 26 April 2012

Published in: Technology, Business

Writing User Stories (04/2012)

  1. 1. Macmillan Cancer Support, April 2012
  2. 2. What itch is there to scratch? Software requirements are a communication problem People who want the software must communicate with those who will build it
  3. 3. Balance is paramount If either side dominates, the business loses If the business side dominates ...  ... functionality and dates are mandated with little regard for reality or whether the developers understand the requirements If the developers dominate ...  ... technical jargon replaces the language of the business and developers lose the opportunity to learn from listening
  4. 4. Domination leads to ...If developers are responsible ...• May trade quality for additional features• May only partially implement a feature• May solely make decisions that should involve the business sideIf the business is responsible ...• Lengthy upfont requirements negotiation and signoff• Features are progressively dropped as deadline nears• Features are continuously changed w/o understanding of impact
  5. 5. Imperfect schedules We cannot perfectly predict a software schedule  As users see the software, they come up with new ideas  Too many intangibles  Developers have a notoriously hard time estimating If we can’t perfectly predict a schedule, we can’t perfectly say what will be delivered
  6. 6. So what do we do? We make decision based on the ... but do it often information we have Rather than making ... we spread decision- one all-encompassing making across the set of decisions project This is were I come in!
  7. 7. What are user stories?Card• Stories are traditionally written on note cards• Cards may be annotated with estimates, notes, etc.Conversation• Details behind the story come out during conversations with the product ownerConfirmation• Acceptance tests confirm whether the story was coded correctly
  8. 8. Anatomy of a user storiesAs a <role>,I want <action that needs to be achieved>so that <goal the completed action achieves or contributes to>.Example:As an individual fundraiser,I want to be able to download the MacMillan logoso that I can use it to print all my fundraising material in high quality.
  9. 9. Stakeholder user storiesIn order to <achieve some outcome which contributes to the vision>As a <stakeholder>I want <some other stakeholder> <to do, use or be restricted by something>Example:In order to be in a position to launch phase 1 of SSOAs the head of digital mediaI want users to be able to login on Be.MacMillan using their My.MacMillan credentials well.
  10. 10. Examples As a user, I want As a photographer, I want to see a preview to order prints of of the photo book my photos before I order As a frequent flyer, I As a user, I want to rebook a past want to cancel trip so that I save my order time booking trips I take often
  11. 11. But ... where are the details? As a user, I want to cancel my order  Does the user get a full or partial refund?  Is the refund to user’s credit card or is it site credit?  How far ahead must the or der be cancelled?  Is that the same for all orders?  For all customers? Different requirements by market?  Is a confirmation provided to the user?  On-screen? Email? Letter?
  12. 12. a) Details as conditions of satisfation • The product owner’s conditions of satisfaction can be added to a story • These are essentially tests / acceptance criteria As a user, I  Verify that a VIP member can cancel the same day without a fee want to cancel  Verify that a non-VIP member is charged 10% for a same-day cancellation  Verify that any refunds are in site credits only my order  Verify that an email confirmation is sent  Verify that the factory is notified of any cancellation
  13. 13. b) Details added in smaller sub-stories As a VIP member, I want to cancel an order up to the last As a user, I minute want to cancel my order As a non-VIP member, I want to cancel my order within 24h of placing
  14. 14. Techniques can be combined Both approaches are not mutually exclusive Write stories at an appropriate level By the time it’s implemented, each story will have conditions of satisfaction associated with it
  15. 15. Product backlog pyramid User Stories Sprint Theme Collection of Release related user stories Epic Future A large user Releases story
  16. 16. Exercise 1 See how many user stories you can write about logging in Use this template “As a <user role>, I wan <goal> so that <reason>.” Examples:  As a registered user, I am required to log in so that I can access the system  As a forgetful user, I can request a password reminder to that I can log in if I forget mine
  17. 17. Writing good stories I ndependent N egotiable V aluable E stimable S mall / appropriately sized T estable
  18. 18. Independent As a user, I want As a user, I want to pay for my to pay for my order with VISA order with one type of credit card As a user, I want to As a user, I want pay for my order with to pay for my an additional type of order with credit card Mastercard
  19. 19. Negotiable As a user, I want to pay for my  order with my credit card Note: Accept Visa, MasterCard and American Express. Consider Discover As a user, I want to pay for my order  with my credit card Note: Accept Visa, MasterCard and American Express. Consider Discover. On purchases over £100, ask for card ID number from back of card. The system can tell what type of card it is from the 1st two digits of the card number. The system can store a card number for future use. Collect the expiration month and date of the card
  20. 20. Why negotiable? Main course comes with soup or salad and bread (Soup or Salad) and Bread Soup or (Salad and Bread)
  21. 21. Estimable It is important for developers to be able to estimate or at least take a guess at the size of a story 3 common failures 1. Developers lack technical knowledge 2. Developers lack domain knowledge 3. Story is too big
  22. 22. Small / Sized appropriately2 kind of epics1. Compound epic2. Complex epic Compound epic • Comprises of multiple shorter stories Complex epic • Cannot be easily disaggregated into smaller stories -> use spikes to find out how to split epics
  23. 23. Testable A user must find the software easy  to use A user must never have to wait long for any screen to appear 
  24. 24. Who writes them? The Product Owner!!!! Developers can help and write technical user stories if needed However, ultimate responsibility lies with the PO The PO is also responsible for prioritisation of stories
  25. 25. Story-writing workshops Include the whole team plus the product owner and possibly some more external stakeholders Typically not done every sprint Brainstorm to generate stories Goal is to write as many stories as possible  Some will be “implementation ready”  Others will be epics Start with epics and iterate NO PRIORITISATION at this point
  26. 26. Slicing Epics Goal: Develop slices of the problem that produces valuable working software with the potential to generate feedback from users. Sometimes the story slices are not deliverable to end- users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software.
  27. 27. Slicing considerations DTSTTCPW principle (=Do The Simplest Thing That Could Possibly Work) What are the different ways that you can handle input/output data ? • You can make a story per input screen. • You can make a story per enabled elements of an input screen. • You can make a simple (not pretty) UI prototype. What scenarios are in scope for acceptance criteria? • You can work with a subset of the input data. • You can defer conditional steps to other stories. • You can defer data validation. • You can defer error handling.
  28. 28. Slicing considerations What architecture decisions can be deferred? • You can defer optimisation of performance. • You can defer internationalisation • You can defer handling large volumes of data Worklow steps Performance Spikes Quality Things you know / don’t know
  29. 29. Horizontal slicing & sizing Try not to slice stories along technical lines Slice them horizontally for as long as you possibly can 1) Exercising every layer reduces risk of finding last minute problems in one of the layers 2) Application with reduced functionality can still be released Example: “A job user can post a CV” (epic) -> “A job seeker can fill out a CV form” -> “Information on a resume form is written to the db” Correct: -> “A job seeker can submit a CV that includes only basic information such as name, address and work history” -> “A job seeker can submit a CV with all information an employer may want to see”
  30. 30. Real world example
  31. 31. Exercise 2 Remember: 1. Who writes user stories? Employees can purchase 2. User role parking passes 3. User story format 4. Aim / goal / business value  As an employee I want to Buyer is charged fee for 1 month only time  One pass for one month is issues at a purchase a parking pass No pass is issued if payment is insufficient   so that I can drive to work Buyer must be can only buy one pass per a current employee  Any employee month
  32. 32. Exercise 3 Remember: 1. Who writes user stories? Users can sort cards by 2. User role popularity 3. User story format 4. Aim / goal / business value  User can sort by most popular 1st As a customer I want to  Timeframe for popularity is last 2 sort available cards by weeks popularity so that I can  Sorting mechanism works will all filters easily access the  Sorting takes no longer than 2 seconds bestsellers  User can un-sort without losing applied filters
  33. 33. Non-functional requirements For some requirements it’s inefficient to be captured in user stories because they apply to all of them  Example 1: “The system must support peak usage of up to 50 concurrent users”  Example 2: “Do not make it hard to i18n the software later if needed” Constraint Write constraint cards and The software must keep them visible run on all versions of Windows 2k +
  34. 34. Closed stories When breaking down stories aim for closed stories Closed stories end with the achievement of a meaningful goal  Example: “A user can reprint previous orders”
  35. 35. Keep UI out as long as possible Agile is about conversations and discussions Eventually inevitable Keep stories with UI elements until a later sprint when stories shift from being new functionality to being modification of existing functionality Example: “A user can select dates from a date widget on the search screen”
  36. 36. This smells Too many interdependent stories -> make stories larger or slice them differently Goldplating -> increase visibility of tasks & workload Too many details -> if you run out of room, use smaller cards Thinking too far ahead -> stop Splitting too many stories PO can’t prioritise -> close look at value
  37. 37. Recognising smells Developer responsibilities You share a responsibility with the PO to be aware of these smells as well as any others you may detect. Work and correct any that affect the project PO responsibilities You share a responsibility with the PO to be aware of these smells as well as any others you may detect. Work and correct any that affect the project

×