tactical product ownership day 1: product scope and planning jeff patton agileproductdesign.com...

Tactical Product

Ownershipday 1: product

scope and planning

Jeff PattonAgileProductDesign.com

[email protected]

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

The ground we’ve crossed so far:

Collaborative project inception Identifying strong business goals and using them to

drive decisions about users and use.

Envisioning solutions Using user scenarios, paper prototypes, and

iterative evaluation to identify solutions

Collaboration Working with people to elicit information, facilitate

groups, and collaborate effectively.

3

Our goals for the next two days:

Move from conceptual analysis and scope definition to detailed Agile project work

1. Plan a project composed of multiple thinned releases

2. Split larger planning grade stories into sprint level stories

3. Develop acceptance criteria for those stories

4. Properly exploit iteration in Agile development

4

candle dipping

5

Starting with where we’ve been


softwaresoftware

The software we choose to build fits in a “product shaped hole”

software

use (tasks)

users (goals)

organization(goals)

problem context

software solution

The quality of the product is a function of how well it fits inside it’s problem

context.

7

The software we choose to build fits in a “product shaped hole”

software

use (activities & tasks)

users (goals)

organization(goals)

problem context

software solution

The quality of the product is a function of how well it fits inside it’s problem

context.

customer(value proposition)

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


Goals, users and activities supported by software form a dependent hierarchy

Business Goals

(Increase Revenue, Reduce Costs)

User Constituencies

(The people that will use some

solution to meet business goals)

Activities & Tasks

performed by users using software


Prioritizing goals and eliminating low priority goals has cascading effects on project scope

Business Goals


User Constituencies



Activities & Tasks



Prioritize your goals before you prioritize your user story backlog

Business Goals


User Constituencies



Activities & Tasks



We learned techniques to model each layer of the problem context

Business Goals


User Constituencies



Activities & Tasks



We learned techniques to model each layer of the problem context

1.Identify goals that motivate creation of the product2. Use “why questions” to find goals that track back to

increasing revenue or reducing cost3. Use the question “how would we know if we were making

progress towards this goal” to identify metrics

1.Identify types of users as roles relative to the business, a process, or the solution

2.Identify characteristics of these groups relevant to the solution

3.Build a persona leveraging those details4. Identify feature ideas and product design

imperatives

1.Identify large collections of related tasks as activities2.Identify tasks within those activities3.Record details of tasks4.Arrange activities and tasks into a typical workflow

order

OVERVIEW OF EXTRANET EVENT PAGES Extranet Event Goals, Users and Activities

Create transparency into community to enable

roundtable participants to engage with each other

effectively across and within communities of interest,

geographic communities, and events.

Lay the architectural foundation for McKinsey

Connect Platform

C- Level Participants

C-LevelAssistants

Event Coordinator

Event Planner Editor

“I want to network

with colleagues that

can help me with

goals and problems

I’m facing in my

company”

“My boss spends

most of his time in

meetings and

traveling. It’s up to

me to keep him

informed.””

“I want to keep my

community of CSOs

active and engaged.”

“There are lots of

important details to

take care of for a

workshop to go

smoothly.”

“McKinsey’s

reputation, and the

quality of interaction

we have with CSOs

relies on relevant

high quality content.”

GO

ALS

US

ER

CO

NS

TIT

UE

NT

SU

SE

R A

CT

IVIT

IES I want to:

View upcoming events

Respond to invitations

View historic events Modify my profile Find knowledge Find peers Post content, pose

questions Look for a job

As a proxy I will: View upcoming

events Respond to

invitations

I need to: Planning events Prepare for events Communicate event

details Maintain event

information Conduct event Manage post-event

publishing Review historic

events Maintain participant

profiles

I need to: Planning events Prepare for events Maintain event

information Conduct events Manage post-event


events

I need to: Maintain event

information Manage post-event


events Maintain participant

profiles Schedule content

events Administrate surveys Manage content Manage community


Solution inception alternates between analyzing the problem context and exploring possible solutions

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.

business problems & goals analysis

user research

user modeling

activity & task analysis (how do users achieve goals today?)

activity and task design(how might users better reach goals?)

user scenario writing

Incremental release planning

user interface design

user story writing

idea

incremental release strategy

time


idea


Solutions design alternates between analyzing the problem context and exploring possible solutions



user research

user modeling






user story writing

time


How are these concept sitting today?

Consider the hierarchy of: business goal user types usage as activities and tasks software specification

Is the hierarchy of concerns understandable in the project you’re working on?

Have you been able to practice approaches to:

elicitation facilitation collaboration


Build up a “one-pager” for new KNOW features

Demonstration: Interviewing Zanub, capture

information for a one-page overview of the current KNOW additions

Practice In small groups, 1 or 2 interviewers,

one interviewee, build quick “one-pagers” for existing McKinsey projects

19

Incremental release planning, second dip


The product owner plans the product in layers


The product owner plans the product in layers

Product or Project

What business objectives will the product fulfill?

Product Charter

Elevator Pitch

ReleaseHow can we release value incrementally?

What subset of business objectives will each release achieve?

What user constituencies will the release serve?

What general capabilities (big stories) will the release offer?

Release plan

SprintWhat specifically will

we build? (user stories)

How will this sprint move us toward

release objectives?

Sprint Plan

Story (Backlog Item)What user or stakeholder need will the story serve?

How will it specifically look and behave?

How will I determine if it’s completed?

Story Details

Acceptance Tests


The Planning Onion can grow to include product portfolios and business strategy

Product or Project

What business objectives will the product fulfill?

Product Charter

Elevator Pitch

ReleaseHow can we release value incrementally?

What subset of business objectives will each release achieve?

What user constituencies will the release serve?

What general capabilities (big stories) will the release offer?

Release plan

SprintWhat specifically will

we build? (user stories)

How will this sprint move us toward

release objectives?

Sprint Plan

Story (Backlog Item)What user or stakeholder need will the story serve?

How will it specifically look and behave?

How will I determine if it’s completed?

Story Details

Acceptance Tests

Product or Project

Release

Sprint

Story



Product or Project

Release

Sprint

Story



Product or Project

Release

Sprint

Story


Product Portfolio

Business Strategy



The software we choose to build is a consequence of smaller upstream choices

Choices in business goals, users, and use have big

consequences to software scope

Use (Activities &

Tasks)

Software to build(Specified as User Stories)

User Constituencies

Business Goals


Segmenting scope into incremental releases also segments use, user goals, and business goals

Use (Activities &

Tasks)

Software to build(Specified as User Stories)

User Constituencies

Business Goals

1 2 3

Work top down (goals to scope) or bottom up (scope back to goals), but

always work to ensure you’re delivering scope that delivers on business and user

goals

27

We’ll plan using a story map that describes use in activities, tasks,

and task details – but first we need to build the story map


By arranging activity and task cards spatially, we can tell bigger stories

Tell a big story of the KNOW release by starting with the user activities the relevant to this release

Arrange activities left to right in the order you’d explain them to someone when asked the question: “What do people do with this system?

time


By arranging activity and task cards spatially, we can tell bigger stories

Add task-centric stories in under each activity in chronological order left to right.

If you were to explain to someone what a person typically does in this activity, arrange tasks in the order you’d tell the story

time


As details emerge in conversation, trap them under there associated task cards

Record details so their not lost, and so those that you’re working with know that you’re listening

Consider tucking them under tasks cards to “hide them” from the discussion

time


Build a story map from the KNOW product backlog

Leverage Zanub as a KNOW subject matter expert

time

User Activity (big thing)

User Task (simple achievable action in the system)

Detail (detail of that task)

32

Moving forward with a subject I’ve been avoiding:

Requirements


In software development, what is a “requirement”?

In small groups, discuss the definition of requirement. Write a working definition for your group.


Consider our hierarchy and requirements

Business goals result in business level requirements to reach specific business objectives, solve business problems, or be in regulatory compliance.

User models help us identify what users desire to be successful. Looking at users’ activities and tasks helps us identify functional requirements. Looking at user characteristics helps us identify design imperatives – or non-functional requirements related to use

Activity & Task models help us identify details of usage and begin to make decisions about which uses to support or not support. (detailed functional requirements and scope boundaries) Discussions of use often reveal business rules or usage constraints.


For the purpose of our conversation, consider a “requirement” to be a decision

“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


Why do “requirements” change?

In small groups, discuss the reasons that requirements change.

Make a list of reasons and prioritize them – most likely to change highest.


Building architects alternate between the words requirements and design constraints

Consider these sources of architectural design constraints. Constraints may come from:

Users (their characteristics, goals, and usage) Clients (business and their goals) Outside regulatory agencies Engineering (tools, materials, and building practice)

Constraints can be relaxed or changed. Consider the sources of constraints above. Order thes sources from easiest to change to hardest.

Why would it be easier to change constraints from one source over another?

38

Requirements are malleable

As a product owner you’ll make decisions that change

requirements for the team creating the software

Make decisions that preserve the goals of the project within the

projects timebox

39

Now that I’ve hopefully given you a broader definition of

requirement, I’d like to give you a new broader definition of

quality


Considering feature quality characteristics

Given a user task like “swing from tree,” a variety of feature design solutions exist to support the task which vary widelyManaging feature details appropriately is an important part of managing scopeWhen initially planning the delivery of a set of features, the characteristics of each feature must be consideredMuch of detail scope management happens during design and development

Close to the time the functionality is needed In the context of other features, time

constraints, development capacity, and other projects in the portfolio

low cost moderate cost high cost


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


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!

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

-- from a NY Times review of the Mini Cooper


Separate objective quality from subjective quality

Objective quality refers to the visible measurable, and easily validated characteristics of the product usually in relation to the products’ specifications.

Does the product perform bug free as specified? Expect objective quality to be high.

Subjective quality refers to the specification or product design choices made that affect the product users’ perception of quality

Is the product simple to use? Is the product efficient to use? Do I like using the product?


The Car MetaphorConsider the job of building a car incrementally.

Omitting necessary features may make the product useless – this makes prioritization difficult.

We need to perform every user task these features are built to support.

Scaling all features to highest quality level increases cost

To control the cost of the car, we scale the features back to economical quality levels

Feature List

Engine Transmission

Tires Suspension

Brakes Steering wheel

Driver’s seat

…


The characteristics of a feature used for managing scope

Necessity: what minimal characteristics are necessary for this feature? For our car a minimal engine and transmission are necessary – along with a

number of other features.

Flexibility: what would make this feature more useful in more situations? For our car, optional all-wheel-drive would make it more useful for me to take

on camping trips. A hatchback might make it easier for me to load bigger stuff into the back.

Safety: what would make this feature safer for me to use? For our car adding seat belts and making the brakes anti-locking would make

the car safer.

Comfort, Luxury, and Performance: what would make this feature more desirable to use?

I’d really like automatic climate control, the seats to be leather, and a bigger V6 engine.


When Planning a Software Release, Thin Software Features Using the Same Guidelines

When planning a software release, start with tasks that users must perform

Add in flexibility tasks as necessary

Add in safety tasks as necessary

Add in comfort, luxury, and performance as it benefits return on software investment


Use Feature Thinning Guidelines to Reduce the Size of a Release

The topmost row of the span could be the first, smallest release

By minimizing a release we can realize financial and risk reduction benefits earlier

The top span represents the minimal tasks users need to accomplish to reach their goals. How can we split these “high level stories” into smallest parts?

Can the feature(s) to support a task have reduced safety? Can the feature(s) to reduce a task have less comfort, performance, and

luxury? Are there optional tasks that can be supported in a subsequent release? For necessary tasks, look at the steps – or subtasks that make up the

task. Can any of those steps be made optional? Move cards around the model, or split cards into multiple cards to defer

task support, or specific feature characteristics till later releases


Splitting tasks in Story Maps

Consider tasks more optional

Split tasks into optional parts

time

optio

nalit

y

necessary

lessoptional

moreoptional

activity 1 activity 2 activity 3 activity 4


Translate the KNOW model into an incremental release plan

1. Create horizontal swim-lanes to group features into releases

2. Arrange features vertically by necessity in the system

3. Split tasks into parts that can be deferred till later releases

op

tionalit

y

necessary

lessoptional

moreoptional


Turn the segmented scope into a milestone plan

For each release candidate give the release:1. a name2. describe how the business benefits on delivery of the release3. indicate which users are affected, and how they benefit for each

release

time

op

tionalit

y

necessary

lessoptional

moreoptional


Effective planning takes into account users and use along with business goals

The planning approach we’ve practiced leverages our story map to prioritize in the context of all system activities and tasks.

Road-mapping builds back up to user and business goals by answering the question for each release:

what value does the business get? what value do users get?

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.

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.


Effective planning takes into account users and use along with business goals

Business Goals

Users

Activities & key tasks

What users get (yellow)

What business

gets (orange)

task in scope(purple)

Milestone

Tactical Product

Ownershipday 2: user stories,

iterative, and incremental development


[email protected]

54

Over the past years, User Stories have evolved to be the preferred way to specify software to build

in an Agile environment


Agile development delivers incrementally by breaking up functionality into small pieces

Small pieces can be referred to as items in a backlog of work (backlog items) – or more commonly today as user stories

User stories are often written on index cards

* Kent Beck coined the term user stories in

Extreme Programming Explained 1st Edition, 1999


Agile development reduced batch size by breaking up functionality into smaller pieces

A good story describes what the system should do from the users perspective.


Agile development reduced batch size by breaking up functionality into smaller pieces

A good story describes what the system should do from the users perspective.

It usually has: a title a concise problem statement:

As a [type of user] I want to [perform some

task] so that [I can reach some

goal or get some benefit] other relevant notes or sketches

We can inherit the user type and the basic goal

from the activity the story supports.

Try telling stories in this form from your story

map.


Stories support users and use to achieve business goals

softwaresoftwaresoftware

use (tasks)

users (goals)

organization(goals)

problem context

software solution

We’ve described our problem and solution space with this simple model…


Stories support users and use to achieve business goals

We model business goals, users, user activities and user tasks to understand the problem context.

We write stories to implement software solutions that allows users to reach those business goals.

Business Goal

User

Activity Activity

Task Task Task

User

Task Task Task

story

story

story

story

story

story

story

story

story

story


Evaluate the quality of stories using INVEST

The INVEST test allows us to evaluate our stories:

Independent Negotiable Valuable Estimable Small Testable

* Bill Wake coined the

INVEST approach to

testing story quality


Large stories may be split by using story thinning guidelines

Necessity: what elements of the story are necessary for users to reach their goal, and for business to receive some value?

Flexibility: what elements of the story afford the user alternative ways to do things or more options?

Safety: what elements of the story make things safer for the user or the protect the business from user errors or malicious use?

Comfort, performance, & luxury: what elements make the story nicer to use, faster to use, better to look at, or more delightful?

Discuss story splitting along these “perforation points”

Split stories only when it offers sufficient benefit, or doesn’t inject unnecessary risk to the product


Split larger task-centric stories into smaller sprint level stories

Discuss these two large KNOW stories split them into smaller sized stories that follow INVEST guidelines use story thinning guidelines to find “perforation points” to help

split

Note, that the stories will need more discussion before they can be split

As a document-reader I want to view documents I need to rate so that I can easily rate documents I’ve downloaded to be a good KNOW citizen, and stop KNOW from nagging me

As a document readerI want to rate a documentso that I can be a good KNOW citizen, stop KNOW from nagging me, and share my knowledge with others.

64

To prepare a story for a sprint, we need to describe

it’s acceptance criteria


A user story goes through a simple lifecycle to grow to become more like “requirements”

A story goes through a simple elaboration cycle of:

card: write the initial story text on the card

conversation: discuss the details with developers, analysts, and testers

confirmation: record the acceptance tests that will allow us to know when the story is complete

* Ron Jeffries coined the 3

C’s in Extreme

Programming Installed


For the sprint level stories you’ve written, have a conversation with developers to write acceptance

Divide into groups of three One person take on the role of developer. Another take on the role of tester, Another take on the role of business analyst.

Discuss the story answering the question:

“How will we determine this story is done?"

Write a list of the things you’ll check to assess “doneness.”

Try using the template: given [precondition]when [user performs some action]then [some result can be observed]

67

Sprint stories are use to build software driving towards release

goals


The Simple Scrum Process Model

It’s called “the snowman model”(see the snowman?)


What does potentially shippable really mean?

70

These day’s we don’t usually plan to release the outcome of single

sprint

So let’s look at Agile time-boxed development a bit differently


The basic anatomy of an Agile iteration

plan perform

evaluate


The basic anatomy of an Agile iteration

plan perform

evaluate

Sprint Planning Meeting

Sprint PlanUser Stories

Development Task Creation

Estimation

Development supported by:

• automated unit tests

• automated acceptance tests

Product DemonstrationCreation of Additional User StoriesMeasurement of Team Velocity Team Retrospective

An Agile iteration is generally 1-4 weeks, or 1 calendar month

objective: plan, create, and validate deliverable functionality


Iteration

An iteration has it’s plan-perform- evaluate cycle


plan

perform

evaluate


Iteration

Performing an iteration means discussing, writing code for, and validating user stories


plan

perform

evaluate

Storydesign

code

validate


Release

Iteration

Releasing software incrementally means building software iteratively


plan evaluate

Storydesign

code

validate

plan evaluate


Product/Project

Release

Iteration

Chartering a product or project means determining how to release it incrementally


plan evaluate

Storydesign

code

validate

plan evaluate

planevaluate

Notice the layers of planning and evaluation

All this planning and evaluation lends lots of opportunity for course correction

Notice how planning and evaluation moves from course grain to fine grain, and from abstract to detailed

abstract, course grained, and high level

precise, fine grained, detailed


We can flatten these nested cycles to see how they look over time.

product


release release

iteration

daily story development

cycles

time


The “definition of done” varies at each cycle

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

Product/Project

Release

Iterationplan evaluate

Storydesign

code

validate

plan evaluate

planevaluate

abstract, course grained, and high level

precise, fine grained, detailed

What is “done” for a story?

What is “done” for a sprint?

What is “done” for a release?

What is “done” for a product?

For each level of done consider: what does done mean? specifically what activities will we do to test for done-

ness?

79

Iterating and incrementing are two different strategies,

You’ll need to leverage both.

80

Jeff, tell Roger’s story here.


“incrementing” builds a bit at a time

1 2 3

Incrementing often calls for a fully formed idea


once development starts, a common failure mode of agile development is to incrementally design and build each feature

at the end of a release timebox, all features supporting user tasks are not implemented

the release isn’t useful to end users

end to end functionality may never have been validated: from a functional, architectural, or usability perspective

this seems like the obvious approach – it’s easiest – but it’s risky – unless you know exactly what you’re going to build and exactly how long it’ll take

iterationsdesign & development

1 2 3 4

user

task

s to

sup

port

release


“iterating” builds a rough version, then slowly builds up quality as we validate requirements

1 2 3

Iterating allows you to move from vague idea to realization


use feature thinning guidelines to grow features iteratively

each feature you design has some measure of necessity, flexibility, safety, comfort, performance, and luxury

start by making sure that each feature is designed and implemented to support necessary, or essential use

after sufficiently completing necessities, continue by adding flexibility and safety

conclude by adding comfort, performance, and luxury to the features that can most benefit


1 2 3 4

user

task

s to

sup

port

release


this strategy has us designing each feature many times over growing and changing the software as we learn from each iteration’s design and development

the resulting release has support for all users’ tasks up to a usable level

complete workflow was visible earlier in the release: this allows for functional, architectural, and preliminary usability evaluation

there’s never enough time to implement all the flexibility, safety, comfort, performance and luxury you’d hoped… strive for sufficiency

this is hard work

you’ll design features over many times, but we’ve significantly reduced risk


1 2 3 4

user

task

s to

sup

port

release


Make quality improvement visible by managing the “gpa” of your release

Grade the quality of release level stories as your release progresses.

Don’t aim for all iteration level stories complete – aim for sufficient release quality


1 2 3 4

user

task

s to

sup

port

release

D D D D D I IB- C C- D D D DA- B B- B B B B-A- A B A A- A- B-


The closer we get to implementing features, the more we know

Barry Boehm first described the cone of uncertainty applying it to estimation accuracy over time

Steve McConnell applied the same principle to certainty of product requirements

Defer specific feature decisions to the “latest responsible moment” as described in Poppendiek & Poppendiek’s Lean Software Development

timeuncertainty decreases over time

cone of uncertainty source: Barry Boehm (estimation), elaborated by Steve McConnell (requirements)

unce

rtai

nty


Divide release design & development into “trimesters”

Build a simple system span of necessary features first

Add flexibility and safety next

Finish with comfort, performance, and luxury

Reserve time in the remaining third for unforeseen additions and adaptations


cone of uncertainty source: Barry Boehm (estimation), elaborated by Steve McConnell (requirements)

unce

rtai

nty

NecessityFlexibility and

Safety

Comfort, Performance, Luxury, and unforeseen

additions and adaptations



unce

rtai

nty

NecessityFlexibility and

Safety

Comfort, Performance, Luxury, and unforeseen

additions and adaptations

This product thickening strategy slowly brings the product into focus

Just as an artist envisions an entire painting by starting with a sketch or an under-painting and slowly building up detail, apply the same strategy to “thicken” the product from simple necessities through to full featured product.


What strategies do you use for iteration?

Possible strategies include: Iterating in low fidelity UI prototypes before

implementing stories Saving sprints at the end of the release for

“feedback” Architectural “spikes” to prototype architectural

concepts before committing to them

What else?

91

Revisiting our goals:

Move from conceptual analysis and scope definition to detailed Agile project work

1.Plan a project composed of multiple thinned releases

2. Split larger planning grade stories into sprint level stories

3. Develop acceptance criteria for those stories

4. Properly exploit iteration in Agile development

Tactical Product

Ownershipday 2: iterative and

incremental development


[email protected]

tactical product ownership day 1: product scope and planning jeff patton agileproductdesign.com...

Documents

software slide

prioritizing goals

strong business goals

problem context business

project scope business

low priority goals

planning jeff patton

event details