1. 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!

2. 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!

3. 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?

4. 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….

5. …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.

6. 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…

7. 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.

8. 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).

9. 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 message” and “Delete an message”; these could be grouped together under the activity of “Managing ”.
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”.

10. 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.

11. 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

12. 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)

13. 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

14. 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.

15. 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.

16. 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.

17. 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

18. 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

19. 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

20. 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!

21. 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.

22. 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.

23. 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.

24. 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 message” and “Delete an message”; these could be grouped together under the activity of “Managing ”.
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”.