Visual Programming SFT 5030 Bernd Meyer [email protected] Ph: 9905 2240 See .
Tactical Product Ownership day 1: product scope and planning Jeff Patton AgileProductDesign.com...
-
Upload
isaiah-lane -
Category
Documents
-
view
213 -
download
1
Transcript of Tactical Product Ownership day 1: product scope and planning Jeff Patton AgileProductDesign.com...
Tactical Product
Ownershipday 1: product
scope and planning
Jeff PattonAgileProductDesign.com
© 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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 6
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 8
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 9
Prioritizing goals and eliminating low priority goals has cascading effects on project scope
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 10
Prioritize your goals before you prioritize your user story backlog
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 11
We learned techniques to model each layer of the problem context
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 12
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
publishing Review historic
events
I need to: Maintain event
information Manage post-event
publishing Review historic
events Maintain participant
profiles Schedule content
events Administrate surveys Manage content Manage community
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 14
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 15
idea
incremental release strategy
Solutions design 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
time
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 16
idea
incremental release strategy
Solutions design 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
time
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 17
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 18
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 20
The product owner plans the product in layers
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 21
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 22
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 23
The Planning Onion can grow to include product portfolios and business strategy
Product or Project
Release
Sprint
Story
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 23
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 24
Product or Project
Release
Sprint
Story
The Planning Onion can grow to include product portfolios and business strategy
Product Portfolio
Business Strategy
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 24
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 25
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 30
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 33
In software development, what is a “requirement”?
In small groups, discuss the definition of requirement. Write a working definition for your group.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 34
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.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 35
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 36
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.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 37
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 40
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 41
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 42
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 43
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?
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 44
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
…
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 45
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.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 46
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 47
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 48
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 49
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 50
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 51
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.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 52
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
Jeff PattonAgileProductDesign.com
54
Over the past years, User Stories have evolved to be the preferred way to specify software to build
in an Agile environment
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 55
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 56
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.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 57
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.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 58
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…
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 59
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 61
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 62
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 63
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 65
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 66
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 68
The Simple Scrum Process Model
It’s called “the snowman model”(see the snowman?)
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 69
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 71
The basic anatomy of an Agile iteration
plan perform
evaluate
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 72
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 73
Iteration
An iteration has it’s plan-perform- evaluate cycle
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 73
plan
perform
evaluate
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 74
Iteration
Performing an iteration means discussing, writing code for, and validating user stories
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 74
plan
perform
evaluate
Storydesign
code
validate
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75
Release
Iteration
Releasing software incrementally means building software iteratively
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 75
plan evaluate
Storydesign
code
validate
plan evaluate
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 76
Product/Project
Release
Iteration
Chartering a product or project means determining how to release it incrementally
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 76
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 77
We can flatten these nested cycles to see how they look over time.
product
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 77
release release
iteration
daily story development
cycles
time
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 78
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.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 81
“incrementing” builds a bit at a time
1 2 3
Incrementing often calls for a fully formed idea
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 82
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 83
“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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 84
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
iterationsdesign & development
1 2 3 4
user
task
s to
sup
port
release
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 85
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
iterationsdesign & development
1 2 3 4
user
task
s to
sup
port
release
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 86
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
iterationsdesign & development
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-
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 87
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 88
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
timeuncertainty decreases over time
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
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 89
timeuncertainty decreases over time
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.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 90
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
Jeff PattonAgileProductDesign.com