Supercharge Your Product Backlog With User Stories
•Download as PPTX, PDF•
2 likes•1,108 views
This document summarizes a workshop on supercharging a product backlog with user stories. The workshop covers defining user stories, examples of user stories, splitting large stories into smaller ones, acceptance criteria, and product backlog refinement. Attendees participate in hands-on exercises to practice writing, critiquing, and splitting user stories. The document emphasizes that user stories should describe features from the perspective of users or stakeholders and focus on value and benefits.
Recommended
Recommended
More Related Content
Similar to Supercharge Your Product Backlog With User Stories
Similar to Supercharge Your Product Backlog With User Stories (20)
Recently uploaded
Recently uploaded (20)
Supercharge Your Product Backlog With User Stories
- 1. Supercharge Your Product Backlog With User Stories (Suzanne Morrison & Laz Allen, XP 2016)
- 2. Welcome & Introductions Introductions Laz Allen Suzanne Morrison https://www.linkedin.com/in/suzannem @SuzanneMorrison https://www.linkedin.com/in/lazallen @LazAllen
- 3. What we’ll cover What we will cover in this workshop + Lots of hands on practical exercises & plenty of time for questions!
- 4. Workshop DOD
- 5. Traveling Smarter Skyscanner – Why (Laz)
- 6. The world’s travel search engine
- 7. Skyscanner Squads and Tribes Model Skyscanner Squads and Tribes
- 8. Agile Coaches at Skyscanner
- 10. Product Backlog
- 11. The Product Backlog Top of Backlog • Well understood • Better defined • Smaller • Better Prioritised Bottom of Backlog • Less understood • Less defined • Large / Epic size • Roughly Prioritised PRODUCT BACKLOG VISIBLE TO ALL
- 12. Product Requirements Challenges What Requirements Challenges / Problems have you had in the past?
- 14. Introducing User Stories User Stories are often used as a way of expressing requirements in Agile development. As a <user role> I want to <goal> so that <benefit> Describes the what, not the how
- 15. The 3 C’s – Card, Conversation, Confirmation CARD CONVERSATION CONFIRMATION Source: Ron Jeffries, originally used in XP The Three C’s
- 16. Examples of user stories As a frequent traveller I want to be able to quickly find a flight that I have previously taken so that I can save time booking flights that I take often.
- 17. Examples of user stories As a leisure traveller I want to be able to browse high quality photos of the hotels so I can find one that I know I will like.
- 18. Examples of user stories As a business traveller I want to be able to find flights with the shortest duration as I want to travel to my destination as quickly as possible.
- 19. Examples of user stories As any type of user I want to be able to quickly see the amenities that a hotel offers so that I can be sure that it has the amenities that are most important to me.
- 20. Alternative User Story Formats We believe that __ (Customer) __ Would like __ (Feature or Function)__ So that __ (Value) __ And to validate this we will __ (hypothesis test) __
- 21. Alternative User Story Formats In order to <achieve some business value> As a <stakeholder type> I want some <new system feature>
- 22. Who is the User? Does the user have to be a real user?
- 24. Practical Exercise 1 – Home Improvements Exercise 1 -Home Improvements Project 1. Choose a Product Owner 2. Read through the list of home improvement requirements 3. Use the template below to write user stories for some of the requirements (Timebox = 15 minutes) “As a <user role> I want to <goal> so that <benefit>”
- 25. How to Write Good User Stories
- 27. Practical Exercise 2 – Critique a Story Exercise 2 - Critique a Story 1. Split into pairs (or triads) 2. Pick one story from earlier 3. Discuss how the story could be improved (2 mins) 4. We’ll ask a couple if you to tell us about how you’d improve this (Timebox = 2 minutes)
- 28. Beware of Story Mania!
- 29. How to Split User Stories
- 30. Why Split User Stories? Why Split User Stories? • It makes them easier to understand • It makes them less risky • They’ll be easier to estimate • Estimates are likely to be more accurate • Quicker to implement, allowing you to release value to the user earlier and more often.
- 31. Splitting Stories Split Vertically Rather than Horizontally Splitting vertically allows you to deliver value to the user earlier Web UI Middleware Data Layer Pay order manually Pay order with PayPal Pay order with credit card
- 32. Patterns for Splitting Stories 5 Patterns for Splitting Stories 1. Operations 2. Input Method Separation 3. Business Rules 4. Interface Simplification 5. Roles Handy downloadable poster: http://agileforall.com/resources/how-to-split-a-user-story
- 33. Example of Story Splitting by Operation As a frequent traveller I’d like to be able to manage my trips… As a frequent traveller I’d like to be able to create new trips As a frequent traveller I’d like to be able to edit existing trips As a frequent traveller I’d like to be able to delete old trips Split by Operation
- 34. Example of Story Splitting by Business Rule As a traveller I’d like to see only the flights that are suitable for me… As a user I’d like to be able to filter flights under a certain duration As a user I’d like to filter flights within a certain price range As a user I’d like to be able to filter flights based on airline Split by Business Rule
- 35. Example of Story Splitting by input type As a traveller I’d like to be assisted to enter destinations As a user I’d like the system to suggest destinations based on my most frequent trips As a user I’d like to search from a drop down list of possible destinations As a user I’d like to see be able to use my computer’s microphone to say the destination Split by Input Type
- 36. Splitting Stories – another way to think about it Splitting Stories - Another way to think about it “What is the smallest thing that I can do in order to learn something (get some value)”
- 37. Exercise 4 – Splitting User Stories Exercise 3 – Splitting User Stories 1. Splitintopairs(ortriads) 2. Usingtheuserstoriesthatwerewrittenearlierpickauserstoriesthatcaneasilybe brokendownandwrite2ormoresmallerstoriestoreplacethebiggerstory. (Timebox=10minutes) “As a <user role> I want to <goal> so that <reason>”
- 38. Definition of Done & Acceptance Criteria
- 39. Example Definition of Done •Unit tests written and passed •Code has been peer reviewed •Acceptance tests passed •Test coverage >80% •Necessary logging or alarms implemented Don’t Forget the Definition of Done The Definition of Done (DoD) captures what the team needs to do to make each story releasable Image Credit – Geek-and-Poke.com
- 40. Example Acceptance Criteria •Error message displayed if I enter a number out with the range 0-100 •Number is rounded to two decimal points if I enter a number that contains more than 2 decimal points •Response time after pressing the enter button is less than 100ms Acceptance Criteria Acceptance Criteria are the User/Customer Conditions of Satisfaction
- 41. Exercise 4 – Adding Acceptance Criteria Exercise 4 – Add Acceptance Criteria 1. Splitintopairs(ortriads) 2. Usingtheuserstoriesthatwerewrittenearlierpickoneuserstoryandwrite acceptancecriteriaforthestory(conditionsofsatisfaction) (Timebox=5minutes)
- 43. Epics, Stories and Tasks EPICS STORIES TASKS
- 44. Example of Epics, Stories & Tasks EPIC – Refurbish the Kitchen STORY – New Oven STORY – Paint the kitchen Tasks: • Look at ovens online & in shops • Buy oven • Get installation quotes • Arrange for installation • …. Tasks: • Buy and try out different testers • Decide on a colour • Paint the undercoat • Paint the first coat of colour • … …
- 45. User Stories and the Agile Values User Stories and the Agile Values INDIVIDUALSAND INTERACTIONS over processes and tools Userstoriesencouragelotsof discussionbetweenusers/businesspeople/POsanddevelopers.The helpto shiftthe focusfrom WRITINGto TALKING. WORKING SOFTWARE over comprehensive documentation Smallstoriesencourageteams to releasevalueearlyand often, they don’t requireextensive/comprehensive documentation. CUSTOMER COLLABORATION over contract negotiation Userstoriesare created in collaborationwiththe customer(or PO) RESPONDING TO CHANGE over following a plan Userstoriesthat are plannedfor far intothe future are veryhighlevel,so respondingto changeiseasyand cheap.
- 47. Product Backlog Refinement (aka Grooming) PRODUCT BACKLOG Delete old user stories Insert new user stories 3 5 1 2 Estimate Stories Break stories down into smaller stories Reprioritise Stories • …. • …. • …. Add acceptance criteria
- 48. If you can do these 3 things If you can do these 3 things…. Ifdoingallofthisseemstoomuchfornow,startwiththese3things (1)Askyourself“Whatisthevalueofthis/whyamIdoingthis?” (2)Thinkaboutwhat“Done”reallymeansforeachpieceofwork (3)Whatistheminimumyoucandotogetvalue?Maximisetheamount ofworknotdone
- 49. References and Further Reading References and Further Reading Further Reading on User Stories • Agile Product Management with Scrum by Roman Pichler • User Stories Applied by Mike Cohn • User Story Mapping – Jeff Patton and Peter Economy • 50 Quick Ideas to Improve your User Stories – Gojko Adzic & David Evans Useful Websites/Blogs for Articles about User Stories • https://www.mountaingoatsoftware.com (Mike Cohn’s Site/Blog) • http://www.romanpichler.com/blog/ (Roman Pichler's Blog) • http://ronjeffries.com/categories/agile-related - Ron Jeffries’ Blog • https://gojko.net/posts.html - Gojko Adzic’s blog • http://agileforall.com/resources/how-to-split-a-user-story - story splitting poster
- 50. Workshop DOD
- 51. Any Questions? Thankyou for Listening! @SuzanneMorrison @LazAllen Any Questions?
Editor's Notes
- Learn Something New Have Fun Something you can take away and apply
- TIMING GUIDELINE – 2 MINUTES Explain the characteristics of the items in the top of the backlog versus the bottom. Don’t stress about the bottom of the backlog – the items here should be pretty big and don’t need to be as strictly prioritised The backlog should be visible to everyone, both in the team and outside the team, not sitting on someone’s hard drive
- TIMING GUIDELINE – 2 minutes ASK THE ROOM & Use a Whiteboard/Flipchart to add more Ask group if they’ve had any experience writing requirements AND/OR using requirements that have been written by someone else Ask if anyone can think of any common problems or challenges Not enough collaboration between business and technical people Not enough customer involvement Requirements are too ambiguous Too much technical jargon Requirements are not prioritised Missing requirements Value not understood Scope creep Say that the rest of the course will cover a number of different techniques that will help to overcome many of these changes
- TIMING GUIDELINE – 1 minute 30 User stories were introduced as part of Extreme programming in 1998 Various templates are available – choose the one that fits best for you. This template is a good start but you don’t need to be restricted by it. If a story doesn’t fit into the template it doesn’t make it bad. Conversely if a story fits into the template it doesn’t necessarily make it good. It captures the WHO, WHAT and the WHY. A few different templates, but this is one of the most common ones. One of the main benefits of user stories is that they allow you to see the reason why the requirement is important They can be seen as a “metaphor for a requirement” or a “promise for a conversation”
- TIMING GUIDELINE – 2 minutes CARD (stories were traditionally written on cards or postits, but may be in a tool such as JIRA) CONVERSATION (the details of story come out through conversations with the product owner CONFIRMATION (acceptance tests confirm that a story is coded correctly) This model was originally proposed by Ron Jeffries for XP (Extreme Programming) in 2001 The card doesn’t contain everything – it’s just a reminder with enough text to identify the requirement The conversation could be multiple conversations between different people happening at different times (e.g. PO, developers, testers, users, customers). Some conversations may happen during planning sessions, or during coding or testing. More info here - http://ronjeffries.com/xprog/articles/expcardconversationconfirmation
- TIMING GUIDELINE – 1 MINUTE Go through the Who, What and Why for the first example, then talk through the others These will be printouts stuck on the wall
- Sources: http://www.infoq.com/articles/story-cards-limit-agility http://blog.crisp.se/2014/09/25/david-evans/as-a-i-want-so-that-considered-harmful
- Sources: http://www.infoq.com/articles/story-cards-limit-agility http://blog.crisp.se/2014/09/25/david-evans/as-a-i-want-so-that-considered-harmful
- TIMING GUIDELINE – 1 minute 30 The user doesn’t have to be a real person. It could be for example another squad (someone in another squad needs something from you in order to implement a new feature) It could be the business (for example adding tracking to a product to allow people to understand what users are doing or be able to understand revenue figures).
- TIMING GUIDELINE – 1 minute Should include the PO, the team and possibly some external stakeholders Brainstorm style meeting to generate stories Goal of writing as many stories as possible (some may be implementation ready, others may be epics) No prioritisation Timeboxed There are a few different ways ways to structure this. One simple way is to start with the Epics, then break them down They can be done with a combination of silent writing of stories and discussion
- TIMING GUIDELINE – 20 MINUTES The following props will be needed: Index cards, or large postit notes Sharpies Bluetack A print out of the home improvements wish list Planning poker cards (for later exercise) 2 x flipchart paper with value map template drawn on it (for later exercise)
- TIMING GUIDE – 2 minutes 30 The first three are really important WHEN the story first gets written. The second two are more important when it gets taken into a sprint. Independent – Ideally it should be independent from other user stories and it can be released without dependencies (not possible in all cases) Negotiable – the details should be discussed between the team and the PO and are not set in stone up front Valuable – a user story should give value to the user (the user could be software e.g. another service). If it’s not going to add value it probably shouldn’t be a user storuy Estimable – if the team can’t estimate it yet, then it’s clear that they don’t understand it!] Small – The team should be able to complete a number of user stories in a single sprint (e.g. 5-10 stories). If it can’t fit into a sprint it needs to be broken down Useful article on Roman Picchler’s Blog: http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
- TIMING GUIDELINE – 3 MINUTES
- TIMING GUIDELINE – 2 MINUTES Talk through each of the common mistakes Useful article here on Roman Pilcher’s Blog: http://www.romanpichler.com/blog/5-common-user-story-mistakes/
- TIMING GUIDELINE – 1 MIN 30 Talk through each of the reasons/benefits for splitting user stories
- TIMING GUIDELINE – 1 MINUTE 30 secs As an example, if we had a system that accepted and processed different types of payments, we could split the work horizontally by doing the data layer, the middleware layer and the UI layer. Splitting this way wouldn’t allow us to add value to the user very quickly as we’d need to wait for all layers to completed. However, if we split it vertically e.g. by payment type we can release value to the user after each slice has been completed.
- TIMING GUIDELINE – 2 MINUTES Operations – does the story talk about “managing” or “configuring” (Split on CRUD – create, read, update, delete) Interface – does the story have a complex interface? Could you do a simpler version first? Input methods– does the story take the same type of data from multiple sources (e.g. CSV file, API, database etc)? Can you do one first, then the others? Business rules– does the story have multiple business rules (e.g. something like “flexible dates”)? Roles – what roles are involved in the story? Are all necessary now? Can the story be broken down according to role? Good blog post and cheat sheet - http://www.agileforall.com/splitting-user-stories/ Another useful blog post - http://blog.agilistic.nl/8-useful-strategies-for-splitting-large-user-stories-and-a-cheatsheet/
- TIMING GUIDELINE – 1 minutes
- TIMING GUIDELINE – 1 MINUTE
- TIMING GUIDELINE – 10 MINUTES
- TIMING GUIDELINE – 1 minute The definition of done is a generic list of things that need to be completed for each story in order for it to be done. Creating this removes any ambiguity on what “done” means If you don’t do this then you are in danger of ending up with a lot of stories in the “Almost done” state as illustrated in this cartoon
- TIMING GUIDELINE – 1 MINUTES 30 Walk through each of the points and explain Explain the difference between the DoD and acceoptance criteria
- TIMING GUIDELINE – 5 MINUTES
- TIMING GUIDELINE – 1 MINUTE Explain the difference between Epics, Stories and Tasks and that an epic usually has multiple stories and a story will have multiple tasks
- Mention that it used to be called “Backlog Grooming”, but was recently renamed due to the negative conotations of the word! You’ll see refinement and grooming used interchangeably in books, blogs etc.
- TIMING GUIDELINE – 2 MINUTES Product Backlog Refinement (Grooming) Estimate stories Add new stories Remove old stories Break down stories Reprioritise stories Having a backlog grooming meeting is important as it helps to keep the backlog healthy and up to date. If you don’t have these meetings you’ll typically find that your sprint planning meetings run for longer as you spend time in the planning doing the things that would be better done
- TIMING GUIDELINE = 2 MINUTES
- TIMING GUIDELINE = 1 MINUTE Walk briefly through the books. Mention that the “Succeeding with Agile” book is a good general book about agile and Scrum but has full chapters on planning, estimation and user stories The “User Stories Applied” book and the “Agile Planning and Estimation” are more in depth about these topics.
- Learn Something New Have Fun Something you can take away and apply