User Story Mapping - mini iad 2014 (Armani, Rodriguez)
17 likes•2,458 views
The document discusses the importance of visualizing and managing the product backlog through techniques like silent brainstorming and dimensional planning to enhance decision-making and collaboration. It outlines a structured approach for creating user story maps and prioritizing user stories, emphasizing iterative development. Additionally, it highlights the need to accommodate complexity and change in requirements throughout the project lifecycle.
User Story Mapping - mini iad 2014 (Armani, Rodriguez)
- 1. Armani -‐ Rodriguez May 17 2014
- 2. Fabio Armani [email protected], @fabioarmani Andrea Torino Rodriguez [email protected], @agilerod
- 3. Why • It allows you to see the big picture in your backlog. • It gives you a be8er tool for making decisions about grooming and priori<zing your backlog. • It promotes silent brainstorming and a collabora<ve approach to genera<ng your user stories.
- 4. Why • It encourages an itera<ve development approach where your early deliveries validate your architecture and solu<on. • It is a great visual alterna<ve to tradi<onal project plans. • It is a useful model for discussing and managing scope. • Allows you to visualize dimensional planning and real op<ons for your project/product.
- 7. Silent Brainstorming • Decide on the type of ques<on • Step 1: generate ideas individually. One idea per post-‐it • Step 2: read and put ideas on the table • Step 3: group the ideas (clustering) • Step 4: Name each group • Step 5: prepare for vo<ng • Step 6: each person votes for their top 3 • Step 7: facilitator tallies the votes • Step 8: act on the item(s) with the highest vote!
- 9. Dimensional Planning • In Scrum the Product Backlog is an ordered list of features. Unfortunately the linearity of the ordered list is not consistent with the way us humans think about problems. • Problems even in the business space are mul<-‐ dimensional. So, we probably also should think of solving our problems in mul<ple dimensions. This is where Dimensional Planning comes in handy when spliXng Product Backlog Items in your Product Backlog during the Refinement or Grooming mee<ngs.
- 10. Dimensional Planning • In Scrum the Product Backlog is an ordered list of features. Unfortunately the linearity of the ordered list is not consistent with the way us humans think about problems. • Problems even in the business space are mul<-‐ dimensional. So, we probably also should think of solving our problems in mul<ple dimensions. • This is where Dimensional Planning comes in handy when spliXng Product Backlog Items in your Product Backlog during the Refinement or Grooming mee<ngs.
- 13. Dimensional Planning From dirt road to flying cars • Dirt road • Cobblestone road • Asphalted road • Highway • Flying cars
- 16. Real Op<ons • How and when (not) to make decisions • Defer commitments
- 17. Problem Customer Supplier Implement Generate op<ons Test and choose op<ons
- 18. Don’t try to decide too fast!
- 20. Real Op<ons • Have a value • Have a cost (= the price of the op<on) • Have a price (“strike price”) when we exercise the op<on • Have an expira<on date/condi<on ~ “Call Op<on” An op<on is not an obliga<on
- 21. Grooming
- 23. Living Charter = Chartering
- 24. How to create a User Story Map
- 27. Backbone
- 28. Walking Skeleton
- 30. Some defini<on • The post-‐its you create in Step 2 are the User Tasks (blue post-‐its in the diagram). • The groups and group names in steps 3 and 4 are the User Ac3vi3es (orange post-‐its). Jeff calls these top two rows the backbone and walking skeleton of your applica<on. • The user stories (yellow post-‐its) are organized under each User Task in order of highest to lowest priority for that User Task. • The chronological order of how users will typically use the applica<on goes lej to right (Time).
- 31. How to priori<ze a User Story Map
- 33. Story … Story 1 Story 2 Story 3 Sprint N-‐1 Sprint N Sprint N+1 Story 3
- 34. Story Slicing Story 1 Story 2 Story 3 Story 4 Story 5 Story 6 Story 7 Story 8 Story 9 Sprint N-‐1 Sprint N Sprint N+1 Wri<ng story tests Automa<ng story tests Implemen<ng the user story
- 35. Risk & Assump<ons • Where are the risky stories? • Where are our biggest assump<ons?
- 37. Applying Cynefin • A way to understand complexity is that ac<ng in the space causes the space to change, and cause and effect can only be understood in retrospect.
- 38. Applying Cynefin "When you start wri<ng tests, or having discussions, and the requirements begin changing underneath you because of what you discover as a result, that’s complex. You can look back at what you end up with and understand that it’s much be8er, but you can’t come up with it to start with, nor can you define what “be8er” will look like and try to reach it. It emerges as you work." "... This is the land of high-‐feedback, risk and innova<on: generally stuff you’ve never done before, anything that the business are unsure about, new technologies, etc."
- 40. How to do it? 1. Divide into groups of 3-‐5 people 2. Start by gathering “things people do” – the tasks. Write them down individually and then read them aloud to your group – Likely they start with a verb. – These are high level user stories called “Tasks” (walking skeleton) – This forms your story map skeleton 3. Group them silently (simply because it is faster) 4. Name the groups and lay them out in order of <me (lej to right) – These are called “User Ac3vi3es” (backbone)
- 41. How to do it? 5. Add more detailed user stories below the main tasks 6. Priori<ze top to bo8om 7. Break into releases 8. Assign values
- 42. Itera<ve 1 2 3 4 5 Credit: Jeff Pa8on Incremental
- 45. thanks
- 46. Fabio Armani www.open-‐ware.org f.armani@open-‐ware.org, @fabioarmani Andrea Torino Rodriguez [email protected], @agilerod