User Story Mapping

3,180 views
2,967 views

Published on

Rounding out your backlog.

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,180
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
129
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • Cards: Agree/ Disagree / Not SureOutcome: Explain what a user story is and isn’tThis is a user story: As a developer, I want to setup the continuous integration server so that we can deploy continuously.This is a user story: Create the service to validate a username and passwordThis is a user story: Forget Password link by emailThis is a user story: Create and Implement the Login pageEach user story should be totally independentOutcome: Describe some reasons to slice stories and list a few ways of doing so“As a user I want to see my profile information so that I can verify its accuracy”. A good example of slicing this story is:Create the profile database tablesCreate the profile service to read the profile dataCreate the profile page to call the service and display the dataUser stories can be sliced by objective qualityUser stories should not be sliced by validation rulesA screen or web page is often a good size for a user story slice.A large story doesn’t need to be slicedOutcome: Describe the benefits of a user story mapA backlog is a list of tasks needed to complete a project.When starting a project a backlog is a great model for seeing the big pictureA user story mapping session can speed up project discoveryA user story map is a better way to visualize priorities than a traditional backlogA traditional backlog isn’t a good vehicle for finding project gapsOutcome: Describe to someone else the difference between iterative and incrementalIt is possible to build an entire horizontal slice of the application in one or two iterationsUser Story Mapping and Iterative Development are strongly relatedIt isn’t possible for your users to see and test the whole application within one or two iterationsIt is difficult to control scope on agile projectsKnowing the final solution before you start is importantOutcome: Be able to create your own user story map
  • Step 1: Generate tasksSplit up into groups of 3 to 5As individuals, think about your morning routine – the things you do.Write down each thing you do on one post-it note. Have everyone in your group use the same colour post-it for this exercise.Step 2: Read them outHave each person read their post-its out loud to the group and then place them in the middle of the table so that you can see all the post-its at once.Comments: Notice the similarities between your post-its and other peoples. Notice also that if you missed a few things, somebody else came up with the missing tasks. You probably all have things like “Brush Teeth”, “Get Dressed”, “Eat breakfast”. All starting with verbs.Step 3: GroupNow as a group, and without talking, move the post-its that are similar to each other closer to each other, and those that are not similar, move them farther apart. Those that are exact duplicates you can eliminate or put on top of each other.Step 4: Name the groupsYou should now have some distinct groups. As a group again, start labeling these groups with a different colour post-it. Just put the group name on top of the grouping.Step 5: Now re-arrange your groups in order of time from left to right. Put the group post-it at the top and the tasks below the group, but still in order left to right.(At this point, show a simple example)Overall comments:Your first user story map!The groups are called “User Activities” – this is the backbone of your applicationThe items below are called “User Tasks” – this is the walking skeleton of your application
  • Also posted as a kanban board in the room – but large enough to put stickies under in the ending exercise.
  • Also posted as a kanban board in the room – but large enough to put stickies under in the ending exercise.
  • Boundary Object (scope). If used properly, you can use it to keep other scope out.Each story encompass all layers of the system. No value to the user without the layersHas value when completed
  • Talk – keep them as stories. Remember INVEST.
  • Highlighted my favourite ones…
  • User Activities are things that users do towards achieving a particular goal.User Tasks are specific steps within an activity. Tasks by themselves do not move towards a goal, but are required components of an activity.User Stories are small end-to-end vertical slices of functionality that implement User Tasks.
  • Time across (link back to breakfast)Priorities down (no more H/M/L, or must have, etc…Releases
  • An alternative to a backlogAllows you to see the big picture in your backlogBetter than a ‘flat’ backlog
  • Allows you to “Walk the map”A nice way to make sure you haven’t missed anythingBring in different users to walk through their scenarios.
  • Visualize building the important things firstbuilding a complete system firstIt isn’t about the precision of the model, but about a common understanding of the model
  • We created this in less than 30 minutes. Another 30 minutes it would have been estimated and we’re ready to go.Some in the lean community question whether backlogs (because it is inventory) is waste. When you use a user story map, your backlog now becomes the story of your project – something you look to understand the model as a whole. Plus, since you can create one so fast with this technique, it is hard to argue that it is wasteful.
  • We’re going to create a second map with some more detail and more relevance to software. You can move your old map out of the way.Practice – build your own MS Outlook competitor.Step 1: Generate tasksSplit up into groups of 3 to 5As individuals, think about your usage of your favourite e-mail toolWrite down each thing you do on one post-it note. Have everyone in your group use the same colour post-it for this exercise.Step 2: Read them outHave each person read their post-its out loud to the group and then place them in the middle of the table so that you can see all the post-its at once.Comments: Notice the similarities between your post-its and other peoples. Notice also that if you missed a few things, somebody else came up with the missing tasks. You probably all have things like “Send Email”, “Read Email”, “View Calendar”, “Create Contact”, etc.Again, all starting with verbs.Step 3: GroupNow as a group, and without talking, move the post-its that are similar to each other closer to each other, and those that are not similar, move them farther apart. Those that are exact duplicates you can eliminate or put on top of each other.Step 4: Name the groupsYou should now have some distinct groups. As a group again, start labeling these groups with a different colour post-it. Just put the group name on top of the grouping.Step 5: Now re-arrange your groups in order of time from left to right. Put the group post-it at the top and the tasks below the group, but still in order left to right.Overall comments:Your second user story map!Reminder:The groups are called “User Activities” – this is the backbone of your applicationThe items below are called “User Tasks” – this is the walking skeleton of your applicationNotice how fast you were able to create a reasonable outline for your whole application?Keep this map as we will be adding to it shortly. At this point we have no user stories.
  • In your user story map you should probably have a “Compose Email” or “Create Email” user task under the “Email Management” user activity or something similar. (if not, then what kind of e-mail have you been using?)We’re going to create the stories that go under that User Activity.Step 1: Generate tasksSplit up into groups of 3 to 5As individuals, think about creating an e-mail and write one user story (just the title, don’t worry about the rest) on each post-it. Slice each story thinly.Again, have everyone in your group use the same colour post-it for this exercise but use a different colour than the ones you have used so far.Step 2: Read them outHave each person read their post-its out loud to the group and then place them in the middle of the table so that you can see all the post-its at once.Again:Notice the similarities between your post-its and other peoples. Notice also that if you missed a few things, somebody else came up with the missing tasks. Step 3: GroupNow as a group, and without talking, move the post-its that are similar to each other closer to each other, and those that are not similar, move them farther apart. Those that are exact duplicates you can eliminate or put on top of each other.Step 4: PrioritizeInstead of naming our groups, this time we are just going to prioritize them top to bottom. The ones at the top will be created first and the others second.Think about the order that each piece would have to be built (again, reminder of the I in INVEST)If you are disagreeing about any story, feel free to split it again if you can.You can do this out loud.Overall comments:Again, notice how fast you were able to create a reasonable outline for your whole application? Has requirements gathering ever been this fast for you?You would repeat this for each activity and there are other requirements facilitation techniques to use like personas, scenarios, UX Design Studio, etc. These models are all inclusive models. They involve everyone and take advantage of all ideas without resorting to the trouble that is brainstorming or even writing down the correct interview questions in order to generate your high level scope and requirements.Do this with your customer!!!
  • Notice how if we turn this upside down it looks suspiciously like a user story map?
  • Allows you to validate your architecture and solution early Allows users to see and test the whole application early Minimizes the affects of change to a feature Ensures important stories are built first Elicits improved feedback on the whole application early Allows you to deliver your application early Discourages "gold plating" It partners nicely with user story mapping (turn the diagram upside down and you have your story map)
  • Allows you to validate your architecture and solution early Allows users to see and test the whole application early Minimizes the affects of change to a feature Ensures important stories are built first Elicits improved feedback on the whole application early Allows you to deliver your application early Discourages "gold plating" It partners nicely with user story mapping (turn the diagram upside down and you have your story map)
  • As a group, choose 2 of the outcomesStep 1: Generate learnings.As individuals, write down 3 things you learned for each of the learning outcomes. One on each post-itStep 2: Read them outHave each person read their post-its out loud to the group and then place them in the middle of the table so that you can see all the post-its at once.Step 3: GroupNow as a group, and without talking, move the post-its that are similar to each other closer to each other, and those that are not similar, move them farther apart. Those that are exact duplicates you can eliminate or put on top of each other.Step 4: Name the groupsYou should now have some distinct groups. As a group again, start labeling these groups with a different colour post-it. Just put the group name on top of the grouping.Step 5: Put them up.Have one person in your group read the ‘group’ post-its and post them on the board with the individual post-its underneath.Your 3rd user story map!
  • User Story Mapping

    1. 1. (Track Sponsor)<br />User Story Mapping – Rounding out your Backlog<br />Steve Rogalsky<br />@srogalsky<br />winnipegagilist.blogspot.com<br />
    2. 2. Agree / Disagree / Not Sure<br />Credit: Monty Python Argument Clinic<br />
    3. 3. Outcome: Demonstrate the ability to create a User Story Map<br />
    4. 4. About Me<br />Agilist and team member at Protegra in Winnipeg <br />(It says “Application Architect” on my business card)<br />Founder of Winnipeg Agile User Group<br />@srogalsky<br />http://winnipegagilist.blogspot.com<br />
    5. 5. Learning Outcomes<br />Demonstrate the ability to create a User Story Map<br />(You’ll create three)<br />Explain what a user story is (and isn’t)<br />Demonstrate the ability to slice user stories in your map<br />Describe the benefits of User Story Mapping<br />Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    6. 6. Outcome: Explain what a user story is (and isn’t) <br />
    7. 7. What User Stories are not<br />Tasks<br />Create user table<br />Create password encryption service<br />Create login service<br />Create CSS <br />Create page template<br />Add login button<br />Outcome: Explain what a user story is (and isn’t) <br />
    8. 8. What User Stories are not<br />Big*<br />Login page<br />“the web site”<br />160 hours of effort<br />* Exception – stories that are in the distance can be big. These stories will shrink in size and grow in detail as they get closer to being implemented.<br />Outcome: Explain what a user story is (and isn’t) <br />
    9. 9. What User Stories are not<br />Use cases<br />Login Use Case<br />Happy path:<br />Login w/ valid pwd<br />Alternate Paths:<br />Login w/ invalid pwd<br />Forgot password<br />Reset password<br />Password rules<br />A use case will often contain many user stories<br />Outcome: Explain what a user story is (and isn’t) <br />
    10. 10. What User Stories are not<br />A document<br />Login.docx<br />“this document, by its very size, ensures that it will never be read.” – Sir Winston Churchill<br />Outcome: Explain what a user story is (and isn’t) <br />
    11. 11. What User Stories are…<br />A small piece of functionality that provides some value to a user<br />As a user, I want to login with my password, so that I can gain access to the site.<br />“A place holder for a conversation.”<br />Outcome: Explain what a user story is (and isn’t) <br />
    12. 12. What User Stories are…<br />I Independent *<br />N Negotiable (can be prioritized)<br />V Valuable (to a user)<br />E Estimable<br />S Small<br />T Testable<br />Outcome: Explain what a user story is (and isn’t) <br />
    13. 13. Formats<br />By the book:<br />As a [role], <br />I want to <br />[some action], so that <br />[goal]<br />As a [user] <br />I want to <br />[login with my pwd] <br />so that <br />[I can gain access to the site]<br />Outcome: Explain what a user story is (and isn’t) <br />
    14. 14. Formats<br />Who<br />What<br />Why<br />As a <br />[user] <br />I want to <br />[login with my pwd] <br />so that <br />[I can gain access to the site]<br />The “by the book” format is great for learning, but at its core, it is just Who/What/Why<br />Outcome: Explain what a user story is (and isn’t) <br />
    15. 15. Formats<br />Title; Sentence; Acceptance Tests<br />Title: Login w/ pwd<br />Login w/ password and show welcome page<br />Test upper, lower, numbers, special characters, accents, spaces<br />Test mandatory lengths<br />Test invalid pwds<br />Outcome: Explain what a user story is (and isn’t) <br />
    16. 16. Formats<br />Lean Startup:<br />Feature <br />[X]<br />will move Metric <br />[Y]<br />Feature <br />[show sad face before logging off] <br />will move Metric <br />[time spent logged into the site]<br />Outcome: Explain what a user story is (and isn’t) <br />
    17. 17. Outcome: Explain what a user story is (and isn’t) <br />
    18. 18. Take the Bluecards and re-sort them<br />Outcome: Explain what a user story is (and isn’t) <br />
    19. 19. Outcome: Demonstrate the ability to slice user stories in your map<br />
    20. 20. Why slice?<br />User Story Slices go here:<br />Outcome: Demonstrate the ability to slice user stories in your map<br />
    21. 21. How not to Slice?<br />Outcome: Demonstrate the ability to slice user stories in your map<br />Tasks<br />Create user table<br />Create password encryption service<br />Create login service<br />Create CSS <br />Create page template<br />Add login button<br />
    22. 22. How to Slice?<br />By screen (for basic screens only) <br />By button <br />By group of fields <br />By workflow step <br />Optional workflow steps <br />Validation <br />Error handling *<br />Admin functions (maintaining drop downs, etc) <br />By priority <br />By applying the INVEST model <br />By acceptance criteria <br />By option <br />By role <br />By Subjective quality (never by objective quality: always be defect free) <br />By value<br />Outcome: Demonstrate the ability to slice user stories in your map<br />
    23. 23. Other Tips<br />Keep them as stories!<br />Slice them small when needed, but don’t get silly<br />Slice any time<br />When you are fighting over your planning poker estimates – slice away.<br />Slice more liberally if the story is higher priority<br />Outcome: Demonstrate the ability to slice user stories in your map<br />
    24. 24. Outcome: Demonstrate the ability to slice user stories in your map<br />Take the Purplecards and re-sort them<br />
    25. 25. Outcome: Demonstrate the ability to create a User Story Map<br />User Activities<br />User Tasks<br />User Stories<br />
    26. 26. Outcome: Demonstrate the ability to create a User Story Map<br />Time<br />Priorities<br />Releases<br />
    27. 27. Outcome: Demonstrate the ability to create a User Story Map<br />
    28. 28. Outcome: Describe the benefits of User Story Mapping<br />
    29. 29. Outcome: Describe the benefits of User Story Mapping<br />
    30. 30. Outcome: Describe the benefits of User Story Mapping<br />
    31. 31. Outcome: Describe the benefits of User Story Mapping<br />
    32. 32. How to do it?<br />1. Divide into groups of 3-5 people<br />2. Start by gathering “things people do” – the tasks. Write them down individually and then read them aloud to your group<br /><ul><li>Likely they start with a verb.
    33. 33. These are high level user stories called “Tasks” (walking skeleton)
    34. 34. This forms your story map skeleton</li></ul>3. Group them silently (simply because it is faster)<br />4. Name the groups and lay them out in order of time (left to right)<br /><ul><li>These are called “User Activities” (backbone)</li></ul>5. Add more detailed user stories below the main tasks<br />6. Prioritize top to bottom<br />7. Break into releases<br />Outcome: Demonstrate the ability to create a User Story Map<br />
    35. 35. Outcome: Demonstrate the ability to create a User Story Map<br />
    36. 36. Outcome: Demonstrate the ability to slice user stories in your map<br />
    37. 37. Outcome: Describe the benefits of User Story Mapping<br />Take the Greencards and re-sort them<br />
    38. 38. Iterative<br />1<br />2<br />3<br />4<br />5<br />Incremental<br />Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />Credit: Jeff Patton<br />
    39. 39. Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    40. 40. Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    41. 41. Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    42. 42. Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    43. 43. Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    44. 44. Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    45. 45. Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    46. 46. Iterative vs. Incremental<br />Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    47. 47. Iterative Advantages<br />Validate your architecture and solution early <br />See and test the whole application early <br />Encourages important stories to be built first <br />Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    48. 48. Iterative Advantages<br />Elicits improved feedback on the whole application early <br />Deliver your application early as early as possible<br />Discourages "gold plating" <br />Helps contain scope<br />Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    49. 49. Iterative Disadvantages<br />Your code and design has to be change tolerant <br />You have to be proficient at slicing your user stories <br />You won't know the final solution at the beginning of the project <br />Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    50. 50. Outcome: Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />Take the Pinkcards and re-sort them<br />
    51. 51. Our Final Map<br />As a table, choose 2 of the outcomes<br />Outcome: Demonstrate the ability to create a User Story Map<br />Demonstrate the ability to create a User Story Map<br />Explain what a user story is (and isn’t)<br />Demonstrate the ability to slice user stories in your map<br />Describe the benefits of User Story Mapping<br />Explain the difference between iterative and incremental and how that relates to User Story Mapping<br />
    52. 52. Questions?<br />THANKS!<br />Contact Info<br />steve.rogalsky@protegra.com<br /> @srogalsky<br />winnipegagilist.blogspot.com<br />http://www.slideshare.net/SteveRogalsky/?????/<br />

    ×