Agile Chennai Keynote by Jeff Patton

Blending User Experience & Business Analysis thinking in the Agile Customer Role 1

Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton 1

Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton ThoughtWorks jpatton@acm.org 1

Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton ThoughtWorks jpatton@acm.org AgileProductDesign.com 1

PEOPLE Learn Skills in a 3-stage Progression: Follow / Break Away / Achieve Fluency Level 1:following (shu) Learn “a technique that works” (Success = following the technique) Level 2:breaking away ( ha ) Learn limits of the technique Learn to shift between techniques Level 3:ﬂuent ( ri ) Shift techniques at any moment Possibly unable to describe the shifts We will use this progression throughout the course. ©Alistair Cockburn Slide 3 2005-6 2

Today I’ll cover 3 areas 1. What is user experience design? 2. Design & analysis practices useful for Agile customers 3. Incorporating design and analysis practices into an Agile lifecycle 3 3

By “Design” I mean the decisions we make regarding the software solution we choose to build. “The hardest single part of building a software system is deciding precisely what to build.” -- Fred Brooks In his 1987 essay “No Silver Bullet” © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 4 4

By “Design” I mean the decisions we make regarding the software solution we choose to build. “The hardest single part of building a software system is deciding precisely what to build.” -- Fred Brooks In his 1987 essay “No Silver Bullet” \"A requirement is a relationship to a decision: If you get to make or change the decision, it's design to you; if you don't get to make or change that decision, it's a requirement to you.\" -- Alistair Cockburn © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 4 4

Garrett’s Elements of User Experience Model describes a series of dependent decisions. 5 5

Software user experience is built from dependent layers Jesse James Garrett’s Elements of User Experience: http://www.jjg.net/elements/ © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 6 6

Structure defines navigation from place to place in the user interface Surface task panes Skeleton Structure modal dialogs Scope modal wizards Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 9 9

The “places” in the user interface are built to support user-task-centric scope user tasks: Surface • enter numbers • enter text • enter formulas • format cells Skeleton • sort information • filter information • aggregate information Structure • graph data • save data • import data • export data Scope • print • ….. Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 10 10

Business goals drive user constituencies choices and contexts supported to form strategy business goals: Surface • displace competitive products • motivate sale of other integrated products • establish file format as default Skeleton information sharing format • … user constituencies: Structure • accountant • business planner • housewife • … Scope usage contexts: • office desktop • laptop on airplane Strategy • pda in car • … © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 11 11

Garret’s Elements of UX stack can apply to the user experience of other complex products These layers of concern apply not only to software but a variety of products. In particular, products that support a wide variety of user tasks benefit from this kind of thinking. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 12 12

Let’s look at the strategy for a product we all use: the place we live goals: Surface • live comfortably • eat well • stay clean • be healthy Skeleton • keep up with Jones’s • … user constituencies: Structure • me • spouse • child • … Scope usage contexts: • suburban neighborhood • near good schools Strategy • near shopping • … © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 13 13

What might I, and my other user constituencies, do to reach our goals? user tasks: Surface • store food • prepare food • eat food • sleep Skeleton • bathe • store changes of clothing • stay out of rain Structure • entertain guests • entertain self • … Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 14 14

Arranging tasks by affinity allows me to think about contexts that best support tasks. Contexts in a home have common names we all know. Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 15 15

When designing a particular interaction context such as a “kitchen,” I optimize layout and tool choices to support tasks I’ll do there Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 16 16

“I’m going to spend a lot of time here, I want my experience to be as pleasant as possible…” Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 17 17

Underneath Garrett’s model is a simple 3 layer model 18 18

Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve take some action © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19

Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve take some action the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19

Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19

Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve goal evaluation is my goal met or problem resolved? take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19

Distilling this down to goals, tasks, and tools problem or goal How I’d like to feel, or what I’d like to achieve goal evaluation is my goal met or problem resolved? take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 20 20

Distilling this down to goals, tasks, and tools goal goal evaluation is my goal met or problem resolved? take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 20 20

When we think about quality of use experience, we need to re-think what we mean by quality. 22 22

Don Norman explains that beauty, at least for products, isn’t skin deep “Attractive things make people feel good, which in turn makes them think more creatively…. making it easier for people to find solutions to the problems they encounter.” -- Don Norman © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 23 23

Norman explains three characteristics of design to observe: Visceral, Behavioral, & Reflective Visceral What is the products initial impact or appearance? Behavioral How does the object feel to use? Reflective What does the object make you think about? What does it say about it’s owner? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 24 24

Noriaki Kano asks 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. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 25 25

Noriaki Kano asks 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 objective- subjective split is the idea that objective quality pertains to the ‘conformance to requirements’ while subjective quality pertains to the ‘satisfaction of users.’” © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 25 25

Noriaki Kano asks 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 objective- subjective split is the idea that objective quality pertains to the ‘conformance to requirements’ while subjective quality pertains to the ‘satisfaction of users.’” --Noriaki Kano © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 25 25

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 happy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26

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 happy One dimensionals © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26

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 happy One dimensionals The more of this I get, the better © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26

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 happy One dimensionals The more of this I get, the better Delighters © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26

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 happy One dimensionals The more of this I get, the better Delighters I love this element of the product! © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26

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 happy One dimensionals The more of this I get, the better “This car has many flaws. Buy it Delighters anyway. It’s so much fun to drive” -- from a NY Times review of the Mini I love this element of the Cooper product! © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26

When we include user experience design into a holistic design process, another model of problem analysis and solution definition becomes useful 27 27

Design alternates between analyzing the problem context and exploring possible solutions sis aly an ti on l em fi ni ob de pr on ti o lu s time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions sis aly an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions sis user aly research an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions user sis modeling user aly research an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis task design (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em fi ni ob de pr user scenario on writing ti o lu business problems s & goals analysis task design (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s & goals analysis task design (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution.  As time passes, problem analysis activities are replaced by solution definition activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29

Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution.  As time passes, problem analysis activities are replaced by solution definition activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29

Now let’s look at practices that a customer or product owner team users to move from problem analysis through to solution definition 30 30

Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31

Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31

Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31

Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31

Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing Planning & road-mapping © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31

Collaborative centers around model building [a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed - Merriam-Webster on-line © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 32 32

Collaborative centers around model building [a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed - Merriam-Webster on-line A goal of a model isn’t completeness or accuracy, but communication © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 32 32

Collaborative centers around model building [a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed - Merriam-Webster on-line A goal of a model isn’t completeness or accuracy, but communication For our purposes:  a model is any visual representation of our current understanding of a concept © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 32 32

Collaborative centers around model building [a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed - Merriam-Webster on-line A goal of a model isn’t completeness or accuracy, but communication For our purposes:  a model is any visual representation of our current understanding of a concept We’ll build models to understand our problem context, and explore solutions © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 32 32

Low fidelity card models are used to facilitate discussions and build common understanding Common model forms include:  Affinity diagrams  Chronological models  Decompositions  Ad hoc charts © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 37 37

Low fidelity card models are used to facilitate discussions and build common understanding Common model forms include:  Affinity diagrams  Chronological models  Decompositions  Ad hoc charts Mix and match as you see fit © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 37 37

Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team  Help the team to gel as an affective workgroup © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 39 39

Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator  Documenter  Schedule & set up work session facility © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 39 39

Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility Perform  Kickoff with goals and scope  Get information figuratively and literally on the table using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39

Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility Document & Communicate Perform  Kickoff with goals and scope  Get information figuratively and literally on the table using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39

Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility Document & Communicate  Capture model with photo and/or movie Perform  Kickoff with goals and scope  Get information figuratively and literally on the table using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39

Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility Document & Communicate  Capture model with photo and/or movie Perform  Document as necessary  Kickoff with goals and scope  Get information figuratively and literally on the table using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39

Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility Document & Communicate  Capture model with photo and/or movie Perform  Document as necessary  Kickoff with goals and scope  Post in publicly accessible place  Get information figuratively and literally on the table using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39

Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility 3Document & Communicate  Capture model with photo and/or movie Perform  Document as necessary  Kickoff with goals and scope  Post in publicly accessible place  Get information figuratively and literally on the table  Display as a poster using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39

Business objectives describes why we’d choose to buy or build the software 41 41

Look for benefit to the buyer or builder of the software For software built for internal use:  Save money  Increase efficiency  Solve problems that are costing money or decreasing efficiency  Improve customer satisfaction  Generate revenue by supporting or improving service offerings © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 42 42

Look for benefit to the buyer or builder of the software For software built for internal use:  Save money  Increase efficiency  Solve problems that are costing money or decreasing efficiency  Improve customer satisfaction  Generate revenue by supporting or improving service offerings For software built for commercial sale:  Generate revenue through sale  Improve/expand market share  Open new markets © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 42 42

Look for benefit to the buyer or builder of the software For software built for internal use:  Save money  Increase efficiency  Solve problems that are costing money or decreasing efficiency  Improve customer satisfaction  Generate revenue by supporting or improving service offerings For software built for commercial sale:  Generate revenue through sale  Improve/expand market share  Open new markets The IRACIS* mnemonic helps us remember to look for business benefit that will  Increase Revenue  Avoid Cost  Increase Service © 2006-2007 Jeff Patton, All rights IRACIS model, 1977 * Gane & Sarson’s reserved, www.agileproductdesign.com 42 42

When asking for business goals look for expressions of business problems or desired outcomes Express goals as business problems or business outcomes © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 43 43

When asking for business goals look for expressions of business problems or desired outcomes Express goals as business problems or business outcomes It’s tempting for business stakeholders or users to describe their proposed solution as a goal  Solution-centric goal: “I’d like a cost effective ski parka”  Problem-centric goal: “I’d like to stay warm and dry while skiing” © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 43 43

When asking for business goals look for expressions of business problems or desired outcomes Express goals as business problems or business outcomes It’s tempting for business stakeholders or users to describe their proposed solution as a goal  Solution-centric goal: “I’d like a cost effective ski parka”  Problem-centric goal: “I’d like to stay warm and dry while skiing” Use root cause analysis to get behind solutions to goals and problems  Toyota’s “5 whys” describes root cause analysis  Poking it with “the why stick” is often what my colleagues say © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 43 43

Use a Goal Question Metric approach to identify appropriate goal metrics Leverage a simple approach from the GQM methodology © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 44 44

Use a Goal Question Metric approach to identify appropriate goal metrics Leverage a simple approach from the GQM methodology 1. Identify and prioritize goals © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 44 44

Use a Goal Question Metric approach to identify appropriate goal metrics Leverage a simple approach from the GQM methodology 1. Identify and prioritize goals 2. Question each goal: If we were making progress toward this goal, how would we know? What would change in the business as a result of reaching this goal? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 44 44

Use a Goal Question Metric approach to identify appropriate goal metrics Leverage a simple approach from the GQM methodology 1. Identify and prioritize goals 2. Question each goal: If we were making progress toward this goal, how would we know? What would change in the business as a result of reaching this goal? 3. Use answers to these questions to identify metrics for goals  Metrics help quantify ROI  Metrics helps justify ongoing development expense  The desire to track metrics often generate important product features © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 44 44

Good business objectives help validate prospective solutions A good set of business objectives help us validate the solutions we choose to construct © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 45 45

Good business objectives help validate prospective solutions A good set of business objectives help us validate the solutions we choose to construct A good set of business objectives are:  short: a single page or slide  prioritized  measurable © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 45 45

Common models such as actors, roles, profiles, & personas describe users Actor & Goal  Often a job title or the common name for the type of user in a system © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 47 47

Common models such as actors, roles, profiles, & personas describe users Actor & Goal  Often a job title or the common name for the type of user in a system User Role  Short name describing a user in pursuit of a goal – users change roles as their goals change © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 47 47

Common models such as actors, roles, profiles, & personas describe users Actor & Goal  Often a job title or the common name for the type of user in a system User Role  Short name describing a user in pursuit of a goal – users change roles as their goals change User Profile  Adding summary information about the types of users who fill a role or perform as an actor begins a process of “profiling” © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 47 47

Common models such as actors, roles, profiles, & personas describe users Actor & Goal On-line Shopper: browse  Often a job title or the common name and purchase merchandise for the type of user in a system on line User Role Customer Support Rep:  Short name describing a user in pursuit aid customers over the of a goal – users change roles as their phone and on line with goals change issues User Profile  Adding summary information about the types of users who fill a role or perform as an actor begins a process of “profiling” Persona  Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 47 47

Common models such as actors, roles, profiles, & personas describe users Casual Browser: pass time by browsing products online Comparison Shopper: compare price and features for items I wish to buy Gift Shopper: find a gift for someone that likes the types of products this website sells Impatient Buyer: find what I need and get through the checkout process quickly © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 48 48

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Casual Browser: pass time  Often a job title or the common name by browsing products for the type of user in a system online Comparison Shopper: compare price and features for items I wish to buy Gift Shopper: find a gift for someone that likes the types of products this website sells Impatient Buyer: find what I need and get through the checkout process quickly © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 48 48

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Casual Browser: pass time  Often a job title or the common name by browsing products for the type of user in a system online Comparison Shopper: User Role compare price and features  Short name describing a user in pursuit for items I wish to buy of a goal – users change roles as their goals change Gift Shopper: find a gift for someone that likes the types of products this website sells Impatient Buyer: find what I need and get through the checkout process quickly © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 48 48

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Casual Browser: pass time  Often a job title or the common name by browsing products for the type of user in a system online Comparison Shopper: User Role compare price and features  Short name describing a user in pursuit for items I wish to buy of a goal – users change roles as their goals change Gift Shopper: find a gift for someone that likes the User Profile types of products this  Adding summary information about the website sells types of users who fill a role or perform Impatient Buyer: find as an actor begins a process of what I need and get “profiling” through the checkout process quickly © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 48 48

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Casual Browser: pass time  Often a job title or the common name by browsing products for the type of user in a system online Comparison Shopper: User Role compare price and features  Short name describing a user in pursuit for items I wish to buy of a goal – users change roles as their goals change Gift Shopper: find a gift for someone that likes the User Profile types of products this  Adding summary information about the website sells types of users who fill a role or perform Impatient Buyer: find as an actor begins a process of what I need and get “profiling” through the checkout process quickly Persona  Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 48 48

Common models such as actors, roles, profiles, & personas describe users Web Shoppers Users: 50,000 customer visit this sporting goods website monthly Activities: browsing, price comparing, gift shopping, handling returns Computer Skills: vary wildly from first time users to expert – although moderate computer skills are typical Domain expertise: typical customers are avid outdoor enthusiasts… © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 49 49

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Web Shoppers  Often a job title or the common name Users: 50,000 customer for the type of user in a system visit this sporting goods website monthly Activities: browsing, price comparing, gift shopping, handling returns Computer Skills: vary wildly from first time users to expert – although moderate computer skills are typical Domain expertise: typical customers are avid outdoor enthusiasts… © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 49 49

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Web Shoppers  Often a job title or the common name Users: 50,000 customer for the type of user in a system visit this sporting goods website monthly User Role  Short name describing a user in pursuit Activities: browsing, price of a goal – users change roles as their comparing, gift shopping, goals change handling returns Computer Skills: vary wildly from first time users to expert – although moderate computer skills are typical Domain expertise: typical customers are avid outdoor enthusiasts… © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 49 49

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Web Shoppers  Often a job title or the common name Users: 50,000 customer for the type of user in a system visit this sporting goods website monthly User Role  Short name describing a user in pursuit Activities: browsing, price of a goal – users change roles as their comparing, gift shopping, goals change handling returns Computer Skills: vary User Profile wildly from first time users  Adding summary information about the to expert – although types of users who fill a role or perform moderate computer skills as an actor begins a process of are typical “profiling” Domain expertise: typical customers are avid outdoor enthusiasts… © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 49 49

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Web Shoppers  Often a job title or the common name Users: 50,000 customer for the type of user in a system visit this sporting goods website monthly User Role  Short name describing a user in pursuit Activities: browsing, price of a goal – users change roles as their comparing, gift shopping, goals change handling returns Computer Skills: vary User Profile wildly from first time users  Adding summary information about the to expert – although types of users who fill a role or perform moderate computer skills as an actor begins a process of are typical “profiling” Domain expertise: typical Persona customers are avid outdoor  Choosing specific characteristics of a enthusiasts… person and compiling those into a archetypal description of that person creates a strong design target © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 49 49

Common models such as actors, roles, profiles, & personas describe users Steve Powell competitive mountain biker “I’m looking for stuff that’ll help me stay ahead of the pack” Steve races mountain bikes competitively. He shops the web on a regular basis to keep abreast of new equipment releases on the market, and to make sure he has the best equipment he can afford. He’s used computers for years and considers himself an expert user. He maintains his own website and blogs about his races and upcoming schedule. Steve relies on reviews from his peers to judge the quality of equipment. He often writes reviews of his own for stuff he’s tried out. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 50 50

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Steve Powell competitive  Often a job title or the common name mountain biker for the type of user in a system “I’m looking for stuff that’ll help me stay ahead of the pack” Steve races mountain bikes competitively. He shops the web on a regular basis to keep abreast of new equipment releases on the market, and to make sure he has the best equipment he can afford. He’s used computers for years and considers himself an expert user. He maintains his own website and blogs about his races and upcoming schedule. Steve relies on reviews from his peers to judge the quality of equipment. He often writes reviews of his own for stuff he’s tried out. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 50 50

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Steve Powell competitive  Often a job title or the common name mountain biker for the type of user in a system “I’m looking for stuff that’ll help User Role me stay ahead of the pack”  Short name describing a user in pursuit of a goal – users change roles as their goals change Steve races mountain bikes competitively. He shops the web on a regular basis to keep abreast of new equipment releases on the market, and to make sure he has the best equipment he can afford. He’s used computers for years and considers himself an expert user. He maintains his own website and blogs about his races and upcoming schedule. Steve relies on reviews from his peers to judge the quality of equipment. He often writes reviews of his own for stuff he’s tried out. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 50 50

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Steve Powell competitive  Often a job title or the common name mountain biker for the type of user in a system “I’m looking for stuff that’ll help User Role me stay ahead of the pack”  Short name describing a user in pursuit of a goal – users change roles as their goals change Steve races mountain bikes competitively. He shops the web on a regular basis to keep abreast of new User Profile equipment releases on the market, and to make sure he has the best equipment  Adding summary information about the he can afford. types of users who fill a role or perform He’s used computers for years and as an actor begins a process of considers himself an expert user. He “profiling” maintains his own website and blogs about his races and upcoming schedule. Steve relies on reviews from his peers to judge the quality of equipment. He often writes reviews of his own for stuff he’s tried out. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 50 50

Common models such as actors, roles, profiles, & personas describe users Actor & Goal Steve Powell competitive  Often a job title or the common name mountain biker for the type of user in a system “I’m looking for stuff that’ll help User Role me stay ahead of the pack”  Short name describing a user in pursuit of a goal – users change roles as their goals change Steve races mountain bikes competitively. He shops the web on a regular basis to keep abreast of new User Profile equipment releases on the market, and to make sure he has the best equipment  Adding summary information about the he can afford. types of users who fill a role or perform He’s used computers for years and as an actor begins a process of considers himself an expert user. He “profiling” maintains his own website and blogs about his races and upcoming schedule. Steve relies on reviews from his peers to Persona judge the quality of equipment. He often writes reviews of his own for stuff he’s  Choosing specific characteristics of a tried out. person and compiling those into a archetypal description of that person creates a strong design target © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 50 50

In organizations where users are paid to use the software, user goals are driven by business goals goals tasks software features © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 52 52

In organizations where users are paid to use the software, user goals are driven by business goals goals tasks All these goals mean lots of tasks, and lots of potential features in our software software features © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 52 52

Design imperatives describe good characteristics the software should have based on the user type Inside your user model are clues about the type of user interface and user interface characteristics needed by your user. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 53 53

Design imperatives describe good characteristics the software should have based on the user type Inside your user model are clues about the type of user interface and user interface characteristics needed by your user. Document these as design imperatives. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 53 53

Design imperatives describe good characteristics the software should have based on the user type Inside your user model are clues about the type of user interface and user interface characteristics needed by your user. Document these as design imperatives. Think about:  ease of learning  retention of learning  efficiency of interaction  reliability of interaction © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 53 53

Design imperatives describe good characteristics the software should have based on the user type Inside your user model are clues about the type of user interface and user interface characteristics needed by your user. Document these as design imperatives. Think about:  ease of learning  user satisfaction  retention of learning  user convenience  efficiency of interaction  necessity for proficiency  reliability of interaction  importance of accuracy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 53 53

A good user model helps us identify functional scope and necessary characteristics of the software A good user model helps:  identify functional scope  identify necessary characteristics of the software  stakeholders understand and empathize with target users  validate proposed software solutions © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 54 54

A good user model helps us identify functional scope and necessary characteristics of the software A good user model helps:  identify functional scope  identify necessary characteristics of the software  stakeholders understand and empathize with target users  validate proposed software solutions An effective user model is prioritized to help rule out unnecessary functional scope and design imperatives © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 54 54

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Draw a left to right axis representing time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Draw a left to right axis representing time time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Identify left to right axis representing time users of the Draw a high level activities performed by system and place them above the time axis in the order that seams reasonable time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Identify left to right axis representing time users of the Draw a high level activities performed by system and place them above the time axis in the order that seams reasonable Activity 1 time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Draw a high level activities performed by Identify left to right axis representing time users of Within each activity, organize tasks in the order they’re mostthe likely completed. There’s likely variation in timethey’re the system and place them above the how axis in order that so arrange them in a completed –seams reasonable typical order.  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Within each activity, organize tasks in the order they’re mostthe Identify left to right axis representing time users of Draw a high level activities performed by likely completed. There’s likely variation in timethey’re the system and place them above the how axis in completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task 1 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Within each activity, organize tasks in the order they’re mostthe Identify left to right axis representing time users of Draw a high level activities performed by likely completed. There’s likely variation in timethey’re the system and place them above the how axis in completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task 1 2 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Within each activity, organize tasks in the order they’re mostthe Identify left to right axis representing time users of Draw a high level activities performed by likely completed. There’s likely variation in timethey’re the system and place them above the how axis in completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task 1 2 3 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Within each activity, organize tasks in the order they’re mostthe Identify left to right axis representing time users of Draw a high level activities performed by likely completed. There’s likely variation in timethey’re the system and place them above the how axis in completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task Task 1 2 3 4 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Within each activity, organize tasks in the order they’re mostthe Identify left to right axis representing time users of Draw a high level activities performed by likely completed. There’s likely variation in timethey’re the system and place them above the how axis in completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task Task Task 1 2 3 4 5 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Withintask details such as business rules or possible the Fill in each activity, organize tasks in the orderby Identify left to right axis representing time users of Draw a high level activities performed they’re most likely completed. There’s likely variation in timethey’re the system and place themtasks below how axis in features that satisfy the above the each task. completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task Task Task 1 2 3 4 5 © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Withintask details such as business rules or possible the Fill in each activity, organize tasks in the orderby Identify left to right axis representing time users of Draw a high level activities performed they’re most likely completed. There’s likely variation in timethey’re the system and place themtasks below how axis in features that satisfy the above the each task. completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task Task Task 1 2 3 4 5 Task Detail (Story) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Withintask details such as business rules or possible the Fill in each activity, organize tasks in the orderby Identify left to right axis representing time users of Draw a high level activities performed they’re most likely completed. There’s likely variation in timethey’re the system and place themtasks below how axis in features that satisfy the above the each task. completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task Task Task 1 2 3 4 5 Task Detail (Story) Task Detail (Story) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Withintask details such as business rules or possible the Fill in each activity, organize tasks in the orderby Identify left to right axis representing time users of Draw a high level activities performed they’re most system and place themtasks below how axis in likely completed. There’s likely variation in timethey’re the features that satisfy the above the each task. completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task Task Task 1 2 3 4 5 Task Detail Task Detail (Story) (Story) Task Detail (Story) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Fill in each activity, organize tasks in the orderby Draw a high level activities performed they’re most Identify left to right axis representing time users of Withintask details such as business rules or possible the likely completed. There’s likely variation in timethey’re the system and place themtasks below how axis in features that satisfy the above the each task. completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task Task Task 1 2 3 4 5 Task Detail Task Detail Task Detail (Story) (Story) (Story) Task Detail (Story) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Withintask details such as business rules or possible the Fill in each activity, organize tasks in the orderby Identify left to right axis representing time users of Draw a high level activities performed they’re most system and place themtasks below how axis in likely completed. There’s likely variation in timethey’re the features that satisfy the above the each task. completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task Task Task 1 2 3 4 5 Task Detail Task Detail Task Detail Task Detail (Story) (Story) (Story) (Story) Task Detail (Story) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map Withintask details such as business rules or possible the Fill in each activity, organize tasks in the orderby Identify left to right axis representing time users of Draw a high level activities performed they’re most likely completed. There’s likely variation in timethey’re the system and place themtasks below how axis in features that satisfy the above the each task. completed –seams reasonable typical order. order that so arrange them in a  If you had to explain the process to someone, arrange Activity 1 them in the order you’d tell the story. time Task Task Task Task Task 1 2 3 4 5 Task Detail Task Detail Task Detail Task Detail (Story) (Story) (Story) (Story) Task Detail Task Detail (Story) (Story) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56 56

A good User Story as used in Scrum and other Agile approaches describes the use of the system The user story form considered “best practice” in Scrum references your user model and user goals. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 57 57

A good User Story as used in Scrum and other Agile approaches describes the use of the system The user story form considered “best practice” in Scrum references your user model and user goals. As a [type of user] I want to [perform some task] so that I can [achieve some goal] © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 57 57

A good User Story as used in Scrum and other Agile approaches describes the use of the system The user story form considered “best practice” in Scrum references your user model and user goals. As a [type of user] I want to [perform some task] so that I can [achieve some goal] As a harried shopper I want to locate a CD in the store so that I can purchase it quickly, leave, and continue with my day. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 57 57

In practice user stories may be written to describe user tasks or the tools that support them goals tasks software features © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 58 58

In practice user stories may be written to describe user tasks or the tools that support them goals user story tasks software features © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 58 58

In practice user stories may be written to describe user tasks or the tools that support them goals More task-centric: As a harried shopper user story I want to locate a specific tasks CD in the store software features © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 58 58

In practice user stories may be written to describe user tasks or the tools that support them goals More task-centric: As a harried shopper user story I want to locate a specific tasks CD in the store More tool-centric: As a harried shopper software I want to enter a CD title features into the search box and initiate a product search © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 58 58

In practice user stories may be written to describe user tasks or the tools that support them goals start with task-centrictask-centric: More user As a harried shopper user story stories early in productlocate a specific I want to tasks discussion and modeling in the store CD More tool-centric: fill in feature-centric As a harried shopper stories till later to software I want enter a CD title features into the search box and initiate a product search © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 58 58

Prioritize task details by necessity to help visualize layers of functionality across the business process Activity 1 time Task Task Task Task Task 1 2 3 4 5 Task Detail Task Detail Task Detail Task Detail (Story) (Story) (Story) (Story) Task Detail Task Detail (Story) (Story) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 68 68

Prioritize task details by necessity to help visualize layers of functionality across the business process Draw a vertical axis to represent necessity Activity 1 time Task Task Task Task Task 1 2 3 4 5 Task Detail Task Detail Task Detail Task Detail (Story) (Story) (Story) (Story) Task Detail Task Detail (Story) (Story) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 68 68

Prioritize task details by necessity to help visualize layers of functionality across the business process Draw a vertical axis to represent necessity Activity 1 time Task Task Task Task Task 1 2 3 4 5 Task Detail Task Detail Task Detail Task Detail (Story) (Story) (Story) (Story) necessity Task Detail Task Detail (Story) (Story) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 68 68

Identify releases in spans of coherent functionality activity 1 activity 2 activity 3 activity 4 time necessary less optional optionality more optional © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 69 69

Identify releases in spans of coherent functionality activity 1 activity 2 activity 3 activity 4 time necessary less optional optionality more optional Choose coherent groups of features that consider the span of business functionality and user activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 69 69

Identify releases in spans of coherent functionality activity 1 activity 2 activity 3 activity 4 time necessary less optional optionality more optional Choose coherent groups of features that consider the span of business functionality and user activities. Support all necessary activities with the first release © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 69 69

Identify releases in spans of coherent functionality activity 1 activity 2 activity 3 activity 4 time necessary less optional optionality more optional 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 with subsequent releases © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 69 69

Identify releases in spans of coherent functionality activity 1 activity 2 activity 3 activity 4 time necessary less first release optional optionality more optional 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 with subsequent releases © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 69 69

Identify releases in spans of coherent functionality activity 1 activity 2 activity 3 activity 4 time necessary less first release optional second release optionality more optional 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 with subsequent releases © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 69 69

Identify releases in spans of coherent functionality activity 1 activity 2 activity 3 activity 4 time necessary less first release optional second release optionality more third release optional 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 with subsequent releases © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 69 69

Distill your release plan into a roadmap A roadmap serves to clearly communicate release level objectives to stakeholders For each incremental release:  Give the release a name or simple statement describing it’s purpose  Write a short sentence or two describing what value the business gets from the release  Write a short sentence or two describing what value the users get from the release © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 70 70

Distill your release plan into a roadmap A roadmap serves to clearly communicate release level objectives to stakeholders For each incremental release:  Give the release a name or simple statement describing it’s purpose  Write a short sentence or two describing what value the business gets from the release  Write a short sentence or two describing what value the users get from the re release S e oftwa t of Sal S Poin asyPO urate r ts acc E he ca sh re giste i sters and g e eplac et sh reg R man ual ca ns se 1: of old oss locatio ake Relea s rid hem m sh es get ion ac r elps t a ss: replac s informat ster that h balancing c Busine inute sale h regi time m se cas , and save up the er to u o eta n easi hen they d iers g em w : Cash , correct th Users takes mis ht. © 2006-2007 Jeff Patton, Allless reserved, nig rights very www.agileproductdesign.com 70 rs e drawe 70

“Bucketing” groups of major functionality or areas of task support is sometimes easier than feature by feature prioritization © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 71 71

Where to do all those practices fit in a typical Agile lifecycle? 72 72

But, it’s commonly understood the snowman is missing a couple balls… Or, that it takes a taller snowman to model product concerns 74 74

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective • Business value • Estimable User Story Feature List: prioritized features (AKA Product Backlog) © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective • Business value • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Iteration © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Iteration • 1-4 week timebox Iteration © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Iteration • 1-4 week timebox Iteration Plan © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Iteration • 1-4 week timebox Iteration Plan Iteration Plan © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Incremental Release © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Incremental Incremental Release Release • 1-6 Iterations • Released internally or externally to end users © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Incremental Incremental Release Plan Release • 1-6 Iterations • Released internally or externally to end users © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Release Plan Incremental Incremental Release Plan Release • 1-6 Iterations • Released internally or externally to end users © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Evaluate Release Plan Incremental Incremental Release Plan Release • 1-6 Iterations • Released internally or externally to end users © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Evaluate Release Plan Incremental Incremental Release Plan Release • 1-6 Iterations • Released internally or externally to end users Product/Project © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Evaluate Release Plan Incremental Incremental Release Plan Release • 1-6 Iterations • Released internally or externally to end users Product/Project Product or Project • Perpetually released © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Evaluate Release Plan Incremental Incremental Release Plan Release • 1-6 Iterations • Released internally or externally to end users Product/Project Product or Project Plan • Perpetually released © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Evaluate Release Plan Incremental Incremental Release Plan Release • 1-6 Iterations • Released internally or externally to end users Product/Project Charter Product/Project Product or Project Plan • Perpetually released © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

Agile development’s nested planning cycles User Story or Product Feature • Expressed from business or user perspective Develop • Business value Test • Estimable User Story Feature List: prioritized features (AKA Product Backlog) Design Evaluate Iteration • 1-4 week timebox Iteration Plan Iteration Plan Evaluate Release Plan Incremental Evaluate Incremental Release Plan Release • 1-6 Iterations • Released internally or externally to end users Product/Project Charter Product/Project Product or Project Plan • Perpetually released © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75 75

planning & design increase in detail over time time Feature Feature Design Development detail course fine grain grain Decide how the feature looks and behaves © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 76 76

planning & design increase in detail over time time Feature Iteration Plan Feature Design Development detail course fine grain grain Decide how the feature looks and behaves Determine the features in the iteration and how they coherently hang together © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 76 76

planning & design increase in detail over time time Feature Release Plan Iteration Plan Feature Design Development detail course fine grain grain Decide how the feature looks and behaves Determine the features in the iteration and how they coherently hang together Determine appropriate product features and the specific features in this release © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 76 76

planning & design increase in detail over time time Feature Project Charter Release Plan Iteration Plan Feature Design Development detail course fine grain grain Determine how the software will earn money, Decide how the feature and the user constituents looks and behaves will be served Determine the features in the iteration and how they coherently hang together Determine appropriate product features and the specific features in this release © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 76 76

feature testing and product evaluation each cycle affords course correction time Feature Project Charter Release Plan Iteration Plan Feature Design Development detail course fine grain grain © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 77 77

feature testing and product evaluation each cycle affords course correction time Feature Project Charter Release Plan Iteration Plan Feature Design Development detail course fine grain grain Feature Test Test that the features look and perform as expected © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 77 77

feature testing and product evaluation each cycle affords course correction time Feature Project Charter Release Plan Iteration Plan Feature Design Development detail course fine grain grain Iteration Evaluation Feature Test Test that the features look and perform as expected Evaluate how features work together. Add, remove, or change features in the release © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 77 77

feature testing and product evaluation each cycle affords course correction time Feature Project Charter Release Plan Iteration Plan Feature Design Development detail course fine grain grain Release Iteration Evaluation Evaluation Feature Test Test that the features look and perform as expected Evaluate how features work Evaluate the finished together. Add, remove, or release. Will it be useful change features in the for its target audience? release Will it earn the revenue expected?. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 77 77

feature testing and product evaluation each cycle affords course correction time Feature Project Charter Release Plan Iteration Plan Feature Design Development detail course fine grain grain Product Release Iteration Evaluation Evaluation Evaluation Feature Test Test that the features look and perform as expected Evaluate how features work Evaluate the finished together. Add, remove, or release. Will it be useful change features in the Evaluate the product for its target audience? release direction as a whole. How Will it earn the revenue can the product earn more expected?. revenue? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 77 77

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another design & plan build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Team design & plan build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team design & plan build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team design & Composition plan build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team design & Composition plan Business Analysts build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team design & Composition plan Business Analysts Interaction Designers build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team design & Composition plan Business Analysts Interaction Designers Prototypers build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Business Analysts Interaction Designers Prototypers build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers Prototypers build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers UI development skills & analysis Prototypers skills build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers UI development skills & analysis Prototypers skills Responsibilities build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers UI development skills & analysis Prototypers skills Responsibilities Gather customer input for features to be implemented in later iterations build evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers UI development skills & analysis Prototypers skills Responsibilities Gather customer input for features to be implemented in later iterations build Design next iteration features evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers UI development skills & analysis Prototypers skills Responsibilities Gather customer input for features to be implemented in later iterations build Design next iteration features Be available to answer questions on current iteration development evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers UI development skills & analysis Prototypers skills Responsibilities Gather customer input for features to be implemented in later iterations build Design next iteration features Be available to answer questions on current iteration development Test features implemented in the previous iteration evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers UI development skills & analysis Prototypers skills Responsibilities Responsibilities Gather customer input for features to be implemented in later iterations build Design next iteration features Be available to answer questions on current iteration development Test features implemented in the previous iteration evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers UI development skills & analysis Prototypers skills Responsibilities Responsibilities Gather customer input for Implement features for current features to be implemented iteration in later iterations build Design next iteration features Be available to answer questions on current iteration development Test features implemented in the previous iteration evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another Customer/Product Owner Development team Team Composition design & Composition plan Smaller number of seasoned Business Analysts developers Interaction Designers UI development skills & analysis Prototypers skills Responsibilities Responsibilities Gather customer input for Implement features for current features to be implemented iteration in later iterations build Collaborate with Product Owner Design next iteration features team to acquire details to Be available to answer construct software questions on current iteration development Test features implemented in the previous iteration evaluate © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78 78

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 Product Owner Team Development Team time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • data gathering Product Owner • design for iteration 1 features – high technical requirements, low Team user requirements Development Team time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • data gathering Product Owner • design for iteration 1 features – high technical requirements, low Team user requirements Development Team • development environment setup • architectural “spikes” time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • data gathering Product Owner • design for iteration 1 features – high technical requirements, low Team user requirements fe at u re de si Development Team gn • development implement iteration environment 1 features setup • architectural “spikes” time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • gather user input • data gathering for iteration 3 Product Owner • design for features iteration 1 • design iteration 2 features – high features technical • support iteration 1 requirements, low development Team user requirements fe at u re de si Development Team gn • development implement iteration environment 1 features setup • architectural “spikes” time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • gather user input • data gathering for iteration 3 Product Owner • design for features iteration 1 • design iteration 2 features – high features technical • support iteration 1 requirements, low development Team user requirements current features fe at u re de si Development Team gn • development implement iteration environment 1 features setup • architectural “spikes” time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • gather user input • data gathering for iteration 3 Product Owner • design for features iteration 1 • design iteration 2 features – high features technical • support iteration 1 requirements, low development Team user requirements current features fe es at ur u at re fe de d de si Development Team gn co • development implement iteration environment 1 features setup • architectural “spikes” time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • gather user input • gather user input • data gathering for iteration 3 for iteration 4 Product Owner • design for features features iteration 1 • design iteration 2 • design iteration 3 features – high features features technical • support iteration 1 • support iteration 2 requirements, low development development Team user requirements • validate iteration 1 features current features fe es at ur u at re fe de d de si Development Team gn co • development implement iteration environment 1 features setup • architectural “spikes” time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • gather user input • gather user input • data gathering for iteration 3 for iteration 4 Product Owner • design for features features iteration 1 • design iteration 2 • design iteration 3 features – high features features technical • support iteration 1 • support iteration 2 requirements, low development development Team user requirements • validate iteration 1 features current features fe es fe ug lity + ab at s te at us b i ur ur fo st u at e un in re de d g fe de si in d gn de si Development Team gn co • development implement iteration environment 1 features setup • architectural “spikes” time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • gather user input • gather user input • data gathering for iteration 3 for iteration 4 Product Owner • design for features features iteration 1 • design iteration 2 • design iteration 3 features – high features features technical • support iteration 1 • support iteration 2 requirements, low development development Team user requirements • validate iteration 1 features current features fe es fe ug lity + ab at s te at us b i ur ur fo st u at e un in re de d g fe de si in d gn de si Development Team gn co • development implement iteration implement iteration environment 1 features 2 features setup fix iteration 1 bugs • architectural if any “spikes” time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

Design and Coded Features Pass Back and Forth Between Tracks Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • gather user input • gather user input • gather user input • data gathering for iteration 3 for iteration 4 for iteration 5 Product Owner • design for features features features iteration 1 • design iteration 2 • design iteration 3 • design iteration 4 features – high features features features technical • support iteration 1 • support iteration 2 • support iteration 3 requirements, low development development development Team user requirements • validate iteration 1 • validate iteration 2 features features current features fe es fe ug lity + ab at s te at us b i ur ur fo st u at e un in re de d g fe de si in d gn de si Development Team gn co • development implement iteration implement iteration implement iteration environment 1 features 2 features 3 features setup fix iteration 1 bugs fix iteration 2 bugs if • architectural if any any “spikes” time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 79 79

The customer/product owner team steers development The customer/product owner team must:  Understand layers of dependent decisions that lead to stories in a backlog  Identify stories to meet release level business objectives  Defer decomposing and detailing stories until necessary  Re-prioritize and create new stories to allow business objectives to be met within time and budget constraints  Business objectives and user objectives are targets – user stories are the tools that help you reach them © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 80 80

Blending User Experience & Business Analysis thinking in the Agile Customer Role 81

Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton 81

Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton ThoughtWorks jpatton@acm.org 81

Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton ThoughtWorks jpatton@acm.org AgileProductDesign.com 81

Agile Chennai Keynote by Jeff Patton

0 comments

Notes on slide 1

3 Favorites