Agile Chennai Keynote by Jeff Patton

Blending User

Experience & Business

Analysis thinking in the

Agile Customer Role

1

Blending User



Agile Customer Role

Jeff Patton

1

Blending User



Agile Customer Role

Jeff PattonThoughtWorks

[email protected]

1

Blending User



Agile Customer Role


[email protected]

AgileProductDesign.com

1

©Alistair Cockburn2005-6 Slide 3

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 techniqueLearn to shift between techniques

Level 3: fluent ( ri )Shift techniques at any momentPossibly unable to describe the shifts

We will use this progression throughout the course.

2

3

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

© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 4

By “Design” I mean the decisions we make regarding the software solution we choose to build.

4



“The hardest single part of building a software system is deciding precisely what to build.”

-- Fred Brooks In his 1987 essay “No Silver Bullet”

4



“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

4

5

Garrett’s Elements of User Experience Model

describes a series of dependent decisions.

5


Software user experience is built from dependent layers

6


Software user experience is built from dependent layers

Jesse James Garrett’s Elements of User Experience: http://www.jjg.net/elements/

6


The surface layer describes finished visual design aspects

Surface

Skeleton

Structure

Scope

Strategy

7


The surface layer describes finished visual design aspects

Surface

Skeleton

Structure

Scope

Strategy

7


The skeleton describes screen layout and functional compartments in the screen

Surface

Skeleton

Structure

Scope

Strategy

8


The skeleton describes screen layout and functional compartments in the screen

Surface

Skeleton

Structure

Scope

Strategy

8


Structure defines navigation from place to place in the user interface

task panes

modal dialogs

modal wizards

Surface

Skeleton

Structure

Scope

Strategy

9


The “places” in the user interface are built to support user-task-centric scope

user tasks:• enter numbers• enter text• enter formulas• format cells• sort information• filter information• aggregate information• graph data• save data• import data • export data• print • …..

Surface

Skeleton

Structure

Scope

Strategy

10


The “places” in the user interface are built to support user-task-centric scope

user tasks:• enter numbers• enter text• enter formulas• format cells• sort information• filter information• aggregate information• graph data• save data• import data • export data• print • …..

Surface

Skeleton

Structure

Scope

Strategy

10


Business goals drive user constituencies choices and contexts supported to form strategy

business goals:• displace competitive products• motivate sale of other

integrated products• establish file format as default

information sharing format• …user constituencies:• accountant• business planner• housewife• …usage contexts:• office desktop• laptop on airplane• pda in car• …

Surface

Skeleton

Structure

Scope

Strategy

11


Garret’s Elements of UX stack can apply to the user experience of other complex products

12


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


Let’s look at the strategy for a product we all use: the place we live

goals:• live comfortably • eat well• stay clean• be healthy• keep up with Jones’s• …user constituencies:• me• spouse• child• …usage contexts:• suburban neighborhood• near good schools• near shopping• …

Surface

Skeleton

Structure

Scope

Strategy

13


Let’s look at the strategy for a product we all use: the place we live

goals:• live comfortably • eat well• stay clean• be healthy• keep up with Jones’s• …user constituencies:• me• spouse• child• …usage contexts:• suburban neighborhood• near good schools• near shopping• …

Surface

Skeleton

Structure

Scope

Strategy

13


What might I, and my other user constituencies, do to reach our goals?

user tasks:• store food• prepare food• eat food• sleep• bathe• store changes of clothing• stay out of rain• entertain guests• entertain self• …

Surface

Skeleton

Structure

Scope

Strategy

14


What might I, and my other user constituencies, do to reach our goals?

user tasks:• store food• prepare food• eat food• sleep• bathe• store changes of clothing• stay out of rain• entertain guests• entertain self• …

Surface

Skeleton

Structure

Scope

Strategy

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

15


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

15


When designing a particular interactioncontext such as a “kitchen,” I optimize layout and tool choices to support tasks I’ll do there

Surface

Skeleton

Structure

Scope

Strategy

16


When designing a particular interactioncontext such as a “kitchen,” I optimize layout and tool choices to support tasks I’ll do there

Surface

Skeleton

Structure

Scope

Strategy

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

17


“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

17

18

Underneath Garrett’s model is a simple 3

layer model

18


Norman’s simple model for a human in pursuit of a goal

19



19



problem or goal

How I’d like to feel, or what I’d like to achieve

19



problem or goal


take some

action

19



problem or goal


take some

action

the worldinformation and tools

19



problem or goal


take some

action action evaluation did that action deliver that results I

expected?


19



problem or goal


take some


expected?


19



problem or goal


take some


expected?

goal evaluation is my goal met or problem

resolved?


19



problem or goal


take some


expected?


resolved?


19



problem or goal


take some


expected?


resolved?


19


Distilling this down to goals, tasks, and tools

problem or goal



take some


expected?


resolved?

20




take some


expected?


resolved?

goal

20




goal

task

20



goal

task

tool

20


Software contains features that support a number of tasks and a number of goals

goals

tasks

tools

21


software


goals

tasks

tools

21


software


goals

tasks

features

21

22

When we think about quality of use

experience, we need to re-think what we mean

by quality.

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

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?

24


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?

24


Noriaki Kano asks us to consider quality as being composed of objective and subjective elements

25



“Discussions of quality have revolved around the two aspects of subjectivity and objectivity since the time of Aristotle.

25




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

25




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

25


Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters

26



Must-haves

26



Must-haves

The products must have this features for me to be happy

26



Must-haves


One dimensionals

26



Must-haves


One dimensionals

The more of this I get, the better

26



Must-haves


One dimensionals


Delighters

26



Must-haves


One dimensionals


Delighters

I love this element of the product!

26



Must-haves


One dimensionals


Delighters

I love this element of the product!

“This car has many flaws. Buy it anyway. It’s so much fun to drive”

-- from a NY Times review of the Mini Cooper

26

27

When we include user experience design into a holistic design process,

another model of problem analysis and solution definition

becomes useful

27


Design alternates between analyzing the problem context and exploring possible solutions

28



time

28



time

proble

m analy

sis

28



time

proble

m analy

sis

solut

ion de

finitio

n

28



time

business problems & goals analysis

proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

user modeling

proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

user modeling

task analysis (how do users achieve goals today?)

proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

user modeling


task design(how might users better reach goals?)

proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

user modeling



user scenario writing

proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

user modeling




user interface design

proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

user modeling




Incremental release planning


proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

user modeling






proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

28



Often, design starts with a candidate solution in mind.

time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

28



Often, design starts with a candidate solution in mind. Exploring the problem helps validate the solution.

time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

28



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.

time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

28



time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

29



Often, design starts with a candidate solution in mind.

time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

29



Often, design starts with a candidate solution in mind. Exploring the problem helps validate the solution.

time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

29





time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

29





time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

29





time


user research

user modeling






user story writing

proble

m analy

sis

solut

ion de

finitio

n

29

30

Now let’s look at practices that a

customer or product owner team users to move from problem analysis through to solution definition

30


Let’s look at a few of many possible product owner team practices

31



Facilitated collaborative work

31




Modeling business objectives

31





Modeling Users

31





Modeling Users

Modeling workflow as user stories: User Story Mapping

31





Modeling Users


Paper prototyping and usability testing

31





Modeling Users



31





Modeling Users



Planning & road-mapping

31


Collaborative centers around model building

32



[a model is] a description or analogy used to help visualize something (as an

atom) that cannot be directly observed

- Merriam-Webster on-line

32






A goal of a model isn’t completeness or accuracy, but communication

32







For our purposes:

a model is any visual representation of our current understanding of a concept

32







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

32


Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding

33


Representing our ideas as models allows us to detect inconsistencies in our understanding

34


Through discussion and iterative model building we arrive at a stronger shared understanding

35


Using that common understanding we can work together toward shared objectives

36


Low fidelity card models are used to facilitate discussions and build common understanding

37



Common model forms include: Affinity diagrams Chronological models

Decompositions Ad hoc charts

37



Common model forms include: Affinity diagrams Chronological models

Decompositions Ad hoc charts

Mix and match as you see fit

37


Collaborative modeling looks like this

38


Collaborative modeling sessions follow a simple, repeatable structure

39



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

39





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

39


1


2







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

possible

39


1


2










possible

Document & Communicate

39


1


2










possible

Document & Communicate Capture model with photo and/or movie

39


1


2










possible

Document & Communicate Capture model with photo and/or movie Document as necessary

39


1


2










possible

Document & Communicate Capture model with photo and/or movie Document as necessary Post in publicly accessible place

39


1


2 3










possible

Document & Communicate Capture model with photo and/or movie Document as necessary Post in publicly accessible place Display as a poster

39



40




40





40





Modeling Users

40





Modeling Users


40





Modeling Users



40





Modeling Users



40





Modeling Users




40

41

Business objectives describes why we’d choose

to buy or build the software

41


Look for benefit to the buyer or builder of the software

42



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

42




For software built for commercial sale: Generate revenue through sale Improve/expand market share Open new markets

42




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

* Gane & Sarson’s IRACIS model, 1977 42


When asking for business goals look for expressions of business problems or desired outcomes

43



Express goals as business problems or business outcomes

43




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”

43




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

43


Use a Goal Question Metric approach to identify appropriate goal metrics

44



Leverage a simple approach from the GQM methodology

44




1. Identify and prioritize goals

44





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?

44





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

44


Good business objectives help validate prospective solutions

45



A good set of business objectives help us validate the solutions we choose to construct

45



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

45



46




46





46





Modeling Users

46





Modeling Users


46





Modeling Users



46





Modeling Users



46





Modeling Users




46


Common models such as actors, roles, profiles, & personas describe users

47



Actor & Goal Often a job title or the common name

for the type of user in a system

47





User Role Short name describing a user in pursuit

of a goal – users change roles as their goals change

47







User Profile Adding summary information about the

types of users who fill a role or perform as an actor begins a process of “profiling”

47









Persona Choosing specific characteristics of a

person and compiling those into a archetypal description of that person creates a strong design target

On-line Shopper: browse and purchase merchandise on line

Customer Support Rep: aid customers over the phone and on line with issues

47



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

48









48











48













48















48



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…

49





Web Shoppers





49







Web Shoppers





49









Web Shoppers





49











Web Shoppers





49



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.

Steve Powellcompetitive mountain biker

“I’m looking for stuff that’ll help me stay ahead of the pack”

50










50






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.





50














50
















50


software

Software products support a variety of users and their goals.

tasks

features

goals

51


software

Software products support a variety of users and their goals.

tasks

features

goals

51


software

In organizations where users are paid to use the software, user goals are driven by business goals

tasks

features

goals

52


software


tasks

features

goals

52


software


tasks

features

goals

All these goals mean lots of tasks, and lots of potential

features in our software

52


Design imperatives describe good characteristics the software should have based on the user type

53



Inside your user model are clues about the type of user interface and user interface characteristics needed by your user.

53




Document these as design imperatives.

53





Think about: ease of learning retention of learning efficiency of interaction reliability of interaction

53





Think about: ease of learning retention of learning efficiency of interaction reliability of interaction

user satisfaction user convenience necessity for proficiency importance of accuracy

53


A good user model helps us identify functional scope and necessary characteristics of the software

54



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

54



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

54



55




55





55





Modeling Users

55





Modeling Users


55





Modeling Users



55





Modeling Users



55





Modeling Users




55


Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map

56



Draw a left to right axis representing time

56



Draw a left to right axis representing time

time

56



Draw a left to right axis representing timeIdentify high level activities performed by users of the system and place them above the time axis in the order that seams reasonable

time

56




time

Activity 1

56




Within each activity, organize tasks in the order they’re most likely completed. There’s likely variation in how they’re completed – so arrange them in a typical order.

If you had to explain the process to someone, arrange them in the order you’d tell the story.

time

Activity 1

56






Task 1

time

Activity 1

56






Task 1

Task 2

time

Activity 1

56






Task 1

Task 2

Task 3

time

Activity 1

56






Task 1

Task 2

Task 3

Task 4

time

Activity 1

56






Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

56






Fill in task details such as business rules or possible features that satisfy the tasks below each task.

Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

56







Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

Task Detail(Story)

56







Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

Task Detail(Story)

Task Detail(Story)

56







Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

56







Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

56







Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

56







Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

56


A good User Story as used in Scrum and other Agile approaches describes the use of the system

57



The user story form considered “best practice” in Scrum references your user model and user goals.

57




As a [type of user]

I want to [perform some task]

so that I can [achieve some goal]

57




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.

57


In practice user stories may be written to describe user tasks or the tools that support them

software

tasks

features

goals

58


user story


software

tasks

features

goals

58


user story


software

tasks

features

goalsAs a harried shopper

I want to locate a specific CD in the store

More task-centric:

58


user story


software

tasks

features




I want to enter a CD title into the search box and initiate a product search

More task-centric:

More tool-centric:

58


user story


software

tasks

features




I want to enter a CD title into the search box and initiate a product search

More task-centric:

More tool-centric:

start with task-centric user stories early in product

discussion and modeling

fill in feature-centric stories till later

58


Building a workflow model helps facilitate discussion – but requires a bit of space

59


Building a workflow model helps facilitate discussion – but requires a bit of space

59


Workflow or a reasonable sized system can fill a room

60


Workflow or a reasonable sized system can fill a room

60


Discussions in front of workflow models are more productive

61



62




62





62





Modeling Users

62





Modeling Users


62





Modeling Users



62





Modeling Users



62





Modeling Users




62


Build paper prototypes from repositionable components

63


Test paper prototypes to determine if they’re usable

64


Finished prototypes are pieced together from moveable and removable paper components

65


Build navigation maps and storyboards to communicate UI design

66


Build navigation maps and storyboards to communicate UI design

66



67




67





67





Modeling Users

67





Modeling Users


67





Modeling Users



67





Modeling Users



67





Modeling Users




67


Prioritize task details by necessity to help visualize layers of functionality across the business process

Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

68



Draw a vertical axis to represent necessity

Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

68



Draw a vertical axis to represent necessity

Task 1

Task 2

Task 3

Task 4

Task 5

time

Activity 1

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)

Task Detail(Story)ne

cess

ity

68


Identify releases in spans of coherent functionality

time

optio

nalit

y

necessary

lessoptional

moreoptional

activity 1 activity 2 activity 3 activity 4

69



Choose coherent groups of features that consider the span of business functionality and user activities.

time

optio

nalit

y

necessary

lessoptional

moreoptional


69




Support all necessary activities with the first release

time

optio

nalit

y

necessary

lessoptional

moreoptional


69





Improve activity support with subsequent releases

time

optio

nalit

y

necessary

lessoptional

moreoptional


69






time

optio

nalit

y

necessary

lessoptional

moreoptional


first release

69






time

optio

nalit

y

necessary

lessoptional

moreoptional


first release

second release

69






time

optio

nalit

y

necessary

lessoptional

moreoptional


first release

second release

third release

69


Distill your release plan into a roadmap

70



A roadmap serves to clearly communicate release level objectives to stakeholders

70




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

70



EasyPOS Point of Sale Software

Release 1: Replace the cash register

Business: replaces gets rid of old manual cash registers and gets accurate

up the minute sales information across locations

Users: Cashiers get an easier to use cash register that helps them make

less mistakes, correct them when they do, and save time balancing cash

drawers every night.


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

70


“Bucketing” groups of major functionality or areas of task support is sometimes easier than feature by feature prioritization

71

72

Where to do all those practices fit in a typical

Agile lifecycle?

72


The simple Scrum snowman process model

73



73



73



73



73



73

74

But, it’s commonly understood the

snowman is missing a couple balls…

Or, that it takes a taller snowman to model product concerns

74


Agile development’s nested planning cycles

User Story

75



User Story

User Story or Product Feature• Expressed from business or user perspective• Business value• EstimableFeature List: prioritized features (AKA Product Backlog)

75



User Story

Design


75



User Story

Design

Develop


75



User Story

Design

DevelopTest


75



Iteration

User Story

Design

DevelopTest


75



Iteration

User Story

Design

DevelopTest


Iteration• 1-4 week timebox

75



Iteration

User Story

Design

DevelopTest

Plan



75



Iteration

User Story

Design

DevelopTest

Iteration Plan

Plan



75



Iteration

User Story

Design

Develop

Evaluate

Test

Iteration Plan

Plan



75



IncrementalRelease

Iteration

User Story

Design

Develop

Evaluate

Test

Iteration Plan

Plan



75



IncrementalRelease

Iteration

User Story

Design

Develop

Evaluate

Test

Iteration Plan

Plan



Incremental Release• 1-6 Iterations• Released internally or

externally to end users

75



IncrementalRelease

Iteration

User Story

Design

Develop

Evaluate

Test

Iteration Plan

Plan

Plan





75



IncrementalRelease

Iteration

User Story

Design

Develop

Evaluate

Test

Iteration Plan

Plan

Release Plan

Plan





75



IncrementalRelease

Iteration

User Story

Design

Develop

Evaluate

Test

Evaluate

Iteration Plan

Plan

Release Plan

Plan





75



Product/Project

IncrementalRelease

Iteration

User Story

Design

Develop

Evaluate

Test

Evaluate

Iteration Plan

Plan

Release Plan

Plan





75



Product/Project

IncrementalRelease

Iteration

User Story

Design

Develop

Evaluate

Test

Evaluate

Iteration Plan

Plan

Release Plan

Plan





Product or Project• Perpetually released

75



Product/Project

IncrementalRelease

Iteration

User Story

Design

Develop

Evaluate

Test

Evaluate

Iteration Plan

Plan

Release Plan

Plan

Plan






75



Product/Project

IncrementalRelease

Iteration

User Story

Design

Develop

Evaluate

Test

Evaluate

Iteration Plan

Plan

Release Plan

Plan

Product/Project Charter

Plan






75



Product/Project

IncrementalRelease

Evaluate

Iteration

User Story

Design

Develop

Evaluate

Test

Evaluate

Iteration Plan

Plan

Release Plan

Plan

Product/Project Charter

Plan






75


planning & design increase in detail over time

FeatureDevelopment

time

detailcoursegrain

finegrain

76



FeatureDevelopment

time

detailcoursegrain

finegrain

Feature Design

Decide how the feature looks and behaves

76



FeatureDevelopment

time

detailcoursegrain

finegrain

Feature Design


Iteration Plan

Determine the features in the iteration and how they coherently hang together

76



FeatureDevelopment

time

detailcoursegrain

finegrain

Feature Design


Iteration Plan


Release Plan

Determine appropriate product features and the specific features in this release

76



FeatureDevelopment

time

detailcoursegrain

finegrain

Feature Design


Iteration Plan


Release Plan

Determine appropriate product features and the specific features in this release

Project Charter

Determine how the software will earn money, and the user constituents will be served

76


feature testing and product evaluationeach cycle affords course correction

FeatureDevelopment

time

detailcoursegrain

finegrain

Feature DesignIteration PlanRelease PlanProject Charter

77



FeatureDevelopment

detailcoursegrain

finegrain

Feature DesignIteration PlanRelease PlanProject Charter

time

77



FeatureDevelopment

detailcoursegrain

finegrain

Feature Design

Test that the features look and perform as expected

Iteration PlanRelease PlanProject Charter

Feature Test

time

77



FeatureDevelopment

detailcoursegrain

finegrain

Feature Design


Iteration Plan

Evaluate how features work together. Add, remove, or change features in the release

Release PlanProject Charter

Feature TestIterationEvaluation

time

77



FeatureDevelopment

detailcoursegrain

finegrain

Feature Design


Iteration Plan


Release Plan

Evaluate the finished release. Will it be useful for its target audience? Will it earn the revenue expected?.

Project Charter


ReleaseEvaluation

time

77



FeatureDevelopment

detailcoursegrain

finegrain

Feature Design


Iteration Plan


Release Plan

Evaluate the finished release. Will it be useful for its target audience? Will it earn the revenue expected?.

Project Charter

Evaluate the product direction as a whole. How can the product earn more revenue?


ReleaseEvaluation

ProductEvaluation

time

77


Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another

design & plan

evaluate

build

78



design & plan

evaluate

build

Customer/Product Owner Team

78



design & plan

evaluate

build


Development team

78



design & plan

evaluate

build


Composition

Development team

78



design & plan

evaluate

build


CompositionBusiness Analysts

Development team

78



design & plan

evaluate

build



Interaction Designers

Development team

78



design & plan

evaluate

build



Interaction DesignersPrototypers

Development team

78



design & plan

evaluate

build




Development teamComposition

78



design & plan

evaluate

build




Development teamCompositionSmaller number of seasoned

developers

78



design & plan

evaluate

build





developers

UI development skills & analysis skills

78



design & plan

evaluate

build




Responsibilities


developers


78



design & plan

evaluate

build




ResponsibilitiesGather customer input for

features to be implemented

in later iterations


developers


78



design & plan

evaluate

build






in later iterationsDesign next iteration features


developers


78



design & plan

evaluate

build







Be available to answer questions on current iteration development


developers


78



design & plan

evaluate

build








Test features implemented in the previous iteration


developers


78



design & plan

evaluate

build










developers


Responsibilities

78



design & plan

evaluate

build










developers


ResponsibilitiesImplement features for current

iteration

78



design & plan

evaluate

build










developers


ResponsibilitiesImplement features for current

iteration

Collaborate with Product Owner team to acquire details to construct software

78


Design and Coded Features Pass Back and Forth Between Tracks

79


Prod

uct

Ow

ner

Team

Design and Coded Features Pass Back and Forth Between Tracks

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te

amDesign and Coded Features Pass Back and Forth Between Tracks

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te


time

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te


Iteration 0 Iteration 1 Iteration 2 Iteration 3

time

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te


• planning• data gathering• design for

iteration 1 features – high technical requirements, low user requirements


time

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te




• development environment setup

• architectural “spikes”


time

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te


implement iteration 1 features






feature designtime

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te



• gather user input for iteration 3 features

• design iteration 2 features

• support iteration 1 development






feature designtime

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te











feature designtime

current features

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te











feature design code

d fea

ture

s

time

current features

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te









• validate iteration 1 features






feature design code

d fea

ture

s

time

current features

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te















feature design code

d fea

ture

s

time

feature design

+ bugs found in

usability testing

current features

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te






implement iteration 2 featuresfix iteration 1 bugs if any










feature design code

d fea

ture

s

time

feature design

+ bugs found in

usability testing

current features

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te
















feature design code

d fea

ture

s

time

feature design

+ bugs found in

usability testing

current features

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te





















feature design code

d fea

ture

s

time

feature design

+ bugs found in

usability testing

current features

79


Prod

uct

Ow

ner

Team

Dev

elop

men

t Te





















feature design code

d fea

ture

s

time

feature design

+ bugs found in

usability testing

current features

79


The customer/product owner team steers development

80


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

80

Blending User



Agile Customer Role

81

Blending User



Agile Customer Role

Jeff Patton

81

Blending User



Agile Customer Role


[email protected]

81

Blending User



Agile Customer Role


[email protected]

AgileProductDesign.com

81