5 Levels of Agile Planning Explained Simply

Delivering value early
and often, giving
ourselves the best
opportunity to beat the
competition to market,
realize revenue and
discover insights that
we can use to help us
improve

5 levels of Agile Planning

How to Organize a Children's Party
If you are having difficulty viewing this video download QuickTime using this link:
http://www.apple.com/quicktime/download/

Then install QuickTime and try the link again.


 Chaotic
Enterprise/Organization
 Ordered
 Complex


Roadmap to “being” agile
• Delivery of commercial or operational value early and
often, giving ourselves the best opportunity to beat the Agile
competition to market, realize revenue and discover Coaching &
insights that we can use to help us improve Training

• Cross-functional, collaborative and adaptive teams
developing and delivering value-added product (system-
software) increments in a continuous flow from
requirements to deployment Agile Scrum
• Avoiding the high cost of discovering defects late in the Cultural Adoption Coaching &
Renewal Training
development cycle by discovering defects early in the
development cycle which is accomplished by
eliminating waste, increasing feedback loops and
developing code from the point of view of provability
and outside-in design
Organizational
• Emphasis is placed on the need for teams to nurture Change
Management
group cohesion, and paying attention to norms that
serve as a guide that strengthens positive practices
• Minimizing frustration levels and making the art and
science of system-software development enjoyable and Delivering value early and
not a burden or death march often, giving ourselves the
best opportunity to beat the
• The what, why, and how of agile/lean product (system-
competition to market,
software) development and delivery is not one persons realize revenue and
vision alone; to become reality it needs to be a "shared" discover insights that we
vision through negotiation and compromise between can use to help us improve
individuals, the team and the organization
5

Four Spheres
of Influence

1. Sphere 1 - Stakeholder Needs and Business Processes: This sphere denotes requirements (including
quality attributes such as performance, security and reliability), end-user business processes, business
drivers and operational environment.
2. Sphere 2 - Architecture and Design: This sphere denotes the essential elements of the system, the
relationships between them, and how they fit with the enterprise system. The elements include
structure, behavior, usage, functionality, performance, resilience, reuse, comprehensibility, economic
and technologic constraints and tradeoffs.
3. Sphere 3 - Marketplace: This sphere denotes available and emerging technology and products, non-
development items and relevant standards.
4. Sphere 4 - Program/Project Management: This sphere denotes the management aspects of the
project. These aspects consider the cost, schedule and risk of building, fielding and supporting the
solution. Key to these management aspects are the cost, schedule and risk of changing the necessary
business processes.

These four spheres are simultaneously defined and traded through the life of an agile and
lean project because a decision in one sphere will inform and likely constrain the decisions
that can be made in another sphere 6

5 levels of Agile Planning
What, Who, Why, When, Constraints,
Product Vision Assumptions
Releases – Date, Theme/Feature Set,
Product Roadmap Objective, Development Approach

Iteration, Team Capacity, Stories, Priority,
Release Planning Size, Estimates, Definition of Done

Stories – Tasks, Definition of Done
Iteration Planning Level-of Effort, Commitment

1. What did I do yesterday?
Daily Planning 2. What will I do today?
3. What is blocking me?

Gain
Lower Accept feedback
project risk change through
through without iterative
higher slowing incremental
visibility down value
delivery

Delivering
value early
and often,
giving
ourselves
the best
opportunity
to beat the
competition
to market,
realize
revenue
and
discover
insights
that we can
use to help
us improve

8

A Paradigm Shift

Fixed

Variable
Source: www.dsdm.org

How is Agile Planning Different from Traditional Approaches?

Product Vision What, Who, Why, When, Constraints, Assumptions



Product Vision
 What
 Who (Stakeholders)
 Why
 When
 Constraints &
Assumptions “If you don't know where you are
going, that's where you'll end up.”
-Yogi Berra
11

Product Vision
 What
 Summary of the major benefits and features the product will provide
 Gives context to the reader
 Defines the business context for the product. In which domain is it going to
function (for example, telecom or bank) and what market—who are the users?
State whether the product is being developed to fulfill a contract or if it is a
commercial product.

 Who (Stakeholders)
 There are a number of stakeholders with an interest in the development and not
all of them are end users. Think of this as outside-in-design.
 Customer/Consumer
 Other vested interests
 Provides the background and justification for why the requirements are needed

Continued on Next Page
12

Continued from Previous Page
Why
Need and opportunity

When
 Begins the process of project scheduling by illuminating the stakeholders’ time expectations
regarding the product. Also helps you dig into their expectations by defining the circumstances in
which the new product would be used.
Constraints & Assumptions
 Express the constraints under which the project is undertaken. These constraints impact risk and
cost. They could be things like external interfaces that the product must adhere to, standards,
certifications or a technical approach employed for strategic reasons, such as using a certain
database technology or distribution mechanisms.

Releases – Date, Theme/Feature Set, Objective,
Product Roadmap Development Approach



If you don't know where you are going, it's impossible to determine the
best way to get there.

A product roadmap is an essential tool for product planning and
development.

Product roadmaps outline when products are scheduled for release and
include an overview of their primary and secondary features.
15

Tooling Life Cycle
Reporting
Life Cycle

Planning/ Receiving/ Inventory Tool End of
Procurement
Sourcing Warehousing Management Utilization Life

Tool received OEM or tooling
Need for a TB submits SC will bin
at PIT Tool utilized deems tool
tool & quantity PR through or check out
USA dock On aircraft unserviceable
defined Sceptre For use

SC receives and Tool shipped
bins the tool Kit back to USA
Process Steps

TS sources TP generates PO Tool then
& gets quote/ that transmits management checked in/out, PIT
delivery date to OEM Tool Sup checks calibrated, shipped,
for damage & Reported on
calibration Tool repeatedly Tool Sup marks
Repair tool BER, lost
OEM confirms or other
price & LT Tool Sup gives
stores
next steps
Theme Tool changed
OEM makes Stores stocks To inactive
tool part or ships to
another location Note: some of these
= System Transaction Process steps may Tool held
TS = Technical Sourcer vary at non-maintenance In case of
TP = Technical Purchaser Tool arrives Future need
Tool Sup = Tooling Supervisor at new station stations For it
TB = Tooling BA
LT = Lead Time
USA = US Airways Tool received
SC = Stock Clerk in Sceptre 16
BER = Beyond Economical Repair

The Product Backlog is Derived from the
Product Vision and Roadmap

© Scott Ambler, 2004

17

Copyright © 2005, Mountain Goat Software

1. Agile puts the Product Owner (aka “the business” or customer representative) in the
driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a limited capacity. They get
to define a scope up-front, but then any changes they deem necessary are change ordered back to them. This practice
assumes that the customer knows exactly what they want up front and penalizes them for changing their minds later in the
development process.

2. Agile allows the business to quickly react to changing market conditions and needs – The only
thing constant in today’s economy is change. Businesses need to be able to make quick course corrections in order to
survive.

3. Agile provides visibility into the development process – For many customers software development is a
dark art. They don’t have the background in order to understand the technical details and in most cases the development
team prefers it this way. The customer is left feeling helpless and Agile engages them throughout the development
lifecycle, providing enhanced visibility.

4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is responsible
for “what” is to be developed the Development Team is self-directing and self-organizing as to “how” to develop the system-
software product
Copyright © 2008 Russell Pannone. All rights reserved.

18

Tooling Project - Product Backlog

19

Where do
Optional
Stories
come from
Optional

Optional
Bus
Strategy

Use Cases
Business
Model

System Requirements
Customer Functional

Business Partner
&
Non-Functional
Product Owner
Team Solution/IT-Services


Characteristics of good stories
As a <who/user> I want <what/goal> so that <why/reason>

 A good story is negotiable, testable, estimatable, commercially or
operationally value-adding, cohesive and loosely-coupled
 It is not an explicit contract for features or functionality; rather stories
are short descriptions of functionality, the details of which are to be
refined in a conversation between the Product Owner (aka, the business or
customer) and the development team
 The challenge comes in learning to include just enough detail to be able to
prioritize and estimate the size of story and minimize ambiguity
Story1 Story4
As an eligible user, I want to pay the As an eligible user, I want to access my Story11
onetime registration fee of $10, so record and delete any or all of my As an eligible user, I want to view a list
that I can access my driver’s record in information to keep it current of assembled answers to questions
the future asked most frequently of the DMV

Story5
Story2 Story12
As an eligible user, I want to access my
As an eligible user, I want to create a As an eligible user, I want to be able
record and change any or all of my
unique user name and password so find an address for my local DMV
information to keep it current
that my access is limited to my record office and print the results
and to track activity and payment
Story6 Story13
Story3 As an eligible user, I want multiple As the application, I want to maintain
As an eligible user, I want to access my payment options to pay fees so that I an audit trail of changes for each
record, so that I can verify that it is am able to access the features of the eligible user record indicating all edits
correct DMV site that require payment

Acceptance
Criteria

 Acceptance criteria, represents the details for a story and specifies the
desired behavior and functionality the system-software must implement
 Acceptance criteria answer the question, “How will I know when I’m done
with the story?”
 Acceptance criterion is high level tests to verify and validate the
completeness of a story or stories implemented during a Sprint/Iteration,
expressed in a business domain language
 These tests are created ideally through collaboration between business
customers, business analysts, testers and developers; however the Product
Owner (aka, the business or customer) is the primary owner of these
conditions-of-satisfaction
 Test cases and acceptance criteria are two different things
 Test cases answer the questions, “How do I test and what are the test
steps?”

 Depiction of the user
interface or maybe even a
report layout, is just as
much a part of the details
behind a story as
acceptance criteria
 Wireframes and screen
mockups are often
attached to stories as a
basic visual guide used in
interface design by the
development team
 Low fidelity diagrams
depicting a candidate
solution may also be
attached to stories to
visually communicate its
design Copyright © 2008 Russell Pannone. All rights reserved. 23

Iteration, Team Capacity, Stories, Priority, Size,
Release Planning Estimates, Definition of Done



Product Vision

Product Roadmap

Iteration Plan

Product Backlog

Review and Adapt Develop

Release Plan

Copyright © 2008 Russell Pannone. All rights reserved. Adapted from “Agile Project Management” Jim Highsmith Copyright 2004 25

The Release Plan
The Release Plan is determined from
the team’s velocity; initially this is an
estimate, a best guess until the team’s
actual velocity can be determined from
historical data
We create the Release plan from
 The size estimate
 The velocity (“size per iteration”)
The Release plan shows what will be
worked on in each iteration
 Each iteration contains approximately the same number of
story points and is time boxed by iteration length


Components of the Release Plan

The Release Plan is comprised of:
1. The release theme
2. The release content
3. Business value statement for the release
4. The release timeline


Creating the Release Plan
(continue from previous slide)

Once we have identified the theme and content for each
release, we can prepare a brief summary of the Business Value
to be delivered at each release

Example:
Release 1- This release implements ……. and allows users to
………………..


Release Timeline

 Stories at the right level of detail
 Prioritized stories
 Sized stories

 Deriving/estimating duration and
cost to deliver product

Velocity is a
measure of a Deriving estimates
team’s rate of  4 iterations based
progress per on team velocity
Iteration  Each iteration 3
weeks long
 12 weeks total
duration
 Estimated cost of
$15,000 per
iteration
 Estimated total
cost of $60,000



Stories – Tasks, Definition of Done Level-of Effort,
Iteration Planning Commitment


1. Selecting Stories from the
Product Backlog based on
the team’s velocity
2. Identifying the tasks to
realize a selected Story
3. Estimating the level-of-
effort required to
complete the task


Working software & demo
Unit test
Code review
Installer
Tests
Functional
Performance
Regression
Documentation
User docs/Online help
Internal design docs
Release notes
API documents
Copyright@2009 SolutionsIQ All rights Reserved

35
Copyright@ 2008 Russell Pannone. All rights reserved.

1. Performing tasks to
complete the story
2. Completing the story
based on story
acceptance criteria
and team's definition
of done
3. Developing and
delivering commercial
or operational value
incrementally


Reduce Waste Feedback Loops
• Remove what isn’t of • Sprint Review & Planning
value to the customer • Sprint Retrospective
• Quicker delivery of value • Daily Scrum
& ROI
39

5 Levels of Agile Planning Explained Simply

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 5 Levels of Agile Planning Explained Simply

Similaire à 5 Levels of Agile Planning Explained Simply (20)

Plus de Russell Pannone

Plus de Russell Pannone (16)

Dernier

Dernier (20)

5 Levels of Agile Planning Explained Simply