This action might not be possible to undo. Are you sure you want to continue?
User Story Mapping
© 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 user’s 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
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
www. all rights reserved. © NBC Studios © Jeff Patton.com 4 .User Stories are multi-purpose QuickTime™ an d a Cinepak decompressor are need ed to see this p icture .AgileProductDesign.
all rights reserved. www.AgileProductDesign.com 5 . 1999 © Jeff Patton.User Stories are multi-purpose Stories are a: User’s 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.
www. specifications. all rights reserved.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. or sketches Before building software write acceptance criteria (how do we know when we’re done?) © Jeff Patton.com 6 .AgileProductDesign.
www.AgileProductDesign. all rights reserved.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 © Jeff Patton.com 7 .
AgileProductDesign.Let’s talk about the nature of multi-purpose things (yes I’m going meta.com 8 . all rights reserved. I blame Brian. www.) © Jeff Patton.
www. and become strongly structured in individual-site use. They may be abstract or concrete.AgileProductDesign.User Stories are boundary objects “A boundary object is a concept in sociology to describe information used in different ways by different communities. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds. interpreted differently across communities but with enough immutable content to maintain integrity” -Wikipedia “They are weakly structured in common use. 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. They are plastic.” -. all rights reserved.Leigh & Griesemer © Jeff Patton.com 9 .
all rights reserved. www.com 10 .AgileProductDesign.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? © Jeff Patton.
How big is the story we want to talk about? © Jeff Patton.com 11 . www.But size always matters. all rights reserved.AgileProductDesign...
AgileProductDesign.com 12 . it’s easy to get lost in the sheer number of them © Jeff Patton. www.And. all rights reserved.
www. all rights reserved.And. as we start moving forward.AgileProductDesign. how do we stay on track? © Jeff Patton.com 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 © Jeff Patton.com 14 . www.AgileProductDesign. all rights reserved.
User Story Mapping is an an approach to Organizing and Prioritizing user stories
Story Maps support the primary intent of user stories, rich discussion
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
The foundational building block of a story map is the user task
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 16
First let’s 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
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 17
com 18 . all rights reserved.AgileProductDesign. www.First let’s 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 © Jeff Patton.
www.What’s common about the items each of you wrote down? What was different? How did the models created by different groups vary? © Jeff Patton.AgileProductDesign.com 19 . all rights reserved.
AgileProductDesign. or what I’d 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 © Jeff Patton.People achieve goals through interaction problem or goal How I’d like to feel.com 20 the world . www. all rights reserved.
task.AgileProductDesign.Think of three levels: goal. and tool problem or goal How I’d like to feel.com 21 tool Did that action deliver the results I expected? . all rights reserved. www. or what I’d like to achieve goal task goal evaluation Is my goal met or problem resolved? action Take some action evaluation the world Information and tools © Jeff Patton.
www.Think of three levels: goal.AgileProductDesign.com 22 . and tool goal task tool © Jeff Patton. all rights reserved. task.
www.Software contains features that support a variety of tasks and a variety of goals goals tasks software features tools © Jeff Patton.AgileProductDesign. all rights reserved.com 23 .
and tools apply at both a personal and organizational level goals tasks tools © Jeff Patton. vendors. all rights reserved.AgileProductDesign. www. tasks. & systems 25 .com business objectives business processes employees.Goals.
com 26 . all rights reserved. www.AgileProductDesign.User tasks are decompose to smaller tasks and organize into activities Tasks require intentional action on behalf of a tool’s 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 © Jeff Patton.
com 27 .AgileProductDesign. “Managing email” is read manage email activity an activity.User tasks are decompose to smaller tasks and organize into activities Tasks require intentional action on behalf of a tool’s 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. task message create task folder send task message prioritize task message delete task message place message task in folder © Jeff Patton. all rights reserved. www.
paper.com 28 . telephones. electronic files.AgileProductDesign.. activity task task task task © Jeff Patton. etc. all rights reserved. information. www. software.Activities have characteristics relevant to the software we’ll 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.
www. I’ll do several of these before I reach a functional level goal Too detailed * from Cockburn’s Writing Effective Use Cases © Jeff Patton.Be sensitive to your user task’s “altitude” Too abstract Activity or “Kite level” Longer term goals often with no precise ending.AgileProductDesign. all rights reserved. I’ll perform several functional tasks in the context of an activity Functional or “Sea level” I’d 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 don’t mean much.com 29 .
www.AgileProductDesign.User tasks make ideal user stories: Title: Take a shower © Jeff Patton.com As an instructor I want to take a shower So that I don’t offend my colleagues 30 . all rights reserved.
all rights reserved.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 © Jeff Patton.com .AgileProductDesign. www.
Getting started with a Story Mapping Problem Read the Barney’s Information Kiosk problem Think about the experience of someone using the kiosk (5 minutes) Barney’s In small workgroups (3-5 people) discuss: What are Barney’s 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) © Jeff Patton.AgileProductDesign. all rights reserved.com Your team 33 . www.
all rights reserved.AgileProductDesign.com 34 .What are the goals & tasks? Business goals or pain points? Types of users using this system? User’s goals or pains? How will users of the system reach their goals? © Jeff Patton. www.
AgileProductDesign. www.com 35 .Start with an understanding or user experience © Jeff Patton. all rights reserved.
9. 8. so Steve knows he‟s got to do well today. has pestered him to make sure he includes this type of information in his daily summaries. The rep‟s ID is already filled in. Time passes as more reps bring in their sheets and Steve completes entering them in between conversations. Field Manager enters daily performance reports The shift has just ended and his reps are coming up with their totals. It looks like he‟s close to his goal. It looks like from the notes on this sheet that this rep left sick two hours early. and that he‟s set an individual bonus giving reps $50 each if they reach 20 apps. www.AgileProductDesign. Steve fills in the shift information for his rep. and it‟s the last week of the month. 12.com 11. Steve validates that the base pay is correct at $5 per app. The annual sale at Macy‟s has brought a lot of people in today. Next to each rep he sees the calculated pay. 5. Last week‟s numbers were bad. Steve begins to enter the reps name. Steve looks at a summary screen for the day. his boss. all rights reserved. In between visits by reps.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. His assistant manager brings him other sheets with totals he‟s signed off. Steve opens his Field Manager Workbench on his laptop. and last week‟s numbers. 10. Steve quickly looks them over and signs them off. but after a few characters the system auto-completes his name. After logging in he sees today‟s date and the planned number of applications his reps should be gathering – 180 for today. After all the sheets are done. and total pay for the day. He then enters the total number of applications taken. 7. That‟s good. He’s 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. and the last 30 days in graph that shows applications relative to approval rate. 36 . along with the code for the credit card promotion they‟re working on today. and the shift is defaulted to „morning‟ since he hasn‟t yet entered info for today. If the next shift continues at this rate he‟ll beat the plan by 5% or so. He also sees yesterday‟s numbers. Steve clicks “enter rep performance data.” He shuffles his reps © Jeff Patton. base. 6. They have printed sheets with totals written on them. The date is defaulted to today. bonus. Steve chooses a “sale increases mall foot traffic” code to add to his shift data sheet. Frank. Steve adds a note about this in the system.
www. all rights reserved.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 © Jeff Patton.AgileProductDesign.com 37 .
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. all rights reserved.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. www.AgileProductDesign. Think about: Typical use.com 38 .” 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 © Jeff Patton.
www.com 39 . all rights reserved.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 © Jeff Patton.AgileProductDesign.
all rights reserved.Organize user stories into a map that communicates experience © Jeff Patton. www.AgileProductDesign.com 40 .
www.AgileProductDesign.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 you’d explain them to someone when asked the question: “What do people do with this system?” time © Jeff Patton. all rights reserved.com 41 .
Don’t get too uptight about the order.com 42 . all rights reserved. we can tell bigger stories Add task-centric stories in under each activity in workflow order left to right. www.AgileProductDesign. If you were to explain to someone what a person typically does in this activity. time © Jeff Patton.By arranging task-centric story cards spatially. arrange tasks in the order you’d tell the story.
By arranging task-centric story cards spatially.AgileProductDesign. all rights reserved.” “or’s” signal a stacking vertically. and then does that. 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. www. time © Jeff Patton.com 43 . “and then’s” signal stepping horizontally.
or large story are the child stories that make it up © Jeff Patton.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.com 44 . (Talk through just these when talking with people with short attention spans.AgileProductDesign.) time Below each activity. www. all rights reserved.
owner & designer of Mad Mimi © Jeff Patton.com 45 .Building a story map helps facilitate discussion – but requires a bit of space Gary Levitt. all rights reserved. www.AgileProductDesign.
all rights reserved.AgileProductDesign.com 46 . www.A story map for a reasonable sized system can fill a room © Jeff Patton.
com 47 .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. www. all rights reserved. are done by similar people in pursuit of similar goals Use a different color sticky to label activities time © Jeff Patton.AgileProductDesign.
www. fill in. and test for completeness © Jeff Patton.com 48 .AgileProductDesign. all rights reserved.Discuss. refine the map.
www.AgileProductDesign.Once you’ve got the idea down. it’s 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 © Jeff Patton.com 49 . all rights reserved.
com 50 . www. all rights reserved.As details emerge in conversation. and so those who you’re working with know that you’re listening Consider tucking them under tasks cards to “hide them” from the discussion activity time task sub-tasks or task details © Jeff Patton. trap them under their associated task cards Record details so they’re not lost.AgileProductDesign.
all rights reserved. 2 3 4 11 2.com 51 .This simple model is easy to stack 1 7 5 6 8 9 10 1.AgileProductDesign. www. 3. 1 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 8 9 11 10 © Jeff Patton.
com 52 . is it necessary they perform this task? If it’s not absolutely necessary. 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. www. how critical is it? time necessity © Jeff Patton.By arranging activity and task-centric story cards spatially. all rights reserved.AgileProductDesign.
www.By arranging activity and task-centric story cards spatially.AgileProductDesign.com 53 . 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. use the phrase “might optionally” to communicate optionality Chose a concrete user name to help tell the story time necessity © Jeff Patton. “absolutely necessary” axis. all rights reserved.
By arranging activity and task-centric story cards spatially.com 54 . Optionally he might have searched by artist. so then Steve views the location in the store for the used title.AgileProductDesign. we can tell bigger stories the title of what he’s looking for. Steve views the price new and used.” Notice the bold time user tasks faced from our story map necessity Notice the conjunctions that knit the cards together into a longer story © Jeff Patton. He steps up to “Steve knows the kiosk and searches by title. and then views the status – whether it’s in stock or not. all rights reserved. www. He notices it’s in stock as both new and used. After seeing titles that match what he typed in.
Discussions over story maps help drive out more details QuickTime™ an d a YUV420 codec decompressor are need ed to see this p icture .com 55 . www. all rights reserved. Repeated review of the story map with multiple users and subject matter experts will help test the model for completeness © Jeff Patton.AgileProductDesign.
com 56 . all rights reserved.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 © Jeff Patton. www.AgileProductDesign.
fill in your story map Work together as a team Look for alternative tasks What else might users of the system have done that didn’t come up in your scenarios? Look for exceptions What could go wrong.AgileProductDesign. 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 © Jeff Patton. www.com 57 . all rights reserved.Using discussion.
com 58 . all rights reserved. www.AgileProductDesign.Slice the map to find ideal incremental releases © Jeff Patton.
www.Agile teams plan product construction in layers © Jeff Patton.com 59 . all rights reserved.AgileProductDesign.
AgileProductDesign. www.com 60 . all rights reserved.Agile teams plan product construction in layers © Jeff Patton.
com . all rights reserved.AgileProductDesign.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 it’s completed? Story Details Acceptance Tests 61 © Jeff Patton. www.
all rights reserved.AgileProductDesign. 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 © Jeff Patton.com 62 . www.Given story map organized vertically by necessity.
AgileProductDesign.Given story map organized vertically by necessity. all rights reserved. we need only slice to plan © Jeff Patton. www.com 63 .
AgileProductDesign.Adding tape lines to the wall lets participants organize stories into layers © Jeff Patton. all rights reserved.com 64 . www.
www.AgileProductDesign.com 65 . all rights reserved.Adding tape lines to the wall lets participants organize stories into layers © Jeff Patton.
Planning incremental releases can be facilitated as a collaborative event © Jeff Patton.com 66 . www.AgileProductDesign. all rights reserved.
www.There’s a secret to effective prioritization (Before I give my ideas about what it is.com 67 . all rights reserved. what’s worked for you?) © Jeff Patton.AgileProductDesign.
com 68 .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 © Jeff Patton.AgileProductDesign. all rights reserved. www.
improved customer retention.com 69 . all rights reserved. and how we can tell we’re 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.Product goals suggest how the business will earn value from the product. www. how would we know it? What would we observe in our organization that indicates success?” The answer to these questions are useful metrics © Jeff Patton.not generic to any product. or improved customer loyalty Product goals are specific to that product .AgileProductDesign. A goal to earn more money isn’t useful Given a product goal. ask: “if we’re making progress towards this goal.
AgileProductDesign.com 70 . www. all rights reserved.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 user’s 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 © Jeff Patton.
AgileProductDesign.com 71 . all rights reserved. www. and use have big consequences to software scope Use (Activities & Tasks) Software to build (Specified as User Stories) © Jeff Patton. users.The software we choose to build is a consequence of smaller upstream choices Business Goals User Constituencies Choices in business goals.
AgileProductDesign. www. user goals. but always work to ensure you’re delivering scope that delivers on targeted business and user goals Software to build (Specified as User Stories) 1 2 3 72 © Jeff Patton. and business goals Business Goals User Constituencies Use (Activities & Tasks) Work top down (goals to scope) or bottom up (scope back to goals).com .Segmenting scope into incremental releases also segments use. all rights reserved.
www. all rights reserved.com 73 .AgileProductDesign.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 © Jeff Patton.
all rights reserved. www.com 74 .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 © Jeff Patton.AgileProductDesign.
AgileProductDesign. all rights reserved.Iteratively and incrementally construct software © Jeff Patton.com 75 . www.
Traditional software development fixes scope then estimates.com 76 . all rights reserved. www. and attempts to fix time and cost Scope Traditional software development Time Cost (resources) © Jeff Patton.AgileProductDesign.
www.Agile development fixes time and cost.AgileProductDesign.com 77 . then leverages iteration and incrementing to maximize scope Time Scope Cost (resources) Agile software development Traditional software development Time Cost Scope (resources) © Jeff Patton. all rights reserved.
AgileProductDesign. www.com Target business goals & outcomes 78 . all rights reserved.Leverage a shared understanding of desired product goals to minimize scope while maximizing value Scope Time Cost (resources) Agile software development Traditional software development Time Cost (resources) Scope © Jeff Patton.
www.To release benefit on a schedule we’ll need to leverage incremental and iterative thinking (What’s the difference?) © Jeff Patton. all rights reserved.com 79 .AgileProductDesign.
AgileProductDesign. all rights reserved.“incrementing” builds a bit at a time Incrementing calls for a fully formed idea.com 80 . 1 2 3 4 5 © Jeff Patton. doing it on time requires dead accurate estimation. www. And.
com 81 .“iterating” builds a rough version. validates it. 1 2 3 4 5 © Jeff Patton. www. all rights reserved.AgileProductDesign. then slowly builds up quality A more iterative allows you to move from vague idea to realization making course corrections as you go.
www.com © 82 . all rights reserved.AgileProductDesign.Many organizations consider revising the same functionality as failure. 193 Jeff Patton. Iteration is not tolerated.
all rights reserved.As a product owner. you need a more refined understanding of “shippable” © Jeff Patton.com 83 .AgileProductDesign. www.
all rights reserved.AgileProductDesign.com 84 . www.Keeping our user stories task-centric allowed us to defer solution decisions user goal user task tool © Jeff Patton.
AgileProductDesign. all rights reserved. www.Make feature decisions in the context of time and budget limitations (to put the flower in) hole ? dig hole hold my options open © Jeff Patton.com 85 .
com 86 . www. not to specific features (to put the flower in) hole ? dig hole © Jeff Patton. all rights reserved.Commit to satisfying user needs.AgileProductDesign.
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 don’t have the same price Each essential feature varies in subjective quality affecting the final price
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
engine transmission brakes suspension seats steering wheel …
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.’”
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 88
There’s more to me than that silly survey technique!
Kano explains three general classifications for product features: must-haves, one-dimensionals, and delighters
The products must have this features for me to be consider the product acceptable
“This car has many flaws. Buy it anyway. It’s so much fun to drive” -- from a NY Times review of the Mini Cooper
The more of this I get, the better
I love this element of the product!
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
Subjective quality refers to the specification or product design choices you make as a product owner. www. all rights reserved.com 90 . Does the product perform bug free as specified? Expect objective quality to be high.Separate objective quality from subjective quality Objective quality refers to the visible measurable. 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? © Jeff Patton.AgileProductDesign. and easily validated characteristics of the product usually in relation to the products’ specifications.
com 91 . Another’s must have is useless to other customers © Jeff Patton. www.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 person’s delighter may leave others apathetic. all rights reserved.AgileProductDesign.
www. all rights reserved.com 92 tires .Let’s look at what happens if we take a naive incremental aproach to construction Let’s 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 © Jeff Patton.AgileProductDesign.
www.We can leverage iteration to build up quality Iterating affords building up quality over time 1 2 3 © Jeff Patton.com 93 . all rights reserved.AgileProductDesign.
Performance. input translation on dates Safety What would make this feature safer for me to use? For both the user.AgileProductDesign. all rights reserved. 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.Consider these four story splitting heuristics that build up quality Bare Necessity For the feature to be minimally demonstrable – but not releasable. enforcement of business rules such as credit card validation * Adapted from Gerard Meszaros’ “Storyotypes” Usability. www. and for the business paying for the software? Example: input validation. date lookup tools.com . Sex Appeal More desirable to use? Faster to use? 95 What would make this feature easier to use? © Jeff Patton.
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.AgileProductDesign.com 96 . all rights reserved. www. 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 © Jeff Patton.
com/Page. 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. performance. www. take advantage of iterative learning uncertainty uncertainty decreases over time time Construx on the Cone of Uncertainty: http://www.com 97 . all rights reserved.construx.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.AgileProductDesign.com/2008/02/19/vegas-hangover-enlightenment/ © Jeff Patton.implementingscrum.aspx?hid=1648 Visdos on the cone: http://www.
www. all rights reserved.com 98 .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 © Jeff Patton.AgileProductDesign.
we begin to pile in value End Game Over time the value of stories begin to diminish signaling it’s time for release © Jeff Patton.Looking at the release of business value over time lets us see what’s 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. all rights reserved. We need to be sure we’re building the right product Mid Game Once we’re confident we have the “shape” of the product right.com 99 .AgileProductDesign. www.
Arrange your brainstormed stories into 3 pile: © Jeff Patton. all rights reserved.com 100 .Split a task-centric backlog item into smaller iteration stories using the 4 quality heuristics Work in small groups of 2-3 people.AgileProductDesign. www. Brainstorm the smaller stories that could build up the larger story to its full quality. one where your group can imagine a prospective user interface. Review the Story Map – the organized backlog – for the Barney’s problem Choose a story you’d like to work with.
com 101 .AgileProductDesign.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. © Jeff Patton. Assess release readiness at the end of each sprint as part of product review. www. all rights reserved. Protect time in the final sprints for product refinement.
AgileProductDesign.Parting thoughts © Jeff Patton. www.com 102 . all rights reserved.
AgileProductDesign.Questions? © Jeff Patton.com 103 . all rights reserved. www.
all rights reserved.com © Jeff Patton.org www. www.agileproductdesign.Building Better Products Using User Story Mapping Jeff Patton jpatton@acm.AgileProductDesign.com .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.