Writing User Stories (04/2012)

• 1. Macmillan Cancer Support, April 2012

2. What itch is there to scratch? Software requirements are a communicationproblem People who want thesoftware mustcommunicate withthose who will build it 3. Balance is paramount If either side dominates, the business loses If the business side dominates ... ... functionality and dates are mandated with littleregard for reality or whether the developers understandthe requirements If the developers dominate ... ... technical jargon replaces the language of the businessand developers lose the opportunity to learn fromlistening 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 thebusiness sideIf the business is responsible ... Lengthy upfont requirements negotiation and signoff Features are progressively dropped as deadline nears Features are continuously changed w/ounderstanding of impact 5. Imperfect schedules We cannot perfectly predict a software schedule As users see the software, they come up with newideas Too many intangibles Developers have a notoriously hard time estimating If we cant perfectly predict a schedule, we cant perfectly say what will be delivered 6. So what do we do?We make decision based on the ... but do it often information we haveRather than making... we spread decision- one all-encompassingmaking across theset of decisions project This is wereI come in! 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 duringconversations with the product ownerConfirmation Acceptance tests confirm whether the story wascoded correctly 8. Anatomy of a user storiesAs a ,I want so that .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 highquality. 9. Stakeholder user storiesIn order to As a I want 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 theirMy.MacMillan credentials well. 10. Examples As a user, I wantAs a photographer, Iwant to see a preview to order prints ofof the photo book my photos before I orderAs a frequent flyer, IAs a user, Iwant to rebook a past want to cancel trip so that I save my ordertime booking trips Itake often 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 users 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. a) Details as conditions of satisfation The product owners conditions of satisfaction can beadded to a story These are essentially tests / acceptance criteriaAs 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. b) Details added in smaller sub-storiesAs a VIP member, I want to cancel anorder up to the lastAs a user, Iminute want to cancel my order As a non-VIPmember, I want to cancel my orderwithin 24h of placing 14. Techniques can be combined Both approaches are not mutuallyexclusive Write stories at an appropriate level By the time its implemented, eachstory will have conditions ofsatisfaction associated with it 15. Product backlog pyramid UserStoriesSprintThemeCollection ofRelease related userstoriesEpic FutureA large user Releasesstory 16. Exercise 1 See how many user stories you can write about loggingin Use this template As a , I wan so that . 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. Writing good storiesI ndependentN egotiableV aluableE stimableS mall / appropriately sizedT estable 18. Independent As a user, I want As a user, I want to pay for my to pay for my order with VISAorder with onetype of creditcardAs a user, I want to As a user, I want pay for my order withto pay for my an additional type oforder with credit card Mastercard 19. NegotiableAs a user, I want to pay for myorder with my credit card Note: Accept Visa, MasterCard and American Express. Consider Discover As a user, I want to pay for my orderwith 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. Why negotiable?Main course comes with soup or salad and bread (Soup or Salad) and Bread Soup or (Salad and Bread) 21. Estimable It is important for developers to be able to estimate orat least take a guess at the size of a story3 common failures1. Developers lack technical knowledge2. Developers lack domain knowledge3. Story is too big 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. Testable A user must find thesoftware easyto useA user must never have to wait long for any screen to appear 24. Who writes them? The Product Owner!!!! Developers can help and write technical user stories ifneeded However, ultimate responsibility lies with the PO The PO is also responsible for prioritisation of stories 25. Story-writing workshops Include the whole team plus the product owner andpossibly 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. Slicing Epics Goal: Develop slices of the problem that producesvaluable working software with the potential togenerate feedback from users. Sometimes the story slices are not deliverable to end-users but they generate value from the learning gainedin producing them. They should all result in testable and demonstrablesoftware. 27. Slicing considerations DTSTTCPW principle (=Do The Simplest Thing ThatCould Possibly Work) What are the different ways that you can handleinput/output data ? You can make a story per input screen. You can make a story per enabled elements of an inputscreen. 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. 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 / dont know 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 minuteproblems in one of the layers 2) Application with reduced functionality can still bereleased 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 dbCorrect:-> A job seeker can submit a CV that includes only basic information such asname, address and work history-> A job seeker can submit a CV with all information an employer may want tosee 30. Real world example 31. Exercise 2Remember: 1.Who writes user stories? Employees can purchase 2.User roleparking 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. Exercise 3 Remember: 1. Who writes user stories? Users can sort cards by2. User role popularity3. User story format 4. Aim / goal / business value User can sort by most popular 1stAs a customer I want to Timeframe for popularity is last 2sort available cards byweekspopularity so that I can Sorting mechanism works will all filters easily access the Sorting takes no longer than 2 secondsbestsellers User can un-sort without losing applied filters 33. Non-functional requirements For some requirements its inefficient to be captured in user stories because they apply to all of them Example 1: The system must support peak usage of upto 50 concurrent users Example 2: Do not make it hard to i18n the softwarelater if neededConstraint Write constraint cards andThe software must keep them visible run on all versions of Windows 2k + 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. Keep UI out as long as possible Agile is about conversations and discussions Eventually inevitable Keep stories with UI elements until a later sprint whenstories shift from being new functionality to beingmodification of existing functionality Example: A user can select dates from a date widgeton the search screen 36. This smells Too many interdependent stories -> make storieslarger or slice them differently Goldplating -> increase visibility of tasks & workload Too many details -> if you run out of room, use smallercards Thinking too far ahead -> stop Splitting too many stories PO cant prioritise -> close look at value 37. Recognising smells Developer responsibilitiesYou share a responsibility with the PO to be aware ofthese 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 ofthese smells as well as any others you may detect.Work and correct any that affect the project