Story Mapping Recover from Flat Backlogs with User Story Mapping Tracy Whitehill Agile Team Coach Story Mapping Welcome to Keep Austin Agile 2014! I’m Tracy Whitehill, an Agile Team Coach with Agile Velocity. We’re going to spend our time together this morning talking about a multi-dimensional approach to eliciting requirements and building backlogs. We’re also going to have a little Agile Velocity Bingo going on. Take a minute to familiarize yourself with your Bingo card and then when I’m talking you can mark off any of the terms that you hear me say. First person to get 5 in a row – horizontally, vertically, diagonally – shout out Agile Velocity Bingo! Kim will come check it out and if it’s a true Bingo, you’ll win these lovely prizes – an Agile Survival Kit, complete with No button, and 3 entries into our AV drawing for UT football tickets. So let’s go!

How good are we at predicting what customers need? Take a moment to consider this question. Now introduce yourself to the person seated next to you and rate your experience at predicting what your customers need on a scale of 1 to 10 – 1 being the worst, 10 being awesome – giving them a little context for your rating. Ok, with show of hands – what are your ratings? Some of you are better at this than the rest of us!

How good are we at predicting what customers need? Feature/function usage in the software industry always often sometimes never rarely From: A Standish Group 2002 study So these statistics are from a study the Standish Group did and they found that 64% of features that are built into software are rarely or never used. Anything come to mind? Of course there are some features that are rarely used that are still important – think about a financial website like ADP - the ability to print or access a W-2 is probably used by most people, but it’s only used once a year. Anyone remember Clippy from Microsoft Word? This means that we’re only building features that our customers use 36% of the time. That’s probably about a 3 on the scale of 1 to 10! So how to we improve this?

We want to Shift the Process from a Requirements Delivery Process… False Assumptions: The customer knows what he wants The developers know how to build it Nothing will change along the way Traditional waterfall development has us doing the analysis up front. We spend weeks or even months writing up lengthy requirements documents to hand over to the developers so they can build the product for our customer. This approach makes some faulty assumptions – it assumes the customer knows what they want from the initial stages, that the developers will know exactly how to build it and that nothing in our plan or requirements document will change along the way. You’re experienced software folks… how often does it really work out this way? So we want to shift from delivering requirements to….

…To a Requirements Discovery Process Reality: The customer discovers what he wants The developers discover how to build it Many things change along the way Discovering requirements. The reality of product development is that the customer has a high level idea of what they want in the product, but they discover more about what they really want as it’s being developed. And we’re building software, not the same widget over and over, so the developers may need to figure out how to build things. Maybe they’re using new technology or maybe they’re building something completely unlike anything they’ve built before. So naturally, a lot of things change along the way. This is where agile requirements in the form of user stories are more flexible – rather than having a large requirements document that is written up front, we write stories to address features the customer wants as we’re learning more about the product.

Challenges with One dimensional backlogs Do you understand the workflow? Are you able to see the relationship of larger stories to child stories? How do you validate that your backlog is complete? What context do you use for prioritization? So this is great, these flexible, just-in-time requirements in the form of user stories. The problem though is that user stories typically live in a one dimensional backlog, maybe in a tool like Jira or Rally or even in an Excel spreadsheet where it’s really difficult to see the workflow and how the stories relate to each other. Looking at a list of stories, it can even be hard to know if you’ve got all the stories you need to build your product. So there’s got to be a better way…

User tasks are decomposed into smaller tasks and organized into activities Introducing the user story map. It’s multi-dimensional - easily displaying the workflow and relationships between stories. The main workflow is across the top and as each piece of that workflow is broken down into smaller stories, they’re grouped below the parent piece.

User Story Maps help us plan releases in complete and valuable slices Here’s another example. In this one, you can see which features/stories were critical enough to be included in the first release (those above the red line) and which ones could wait until a later release (those above the green line).

Anatomy of a User Story Map backbone Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Workflow sequence walking skeleton Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) High First Release Action (story) Action (story) Action (story) Action (story) Priority Next Release Action (story) Action (story) Low Action (story) When you’re building a story map, you’ll start by thinking of one persona that may use your product and brainstorming the Actions (or Stories) that create the main workflow sequence. Actions have an objective that can be completed. Actions often cluster together into Activities of related tasks. Examples of actions could be “Read an email message” and “Delete an email message”; these could be grouped together under the activity of “Managing email”. You can walk through your map with other personas and add additional actions or maybe as you walk the map with your customers, they will identify additional actions/stories that are needed. These actions are placed on the map in priority order – those that are higher priority are close to the top; lower priority lower on the map. Once you’ve fleshed out the story map, you can work with your customer to determine which stories are most critical to get into the first release. Subsequent releases can then be identified. The highest priority stories form what’s called the “walking skeleton”. The activities are the essential capabilities the product needs to have and these form the “backbone”.

Minimal Viable Product - MVP MVP is “the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” – Eric Ries, The Lean Startup So we’re going to build a user story map. But first – let’s talk a little about the first release or MVP. Zappos founder Nick Swinmurn started by posting photos of shoes from a local shoe store and buying from the store when customers bought online. The purpose was to validate the hypothesis that customers were willing to buy shoes online. Food on the Table (based in Austin) is a meal planning service. They used a concept Eric Ries calls the “Concierge MVP”. Instead of building a website, they found one customer who wanted a meal planning service, and visited her in her home to ask what meals and groceries she wanted, after researching what was on sale at the local supermarket. They then prepared recipes and a shopping list, and hand delivered it to their single customer.

Validated Learning: the Build-Measure-Learn cycle 1) What do we need to learn? Learn Build 3) What is the simplest thing to build to measure it? (MVP) Minimize time thru the loop 2) How can we measure it? Measure These are both examples of the Build-Measure-Learn cycle. Eric Ries: The Lean Startup

Lean Canvas 1. Problem 4. Solution 3. Unique value proposition Lean Canvas: Ash Maurya 1. Problem top 3 problems Existing alternatives 4. Solution top 3 features 3. Unique value proposition Clear compelling message. Why makes you different? 9. Unfair advantage Not easily copied or bought 2. Customer segments Target customers Early adopters? 8. Key metrics e.g. AARRR 5. Channels Path to customers 7. Cost Structure Customer acquisition, distribution, people, etc. 6. Revenue streams Revenue model, life time value, revenue, gross margin Product Market The Lean Canvas is a 1-page business model. Size of box represents relative amount of content that should be included. Numbers indicate the suggested order for filling in the canvas. Product-centric attributes are on the left side, Market-centric attributes are on the right side. We’re not here to go in depth on the Lean Canvas – that could be its own session – but we’re going to use a partially filled out canvas to give us a topic for practicing our user story mapping. AARRR: Dave McClure “pirate metrics”: acquisition, activation, retention, revenue, referral Process: 1) do lean canvas (2) identify risks (3) systematically test Lean Canvas, from Ash Maurya: Running Lean. Licensed under Creative Commons-Attribution-Share Alike 3.0 *AARRR metrics: acquisition, activation, revenue, retention, referral (Dave McClure)

Partial Lean Canvas: Home Automation 1. Problem Inefficient energy usage Age & disability create difficulty ? Existing alternatives Hire help Perform manually 4. Solution Voice command lights, appliances Scheduled tasks Motion detection ? 3. Unique value proposition Integrated control of ALL home systems Free installation ? 9. Unfair advantage Patents ? 2. Customer segments Elderly/disabled Eco-conscious ? Early adopters? 5. Channels Infomercials Social media ? 8. Key metrics # requests 4 info # subscriptions ? 7. Cost Structure Marketing, product design, ? 6. Revenue streams Hardware sales, subscription, ? Product Market Product idea: home automation or smart home: manage electrical, plumbing, windows, appliances; automate tasks remotely. So we’re going to take a little time to get familiar with our problem space for the story mapping. Since working in groups requires talking, if I need to get your attention for anything, I’ll raise my hand. When you see this happen, stop talking and raise your hand along with me. This will be how we bring the groups back together. Activity: In small groups, add to & modify this partial lean canvas. Focus on items 1, 2, 3, and 4 (problem, customer segments, unique value prop and solution) if time is limited. Handouts: (1) the Lean Canvas slide, (2) partial lean canvas for home automation, (3) partial lean canvas on 11x17. Alternative: participants draw a lean canvas on a flip chart Other supplies to bring: stickies (multiple colors), sharpies, pens or pencils Presenter: visit each group, give hints if needed to move them along. Lean Canvas, from Ash Maurya: Running Lean. Licensed under Creative Commons-Attribution-Share Alike 3.0

Story Map Activity Part 1 Choose a Customer Segment from your Lean Canvas One person plays the Customer role Ask what the customer wants, capture each idea on a post-it Workflow sequence Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) So we’re going to practice building a user story map. I’ll walk you through our process so you know what’s coming and then will give you time to work as a group. You’ll need to break into groups of 4-6 to work together. Since working in groups requires talking, if I need to get your attention for anything, I’ll raise my hand. When you see this happen, stop talking and raise your hand along with me. This will be how we bring the groups back together.

Story Map Activity Part 2 (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Workflow sequence Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) High Action (story) Action (story) Action (story) Action (story) Priority Action (story) Action (story) Low Arrange in order of workflow Group items into common activities or categories Arrange top to bottom by priority Then in the second part, your group will put all the post-its in order from beginning to end. There may be duplicates so you can eliminate those. Group related tasks. And place them on the map with highest priority actions at the top and lower priority ones towards the bottom.

Story Map Activity Part 3 (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Workflow sequence Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) High MVP Action (story) Action (story) Action (story) Action (story) Priority Next Release Action (story) Action (story) Low Draw the line for your MVP Draw the line for subsequent Releases Once you’ve got your story map, test it out with different personas – – to fill in missing stories. Then determine which are the absolute critical tasks to accomplish. This will be your MVP I’ll go back to the instructions for the first part and give you some time to do the work. To keep us on track timewise, I’ll switch the instructions to the 2nd and 3rd parts as you should be moving along.

Step 1 At your tables: Choose a Customer Segment from your Lean Canvas Someone plays the part of this Customer and describes what they would do with the product The rest of the group writes these tasks down on post-its

Merge these post-its into a single model: Step 2 Merge these post-its into a single model: Arrange them left to right in an order that makes sense to the group Eliminate duplicates Cluster items that seem similar and create labels for the clusters if items seem to go together

Create the MVP and subsequent releases: Step 3 Create the MVP and subsequent releases: Walk the map to determine necessary tasks Draw a line below those tasks – this is your MVP Discuss with stakeholders to determine subsequent logical releases

Reading the activities across the top of the system helps us understand end-to-end use of the system. Reading the activities across the top of the system helps us understand end-to-end use of the product. Remember these are the essential capabilities the product needs to have. This is a good Cliff notes version for your stakeholders!

User Story Mapping is Collaborative & Fosters Co-Ownership Story Mapping is best done when it involves the team and the stakeholders so that we can be sure we’re building a product with features they need and will use. It’s a great way to do the requirements discovery we talked about back at the beginning.

User Story Maps help us see things from a user’s perspective Colors for different user personas The story map helps us to consider different user personas. In this map, the various personas were represented by different colors.

With User Story Mapping you can test for Gaps by Walking the Map And the story map allows us to have a more complete backlog as we test it out by talking through it with a variety of people – the delivery team, stakeholders, etc.

Anatomy of a User Story Map Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Activity (Theme/epic) Workflow sequence Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) Action (story) High MVP Action (story) Action (story) Action (story) Action (story) Priority Next Release Action (story) Action (story) Low Action (story) When you’re building a story map, you’ll start by thinking of one persona that may use your product and brainstorming the Actions (or Stories) that create the main workflow sequence. Actions have an objective that can be completed. Actions often cluster together into Activities of related tasks. Examples of actions could be “Read an email message” and “Delete an email message”; these could be grouped together under the activity of “Managing email”. You can walk through your map with other personas and add additional actions or maybe as you walk the map with your customers, they will identify additional actions/stories that are needed. These actions are placed on the map in priority order – those that are higher priority are close to the top; lower priority lower on the map. Once you’ve fleshed out the story map, you can work with your customer to determine which stories are most critical to get into the first release. Subsequent releases can then be identified. The highest priority stories form what’s called the “walking skeleton”. The activities are the essential capabilities the product needs to have and these form the “backbone”.