Agile Planning

transcript

Agile Planning

September Central Indiana MPUG

Matt Block

Quick Introduction

Developer by trade – CS Major from Purdue (Go Boilers!) – Developer at large manufacturing company

Development Manager – Small software company – Introduced Agile

Product Manager/Product Owner – Sounded good at the time

Development Manager – Large Software company – Leading Agile Transformation

AgileIndy – Founding Member/Organizer

Agenda

Agile Planning – Common Myths

– Agile means no plans

– You can’t do fixed date projects in agile

Agile Release Planning – An Overview

AGILE MEANS NO PLANS

The Agile Manifesto

Individuals and Interactions

Working Software

Customer Collaboration

Responding to Change

Processes and Tools

Comprehensive Documentation

Contract Negotiation

Following a Plan

Agile Teams Plan Constantly

“Plans are nothing; planning is everything.”

– Dwight D. Eisenhower

“I plan to re-plan”

– Popular agile t-shirt

Levels of Planning in Agile

Strategy

Portfolio

Product

Release

Iteration

• 1-2 times per year • Product evolution over time

• 3-4 times per year • Feature/Date tradeoffs

• Every 2-4 weeks • What will fit in this iteration?

• Every day • How to complete comittement

Planning in Scrum

We Can’t Know Everything Up Front

Agile is Iterative

Accuracy vs. Precision

Plans must be accurate, gain precision over time – We’ll be done in Q3.

– We’ll be done in September.

– We’ll be done on September 10.

Precision is expensive, and more likely to be wrong.

While both accuracy and precision are desirable, accuracy is much more valuable.

YOU CAN’T DO FIXED DATE PROJECTS IN AGILE

The Agile Manifesto

Individuals and Interactions

Working Software

Customer Collaboration

Responding to Change

Processes and Tools

Comprehensive Documentation

Contract Negotiation

Following a Plan

Planning in Scrum

Fixed Date!

Fixed Dates in Scrum

Fixed Date

What About Utilization?

“Attempts to force non-deterministic systems to operate at greater than 80% efficiency will cause short bursts of stabilization followed by extreme periods of destructive and unpredictable variations from that goal.”

- W. Edwards Deming

The Iron Triangle

Quality is part of scope

– It is built in from the beginning, not “tested in” at the end.

Value is part of scope

– Higher value items are delivered sooner

“Depth” is part of scope

– Do you need a Porsche or will a Kia do?

Cost Schedule

The Release Burndown

Release Burndown Release Date

RELEASE PLANNING IN AGILE

Levels of Planning in Agile

Strategy

Portfolio

Product

Release

Iteration

• 1-2 times per year • Product evolution over time

• 3-4 times per year • Feature/Date tradeoffs

• Every 2-4 weeks • What will fit in this iteration?

• Every day • How to complete comittement

What is It?

Usually trying to answer questions like…

– How much can be done by a given date?

– When can this set of features be shipped?

– How many teams do we need working on this project?

What is Needed?

Prioritized, estimated backlog

– High level estimates from the team that will likely do the work.

– Prioritized by business value.

Velocity

– Average amount of work a given team can complete in a given sprint.

– Usually use the previous 8 – 12 sprints.

Velocity?

Agile teams usually use relative estimates, not precise estimates

– This feature is about the same as that one.

– Often expressed as Story Points using a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, … )

A team’s Velocity is the sum of the story points for all of the user stories/features that are completed in a sprint

Getting Confidence Intervals

We can obtain the 90% confidence intervals using a team’s historical velocity values from recent sprints.

Sort the velocities from the previous 9 sprints.

Throw out the highest and lowest. The remaining highest and lowest

is your 90% confidence range. www.mountaingoatsoftware.com

has good tools to help with this

Using Confidence Intervals

Apply the confidence intervals to your backlog to get a better idea of how much work will be done by a given date.

We will almost certainly get here (8x26)

At our median velocity, we’ll get here (8x30)

The most we could realistically expect is here (8x32)

Using Confidence Intervals

Apply the confidence intervals to your backlog to determine when a given set of features will be done.

– We will almost definitely be done in 20 sprints (500 / 26)

– At our median velocity, we will be done in 17 sprints (500 / 30)

– The best we could realistically expect is to be done in 16 sprints (200 / 32)

Burndown with Confidence!

Release Burndown Release Date

Credits and References

Mike Cohn

– http://www.mountaingoatsoftware.com

– Blog, Books, Articles, Presentations

– Agile Estimating and Planning, Succeeding with Agile

– Portions of this presentation were taken from his redistributable Introduction to Scrum presentation

Contact Information

Matt Block

– Email: matt@developmentblock.com

– Blog: http://www.developmentblock.com

AgileIndy

– Meetup: http://www.meetup.com/agileindy/

– Meet 2nd Wednesday @ 5:30

Agile Planning

Technology