Through the looking glass

Through the Looking Glass
Agile Product Management & Planning Methods

...or its much easier to steer a moving car
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.

iterative & incremental
development is the norm


First description of
Iterative Development
(1968) Brian Randell
& F.W. Zurcher

“The basic approach
recognizes the futility of
separating design,
evaluation, and
documentation
processes in software-
system design”

Iterative & incremental development has a rich
history since the 1950s

•1950s - X-15 Hypersonic jet was a milestone 1950s
project applying IID
•1960s - Project Mercury, the ﬁrst human spaceﬂight
program in the US
•1972 - IBM FSD (Federal Systems Division) working on
1 million+ lines of code for US Trident command system
•1977 - FSD incorporated the Trident IID approach with
over 2500 engineers as an alternative to waterfall


decoding the impact of
cost of change


Assembly Line Manufacturing
has a high cost of change

http://www.archives.gov.on.ca/english/on-line-exhibits/d-day/big/big_03_airline_assembly.aspx
Archives of Ontario, Reference Code: C 190-5-0-0-21


Inclusive thinking
• In software development high
cost of change leads to inclusive
thinking

• Any and every idea has to be
captured in the ﬁrst version of a
requirements speciﬁcation

• Creates waste - bloated
documents, unwanted features
and entitlement thinking


Software Development has
commoditized cost of change
Object-oriented
languages
jquery

Ruby on Rails

Coffeescript
Continuous Delivery


Changing paradigms
• If change is cheap, requirements
can change continuously

• We can evolve our thinking as
we learn more about the product
we are building

• High-level, broad requirements
(why we need something) with
focus (how will we know when
we’re done)


Cost of Hypothesized
Change Requirements

Evolving
Requirements

Validated
Requirements Capture all
possible needs

Emerging needs
as development
progresses
Lean Startup
experiments

Detail of
Requirements

portfolio planning in an
uncertain world


Five Levels of Planning

Exec Management,
Vision
Planning
Annually
Stakeholders

Product Owners, UX,
Roadmap
Planning Bi-‐annually
Engineering, Architecture

Product Owners, UX,
Release
Planning
Vision
Planning Quarterly Architecture, Analytics, SEO,
Production
Roadmap
Planning
Itera3on

Release
Planning Product Owners, Delivery
Planning Bi-‐weekly
Team
Daily

Planning Product Owners, Delivery
Daily
Team


The
Requirements
Pyramid
Star3ng
from
the
objec3ve
for
the
consumer
experience,

an
experience
ini3a3ve
is
deﬁned
in

terms
of
requirements,
epics,
and
user
stories.

Sizing
guideline:
A
single
team
should
be
able
to
deliver
5-‐10:
Vision -‐
Requirements
within
a
year
-‐
Epics
within
a
quarter
-‐
User
Stories
within
a
sprint

Ini$a$ves Deﬁned
by
a
one-‐page

project
descrip3on

Requirement
Increasing

detail

Epic Expressed
as
User

Stories
and
sized
by
the

teams
User
Story


Where do User Stories come from?
Ini$a$ves

• Describes a large program over years. Corresponds to the Project Chartering level of traditional
PMI-type project management
Requirements

• Describes the needs of the product - the problem
we want to solve – in terms of the
consumers’ experience
Epics
• Requirements are transformed into multiple Epics, were each Epic is a proposal to partially
satisfy the Requirement
• Epics are broadly capability speciﬁc, though some cross-capability dependencies will be
unavoidable
User
Stories
• Epics are in turn transformed into multiple User Stories, were each User Story is a proposal to
partially satisfy the Epic


Delivery Process

• Nested hierarchy of increasing detail, starting with high-
level vision to high-detail user stories
• Four levels of granularity fully describe the product, from
vision to individual user stories
• Features are described just-in-time, in just enough detail,
to be estimated and delivered
• Prioritization and de-scoping decisions can be made at all
levels, at any time


Vision Roadmap Release Plan Iterations Release
Initiatives Requirements Features/Epics User Stories Code

Appropriate
documenta3on
at

each
level
captures
key

informa3on

Ini3a3ve
SMART
Epic
User

Vision Requirements Stories Stories

Characteristics of Each Level

• Each level of product planning has a different:
–Cadence: the rhythm at which the content is reviewed
and commitments are made
–Ownership: product ownership cascades through the
team allowing quick and appropriate decisions
–Documenta$on: a speciﬁc form of information capture is
used at each level, driving collaboration
–Tracking: transparency is essential for teams to be
prepared and adapt to new information

Vision Roadmap Release Plan Iterations Release
Initiatives Requirements Features/Epics User Stories Code

6+
months 1-‐3
months <1
month <2
weeks CADENCE

OWNERSHIP

Ini$a$ve
SMART
Epic
User

DOCUMENTATION
Vision Requirements Stories Stories


Change is rapidly
disappearing as a material
cost in software delivery


• Elicit a guiding vision and
requirements from stakeholders
• Emerge further details based on
experience with delivered work
• Validate ideas before investing
in them using Lean Startup
• Use empirical data to manage
portfolio roadmap


Further Reading
• Slideshare: http://www.slideshare.net/davesharrock

• Iterative and Incremental Development: A Brief History, IEEE Computer Society,
by Craig Larman & Victor R. Basili

• The Lean Startup by Eric Ries

• Running Lean: Iterate from Plan A to a Plan That Works by Ash Maurya

• Software by Numbers: Low-Risk, High-Return Development by Mark Denne &
Jane Cleland-Huang


thank you

dave.sharrock@agile42.com
skype: dave.sharrock
follow us on: @agile42
follow me on: @davesharrock

Through the looking glass

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Through the looking glass

Similar to Through the looking glass (20)

More from Dave Sharrock

More from Dave Sharrock (20)

Recently uploaded

Recently uploaded (20)

Through the looking glass