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.

http://www.youtube.com/watch?v=Miwb92eZaJg

http://www.cognitive-edge.com/video-childrens-party.php

http://www.apple.com/quicktime/download/

ChaoticEnterprise/Organization

OrderedEnterprise/Organization

ComplexEnterprise/Organization


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

• Delivery of commercial or operational 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

• Cross-functional, collaborative and adaptive teams developing and delivering value-added product (system-software) increments in a continuous flow from requirements to deployment

• Avoiding the high cost of discovering defects late in the 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

• Emphasis is placed on the need for teams to nurture 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 not a burden or death march

• The what, why, and how of agile/lean product (system-software) development and delivery is not one persons vision alone; to become reality it needs to be a "shared" vision through negotiation and compromise between individuals, the team and the organization

5

Roadmap to “being” agile

Agile Adoption

Agile Coaching & Training

Scrum Coaching & Training

Organizational Change

Management

Cultural Renewal

Four Spheresof 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 sphere6

Product Vision

Product Roadmap

Release Planning

Iteration Planning

Daily Planning

What, Who, Why, When, Constraints, Assumptions

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

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

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

5 levels of Agile Planning

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

8

Gainfeedbackthroughiterative

incrementalvalue

delivery

Acceptchangewithoutslowingdown

Lowerproject risk

throughhigher

visibility

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

A Paradigm Shift

How is Agile Planning Different from Traditional Approaches?

Source: www.dsdm.org

Variable

Fixed

http://www.dsdm.org/

Product Vision

Product Roadmap

Release Planning

Iteration Planning

Daily Planning






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 Berra11

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

12

Continued on Next Page

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

Continued from Previous Page

Product Vision

Product Roadmap

Release Planning

Iteration Planning

Daily Planning






15

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.

16

Tooling Life Cycle

Planning/

SourcingProcurement

Receiving/

Warehousing

Inventory

Management

Tool

Utilization

End of

Life

Need for a

tool & quantity

defined

TS sources

& gets quote/

delivery date

TB submits

PR through

Sceptre

TP generates PO

that transmits

to OEM

OEM confirms

price & LT

OEM makes

tool

Tool Sup checks

for damage &

calibration

Tool received

at PIT

USA dock

Tool Sup gives

stores

next steps

Stores stocks

part or ships to

another location

Tool received

in Sceptre

Tool arrives

at new station

SC will bin

or check out

For use

Tool then

checked in/out,

calibrated, shipped,

Reported on

repeatedly

Tool utilized

On aircraft

OEM or tooling

deems tool

unserviceable

Tool shipped

back to USA

PIT

Tool Sup marks

tool BER, lost

or other

Tool changed

To inactive

Tool held

In case of

Future need

For it

TS = Technical Sourcer

TP = Technical Purchaser

Tool Sup = Tooling Supervisor

TB = Tooling BA

LT = Lead Time

USA = US Airways

SC = Stock Clerk

BER = Beyond Economical Repair

= System Transaction

Kit

management

Reporting

Note: some of these

Process steps may

vary at non-maintenance

stations

SC receives and

bins the tool

Tool

Repair

Pro

ce

ss

Ste

ps

Lif

e C

yc

le

Theme

The Product Backlog is Derived from theProduct Vision and Roadmap

© Scott Ambler, 2004

17

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

18

Copyright © 2005, Mountain Goat Software

Copyright © 2008 Russell Pannone. All rights reserved.

Tooling Project - Product Backlog

19

Virtual Story Board Tooling Project.xls

BusStrategy

BusinessModel

System RequirementsFunctional

&Non-Functional

Solution/IT-Services

Where do Stories

come from

Use Cases

20Copyright © 2008 Russell Pannone. All rights reserved.

Optional

Optional

Optional

CustomerBusiness PartnerProduct Owner

Team

Characteristics of good stories

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

21

Story1As an eligible user, I want to pay the onetime registration fee of $10, so that I can access my driver’s record in the future

Story2As an eligible user, I want to create a unique user name and password so that my access is limited to my record and to track activity and payment

Story3As an eligible user, I want to access my record, so that I can verify that it is correct

Story4As an eligible user, I want to access my record and delete any or all of my information to keep it current

Story5As an eligible user, I want to access my record and change any or all of my information to keep it current

Story6As an eligible user, I want multiple payment options to pay fees so that I am able to access the features of the DMV site that require payment

Story13As the application, I want to maintain an audit trail of changes for each eligible user record indicating all edits

Story12As an eligible user, I want to be able find an address for my local DMV office and print the results

Story11As an eligible user, I want to view a list of assembled answers to questions asked most frequently of the DMV


As a <who/user> I want <what/goal> so that <why/reason>

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?”


23

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.

Product Vision

Product Roadmap

Release Planning

Iteration Planning

Daily Planning






Product Vision

Release Plan

Iteration Plan

DevelopReview and Adapt

Product Backlog

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

Product Roadmap

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


28

Content

Virtual Story Board Tooling Project.xls

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


Creating the Release Plan(continue from previous slide)

Release Timeline

Stories at the right level of detail

Prioritized stories

Sized stories

Deriving/estimating duration and cost to deliver product



Deriving estimates

4 iterations based on team velocity

Each iteration 3 weeks long

12 weeks total duration

Estimated cost of $15,000 per iteration

Estimated total cost of $60,000

Velocity is a measure of a team’s rate of progress per

Iteration

Product Vision

Product Roadmap

Release Planning

Iteration Planning

Daily Planning







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

34

35

Copyright@2009 SolutionsIQ All rights Reserved

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@ 2008 Russell Pannone. All rights reserved.

Product Vision

Product Roadmap

Release Planning

Iteration Planning

Daily Planning







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

37

Reduce Waste

• Remove what isn’t of value to the customer

• Quicker delivery of value & ROI

Feedback Loops

• Sprint Review & Planning

• Sprint Retrospective

• Daily Scrum

39

5 levels of agile planning explained simply

Technology

product roadmapobjective

agile competition

agile planning different

product roadmap objective

development approachiteration

development approach

iteration planning level

levels of agile planningwhat