Patton User Story Mapping

Building Better Products Using
User Story Mapping
Jeff Patton
jpatton@acm.org www.agileproductdesign.com
Jeff Patton, all rights reserved, www.AgileProductDesign.com
Our goals and agenda today

Goal: Learn to use the user story backlog as a way to describe users experience with your product Part 1: Mapping user stories
User story essentials Telling stories about the user experience Mapping user stories based on experience
Part 2: Planning valuable incremental releases

Identifying product goals that delivery value Slicing the story map into valuable releases
Part 3: Iteratively constructing software (time permitting)

Identifying an iterative and incremental construction strategy Splitting and thinning stories for upcoming development iterations
Jeff Patton, all rights reserved, www.AgileProductDesign.com 2
Starting with the User Story

What do you know about user stories? What do you like about user stories? What causes you trouble with user stories
User Stories are multi-purpose
QuickTime an d a Cinepak decompressor are need ed to see this p icture .
NBC Studios
User Stories are multi-purpose

Stories are a:
Users need Product description Planning item Token for a conversation Mechanism for deferring conversation
* Kent Beck coined the term user stories in Extreme Programming Explained 1st Edition, 1999
Stories gain detail over time

Start with a title Add a concise description often using this useful template:
As a [type of user] I want to [perform some task] so that I can [reach some goal]
Add other relevant notes, specifications, or sketches

Before building software write acceptance criteria (how do we know when were done?)
Agile customers or product owner prioritize stories into a backlog

A collection of stories for a software product is referred to as the product backlog The backlog is prioritized such that the most valuable items are highest
Lets talk about the nature of multi-purpose things

(yes Im going meta. I blame Brian.)
User Stories are boundary objects

A boundary object is a concept in sociology to describe information used in different ways by different communities. They are plastic, interpreted differently across communities but with enough immutable content to maintain integrity -Wikipedia They are weakly structured in common use, and become strongly structured in individual-site use. They may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable means of translation. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds. -- Leigh & Griesemer
User Stories act as the boundary to facilitate conversation between many How do I people understand How do I
describe to you what I want? users and their needs? What are the things my product needs to be successful? What are the details of this feature I need describe?
user
UX person BA
business leader
How do I schedule this work and track it its progress? How do I validate this work is done?
PM tester
developer
What are the details of what I need to work on today?
10
But size always matters...

How big is the story we want to talk about?
11
And, its easy to get lost in the sheer number of them
12
And, as we start moving forward, how do we stay on track?
13
User Story Mapping is an an approach to Organizing and Prioritizing user stories

Unlike typical user story backlogs, Story Maps:
make visible the workflow or value chain show the relationships of larger stories to their child stories help confirm the completeness of your backlog provide a useful context for prioritization Plan releases in complete and valuable slices of
User Story Mapping is an an approach to Organizing and Prioritizing user stories
Story Maps support the primary intent of user stories, rich discussion
15
The foundational building block of a story map is the user task

First lets do a warm-up exercise to understand a few concepts
What were all the things you did to get ready to be here today?
Starting from the moment you woke up until you arrived here Write one item per sticky note
First lets do a warm-up exercise to understand a few concepts
In a small group (3 to 5 people) merge these stickies 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 that seem to go together
Whats common about the items each of you wrote down? What was different? How did the models created by different groups vary?
People achieve goals through interaction

problem or goal
How Id like to feel, or what Id like to achieve
goal evaluation action

Take some
Is my goal met or problem resolved?
action evaluation
Did that action deliver the results I expected?
Information and tools

the world
Think of three levels: goal, task, and tool

problem or goal
How Id like to feel, or what Id like to achieve
goal task
goal evaluation
Is my goal met or problem resolved?
action
Take some
action evaluation the world
Information and tools

tool
Did that action deliver the results I expected?
Think of three levels: goal, task, and tool
goal task
tool
Software contains features that support a variety of tasks and a variety of goals
goals tasks
software
features tools
Goals, tasks, and tools apply at both a personal and organizational level
goals tasks
tools
business objectives
business processes
employees, vendors, & systems

25
User tasks are decompose to smaller tasks and organize into activities
Tasks require intentional action on behalf of a tools user Tasks have an objective that can be completed Tasks decompose into smaller tasks Tasks often cluster together into activities of related tasks
task
activity
task task task
task
26
User tasks are decompose to smaller tasks and organize into activities
Tasks require intentional action on behalf of a tools user Tasks have an objective that can be completed Tasks decompose into smaller tasks Tasks often cluster together into activities of related tasks Read an email message is a task, Managing email is read manage email activity an activity. task message
create task folder send task message prioritize task message delete task message
place message task in folder
27
Activities have characteristics relevant to the software well choose to build

some number of common tasks a general goal or purpose a primary human participant usually other human participants a physical place or location some number of tools including computers, software, electronic files, telephones, information, paper, etc..
activity
task task task task
Be sensitive to your user tasks altitude

Too abstract Activity or Kite level
Longer term goals often with no precise ending. Ill perform several functional tasks in the context of an activity
Functional or Sea level

Id reasonably expect to complete this in a single sitting
Think about user experience at this level
Sub-Functional or Fish level

Small tasks that by themselves dont mean much. Ill do several of these before I reach a functional level goal
Too detailed
* from Cockburns Writing Effective Use Cases
User tasks make ideal user stories:

Title: Take a shower
As an instructor I want to take a shower So that I dont offend my colleagues
30
In practice user stories may be written to describe user tasks or the tools that support them
goals
user story
More task-centric:
As a weekend gardener
I want to dig a hole
tasks
software
so that I can plant a tree More tool-centric:

(or feature-centric)
As a weekend gardener I want a shovel so that I can [dig a hole to] plant a tree
31
features
Getting started with a Story Mapping Problem

Read the Barneys Information Kiosk problem Think about the experience of someone using the kiosk
(5 minutes)
Barneys
In small workgroups (3-5 people) discuss:

What are Barneys goals or pains?
What types of users might use the kiosk and why?

Try to talk about users tasks without talking about the kiosk (tool) this can be difficult
(5 minutes)
Your team
33
What are the goals & tasks?

Business goals or pain points?
Types of users using this system?

Users goals or pains? How will users of the system reach their goals?
Start with an understanding or user experience

Write user scenarios to think through user experience

Steven
Credit Card Marketing Field Manager Steven is a field manager working at the local shopping center. Hes in the middle of a long workday supervising 13 reps who are busy talking to people trying to convince them to apply for a credit card.
5. The date is defaulted to today, and the shift is defaulted to morning since he hasnt yet entered info for today. Steve begins to enter the reps name, but after a few characters the system auto-completes his name. 6. The reps ID is already filled in, along with the code for the credit card promotion theyre working on today. 7. Steve fills in the shift information for his rep. He then enters the total number of applications taken.
Field Manager enters daily performance reports

The shift has just ended and his reps are coming up with their totals. They have printed sheets with totals written on them. Steve quickly looks them over and signs them off. His assistant manager brings him other sheets with totals hes signed off. In between visits by reps, Steve opens his Field Manager Workbench on his laptop. After logging in he sees todays date and the planned number of applications his reps should be gathering 180 for today.
8. It looks like from the notes on this sheet that this rep left sick two hours early. Steve adds a note about this in the system.
9. Time passes as more reps bring in their sheets and Steve completes entering them in between conversations. 10. After all the sheets are done, Steve looks at a summary screen for the day. It looks like hes close to his goal. If the next shift continues at this rate hell beat the plan by 5% or so. Thats good.
He also sees yesterdays numbers, and last weeks numbers, and the last 30 days in graph that shows applications relative to approval rate. Last weeks numbers were bad, and its the last week of the month, so Steve knows hes got to do well today.
Steve clicks enter rep performance data. He shuffles his reps Jeff Patton, all rights reserved, www.AgileProductDesign.com
11. Steve validates that the base pay is correct at $5 per app, and that hes set an individual bonus giving reps $50 each if they reach 20 apps. Next to each rep he sees the calculated pay, base, bonus, and total pay for the day.
12. The annual sale at Macys has brought a lot of people in today. Steve chooses a sale increases mall foot traffic code to add to his shift data sheet. Frank, his boss, has pestered him to make sure he includes this type of information in his daily summaries. 36
A user scenario is a simple way to think through user experience concretely

A user scenario tells a story about a main character with a problem or goal
Describes how that character reaches their goal contains important facts describes external context describes goals and concerns of our character
include interesting plot points that help us envision important aspects of the system
A scenario can gloss over uninteresting details
37
Imagine the user experience as a scenario

Separate your team of four into two pairs One person imagine out loud the experience of someone using the kiosk. Think about: Typical use, including typical problems Interesting plot points Goals and pains of your user The other ask questions to better understand After 5 minutes of discussion write out the scenario
Pair one think about Carol:

casual browser I want to find something good from a band I heard on the radio. Goal: : have fun finding something interesting
Pair two think about Isaac:

Impatient buyer I wan to find a specific hard to find foreign film. Goal: : Find it and get out quickly without wasting my time
38
Extract task-centric user stories from your user scenarios

Come back together as a team
Reviewing each others scenarios, extract taskcentric stories using yellow stickies
Write only the tasks verb-phrase for your title
Organize user stories into a map that communicates experience

By arranging activity and task-centric story cards spatially, we can tell bigger stories
Tell a big story of the product by starting with the major user activities the kiosk will be used for
Arrange activities left to right in the order youd explain them to someone when asked the question: What do people do with this system?
time
41
By arranging task-centric story cards spatially, we can tell bigger stories

Add task-centric stories in under each activity in workflow order left to right.
If you were to explain to someone what a person typically does in this activity, arrange tasks in the order youd tell the story. Dont get too uptight about the order.
time
42
By arranging task-centric story cards spatially, we can tell bigger stories

Overlap user tasks vertically if a user may do one of several tasks at approximately the same time
If in telling the story I say the systems user typically does this or this or this, and then does that, ors signal a stacking vertically, and thens signal stepping horizontally.
time
43
The map shows decomposition and typical flow across the entire system
Reading the activities across the top of the system helps us understand end-to-end use of the system. (Talk through just these when talking with people with short attention spans.)
time
Below each activity, or large story are the child stories that make it up
Building a story map helps facilitate discussion but requires a bit of space
Gary Levitt, owner & designer of Mad Mimi

A story map for a reasonable sized system can fill a room
46
Assemble your harvested task-centric stories into a simple story map

Work as a team to organize your stories Look for activities: tasks that seems similar, are done by similar people in pursuit of similar goals
Use a different color sticky to label activities

time
47
Discuss, fill in, refine the map, and test for completeness
Once youve got the idea down, its quick to record stories as you discuss the experience with users
Discuss the steps of the process with candidate users
Record tasks as they say them Rearrange tasks and insert tasks as you clarify the big story Add activities as you identify them from discussion
time
49
As details emerge in conversation, trap them under their associated task cards
Record details so theyre not lost, and so those who youre working with know that youre listening
Consider tucking them under tasks cards to hide them from the discussion
activity
time
task sub-tasks or task details
50
This simple model is easy to stack

1
7 5 6 8 9 10
1.
2 3
4
11
2. 3.
10
11
1 2 3 4 5 6 7 8 9 11 10
51
By arranging activity and task-centric story cards spatially, we can tell bigger stories axis to indicate necessity Add a vertical
Move tasks up and down this axis to indicate how necessary they are to the activity.
For a user to successfully engage in this activity, is it necessary they perform this task? If its not absolutely necessary, how critical is it?
time
necessity
52
By arranging activity and task-centric story cards spatially, we can tell bigger stories Map by telling bigger stories with it Test the Story
Choose an activity to start with When reading left to right use the conjunction and then to connect cards in the story With cards in the same row use or to connect cards in the story For cards below the top, absolutely necessary axis, use the phrase might optionally to communicate optionality Chose a concrete user name to help tell the story
time
necessity
53
By arranging activity and task-centric story cards spatially, we can tell bigger stories the title of what hes looking for. He steps up to Steve knows
the kiosk and searches by title. Optionally he might have searched by artist. After seeing titles that match what he typed in, Steve views the price new and used, and then views the status whether its in stock or not. He notices its in stock as both new and used, so then Steve views the location in the store for the used title.
Notice the bold time user tasks faced from our story map
necessity
Notice the conjunctions that knit the cards together into a longer story
54
Discussions over story maps help drive out more details
QuickTime an d a YUV420 codec decompressor are need ed to see this p icture .
Repeated review of the story map with multiple users and subject matter experts will help test the model for completeness
The user story map contains two important anatomical features

The backbone of the application is the list of essential activities the application supports The walking skeleton is the software we build that supports the least number of necessary tasks across the full span of user experience
The backbone
time
The walking skeleton

necessity
56
Using discussion, fill in your story map

Work together as a team Look for alternative tasks
What else might users of the system have done that didnt come up in your scenarios?
Look for exceptions

What could go wrong, and what would the user have to do to recover?
Consider other users

What might other types of users do to reach their goals?
Knit al these additional stories into your map

Slice the map to find ideal incremental releases
58
Agile teams plan product construction in layers
59
Agile teams plan product construction in layers
60
Release Product or Project

What business objectives will the product fulfill? Product Goals Product Charter How can we release value incrementally? What subset of business objectives will each release achieve? What user constituencies will the release serve? What general capabilities (big stories) will the release offer?
Customers
User Personas
Release Roadmap
Target Customers Target Personas
Iteration or Sprint
What specifically will we build? (user stories) How will this iteration move us toward release objectives? Iteration Goal Development or Construction Tasks
Story (Backlog Item)
What user or stakeholder need will the story serve? How will it specifically look and behave? How will I determine if its completed? Story Details Acceptance Tests 61
Given story map organized vertically by necessity, we need only slice to plan
time necessary less optional
first release
optionality
second release
more optional
third release
Choose coherent groups of features that consider the span of business functionality and user activities Support all necessary activities with the first release Improve activity support and add additional activities with subsequent releases
Given story map organized vertically by necessity, we need only slice to plan
63
Adding tape lines to the wall lets participants organize stories into layers
64
Adding tape lines to the wall lets participants organize stories into layers
65
Planning incremental releases can be facilitated as a collaborative event
66
Theres a secret to effective prioritization

(Before I give my ideas about what it is, whats worked for you?)
67
Identify and prioritize desired outcomes before prioritizing the backlog

Product goals describe what outcome or benefit received by the organization after the product is in use
68
Product goals suggest how the business will earn value from the product, and how we can tell were getting it
Software built for internal use usually saves money or helps improve service to customers indirectly earning money Software built for use by customers earns money through direct sales, improved customer retention, or improved customer loyalty Product goals are specific to that product - not generic to any product. A goal to earn more money isnt useful Given a product goal, ask: if were making progress towards this goal, how would we know it? What would we observe in our organization that indicates success? The answer to these questions are useful metrics
Use product goals to identify candidate incremental releases, where each release delivers benefit
Create horizontal swim-lanes to group features into releases Arrange features vertically by necessity from the users perspective Split tasks into parts that can be deferred till later releases
Use the product goals from your handouts to identify slices that incrementally realize product goals
necessary optionality less optional
more optional
70
The software we choose to build is a consequence of smaller upstream choices

Business Goals User Constituencies
Choices in business goals, users, and use have big consequences to software scope
Use (Activities & Tasks)
Software to build (Specified as User Stories)
71
Segmenting scope into incremental releases also segments use, user goals, and business goals
Business Goals User Constituencies
Use (Activities & Tasks)
Work top down (goals to scope) or bottom up (scope back to goals), but always work to ensure youre delivering scope that delivers on targeted business and user goals
Software to build (Specified as User Stories)
3
72
A product release roadmap targets benefit delivered over time

A roadmap serves to clearly communicate release level product goals and benefits to stakeholders For each incremental release:
Give the release a name or simple statement describing its purpose think mantra Write a short sentence or two describing what value or benefit the business gets Write a short sentence or two describing what value or benefit the users get
73
Turn your sliced story map into a roadmap

For each slice in your release:
Give the release a name or simple statement describing its purpose think mantra Write a short sentence or two describing what value or benefit the business gets Write a short sentence or two describing what value or benefit the users get
74
Iteratively and incrementally construct software

Traditional software development fixes scope then estimates, and attempts to fix time and cost
Scope
Traditional software development
Time
Cost (resources)
76
Agile development fixes time and cost, then leverages iteration and incrementing to maximize scope
Time Scope Cost (resources)
Agile software development
Time
Cost Scope (resources)
77
Leverage a shared understanding of desired product goals to minimize scope while maximizing value
Scope
Time Cost (resources)
Agile software development
Time
Cost (resources)
Scope
Target business goals & outcomes
78
To release benefit on a schedule well need to leverage incremental and iterative thinking
(Whats the difference?)
incrementing builds a bit at a time

Incrementing calls for a fully formed idea. And, doing it on time requires dead accurate estimation.
80
iterating builds a rough version, validates it, then slowly builds up quality
A more iterative allows you to move from vague idea to realization making course corrections as you go.
81
Many organizations consider revising the same functionality as failure. Iteration is not tolerated.
193 Jeff Patton, all rights reserved, www.AgileProductDesign.com 82
As a product owner, you need a more refined understanding of shippable
83
Keeping our user stories task-centric allowed us to defer solution decisions
user goal user task

tool
Make feature decisions in the context of time and budget limitations

(to put the flower in)
hole
dig hole
hold my options open
Commit to satisfying user needs, not to specific features

(to put the flower in)
hole
dig hole
86
Products with similar features often vary substantially in the price we pay
Think about the high-level features in a car - well a bus in our example At a high level, all features are necessary But we know that all buses dont have the same price Each essential feature varies in subjective quality affecting the final price
low cost
engine transmission brakes suspension seats steering wheel
moderate cost
high cost
51
87
Kano cautions us to consider quality as being composed of objective and subjective elements
Discussions of quality have revolved around the two aspects of subjectivity and objectivity since the time of Aristotle. Embedded in this objectivesubjective split is the idea that objective quality pertains to the conformance to requirements while subjective quality pertains to the satisfaction of users.
--Noriaki Kano
Theres more to me than that silly survey technique!
Kano explains three general classifications for product features: must-haves, one-dimensionals, and delighters
Must-haves
The products must have this features for me to be consider the product acceptable
One-dimensionals
This car has many flaws. Buy it anyway. Its so much fun to drive -- from a NY Times review of the Mini Cooper
The more of this I get, the better
Delighters
I love this element of the product!
89
Separate objective quality from subjective quality

Objective quality refers to the visible measurable, and easily validated characteristics of the product usually in relation to the products specifications.
Does the product perform bug free as specified?

Expect objective quality to be high. Subjective quality refers to the specification or product design choices you make as a product owner. These choices affect the product users perception of quality Is the product simple to use? Is the product efficient to use? Do I like using the product?
Use the Kano classifications to both prioritize and split

Brakes (must have)
Basic brakes (must have)
(one dimensional)
Stopping distance
Anti-locking (delighter)
Cool dashboard light when slipping (delighter)
Keep in mind: you must know your customers and users to determine subjective value.
One persons delighter may leave others apathetic.

Anothers must have is useless to other customers
Lets look at what happens if we take a naive incremental aproach to construction

Lets start with the basic features of our bus.
sprint 4 3 2 1
release
Interior seating
exterior body
transmission
suspension
features
brakes
engine
Product goal: (in 4 sprints) be driving the coolest bus in town

tires
We can leverage iteration to build up quality

Iterating affords building up quality over time
93
Consider these four story splitting heuristics that build up quality

Bare Necessity
For the feature to be minimally demonstrable but not releasable, what is the minimal functionality Example: A form with only necessary fields and no validation
Capability & Flexibility

What would add the ability to perform the user task in different ways? Adding in sub tasks that are optionally performed?
Example: a form with optional fields, date lookup tools, input translation on dates
Safety
What would make this feature safer for me to use? For both the user, and for the business paying for the software?
Example: input validation, enforcement of business rules such as credit card validation
* Adapted from Gerard Meszaros Storyotypes
Usability, Performance, Sex Appeal

More desirable to use? Faster to use?
95
What would make this feature easier to use? Jeff Patton, all rights reserved, www.AgileProductDesign.com
Building up quality iteratively and incrementally ships the best product possibleknow each story can be split into at least four parts We
sprint 4 3 2 1
Early iterations strive to build bare necessities, later iterations build up quality Evaluating readiness based on subjective quality to understand doneness
BAD
C D B A
CBD B
release
D B A
AD B
AD B I
BD I
user tasks to support
Product goal: (in 4 sprints) be driving the highest quality bus possible
Divide release design & development into three phases

Opening Game: Build a simple system span of necessary features first the walking skeleton Mid-Game: Add flexibility and safety next End Game: Finish with comfort, performance, and luxury Reserve time in the remaining third for unforeseen additions and adaptations
Opening Game Build up necessities Mid-Game Build out flexibility and business rule enforcement End-Game
Refine the UI and interactions, take advantage of iterative learning
uncertainty
uncertainty decreases over time

time
Construx on the Cone of Uncertainty: http://www.construx.com/Page.aspx?hid=1648 Visdos on the cone: http://www.implementingscrum.com/2008/02/19/vegas-hangover-enlightenment/ Jeff Patton, all rights reserved, www.AgileProductDesign.com 97
This product growing strategy slowly brings the product into focus
An artist envisions an entire painting by starting with a sketch or an under-painting and slowly building up detail Apply the same strategy to learn about the product domain as quickly as possible to chase out uncertainty before too heavily investing
Opening Game Build up necessities Mid-Game Build out flexibility and business rule enforcement End-Game
Refine the UI and interactions, take advantage of iterative learning
uncertainty
uncertainty decreases over time

time
98
Looking at the release of business value over time lets us see whats going on here
cumulative business value
To finish on time we may trim the tail by deferring stories of modest value
time Opening Game

Early stories emphasize iteration and learning. We need to be sure were building the right product
Mid Game
Once were confident we have the shape of the product right, we begin to pile in value
End Game
Over time the value of stories begin to diminish signaling its time for release
99
Split a task-centric backlog item into smaller iteration stories using the 4 quality heuristics Work in small groups of 2-3 people. Review the Story Map the organized backlog for the Barneys problem Choose a story youd like to work with, one where your group can imagine a prospective user interface. Brainstorm the smaller stories that could build up the larger story to its full quality. Arrange your brainstormed stories into 3 pile:
Guidelines for releasing on time

Thin stories aggressively during early sprints to build all essential functionality early.
Build up functionality only after all necessities are in place.

Protect time in the final sprints for product refinement. Assess release readiness at the end of each sprint as part of product review.
Parting thoughts
102
Questions?
103
Building Better Products Using
User Story Mapping
Jeff Patton
jpatton@acm.org www.agileproductdesign.com

Patton User Story Mapping

Uploaded by

Copyright:

Available Formats

Patton User Story Mapping

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Patton User Story Mapping

Uploaded by

Copyright:

Available Formats

Building Better Products Using

User Story Mapping

Our goals and agenda today

Part 2: Planning valuable incremental releases

Part 3: Iteratively constructing software (time permitting)

Starting with the User Story

Jeff Patton, all rights reserved, www.AgileProductDesign.com

User Stories are multi-purpose

QuickTime an d a Cinepak decompressor are need ed to see this p icture .

User Stories are multi-purpose

Jeff Patton, all rights reserved, www.AgileProductDesign.com

Stories gain detail over time

Add other relevant notes, specifications, or sketches

Agile customers or product owner prioritize stories into a backlog

Jeff Patton, all rights reserved, www.AgileProductDesign.com

Lets talk about the nature of multi-purpose things

Jeff Patton, all rights reserved, www.AgileProductDesign.com

User Stories are boundary objects

What are the details of what I need to work on today?

Jeff Patton, all rights reserved, www.AgileProductDesign.com

But size always matters...

Jeff Patton, all rights reserved, www.AgileProductDesign.com

And, its easy to get lost in the sheer number of them

Jeff Patton, all rights reserved, www.AgileProductDesign.com

And, as we start moving forward, how do we stay on track?

Jeff Patton, all rights reserved, www.AgileProductDesign.com

User Story Mapping is an an approach to Organizing and Prioritizing user stories

User Story Mapping is an an approach to Organizing and Prioritizing user stories

Jeff Patton, all rights reserved, www.AgileProductDesign.com

The foundational building block of a story map is the user task

First lets do a warm-up exercise to understand a few concepts

First lets do a warm-up exercise to understand a few concepts

In a small group (3 to 5 people) merge these stickies into a single model

People achieve goals through interaction

goal evaluation action

Is my goal met or problem resolved?

Information and tools

Think of three levels: goal, task, and tool

action evaluation the world

Information and tools

Did that action deliver the results I expected?

Think of three levels: goal, task, and tool

employees, vendors, & systems

Jeff Patton, all rights reserved, www.AgileProductDesign.com

Jeff Patton, all rights reserved, www.AgileProductDesign.com

Activities have characteristics relevant to the software well choose to build

Be sensitive to your user tasks altitude

Functional or Sea level

Think about user experience at this level

Sub-Functional or Fish level

User tasks make ideal user stories:

Jeff Patton, all rights reserved, www.AgileProductDesign.com

As an instructor I want to take a shower So that I dont offend my colleagues

I want to dig a hole

so that I can plant a tree More tool-centric:

Getting started with a Story Mapping Problem

In small workgroups (3-5 people) discuss:

What types of users might use the kiosk and why?

Jeff Patton, all rights reserved, www.AgileProductDesign.com

What are the goals & tasks?