agile estimation and planning spin spspinsp.org.br/apresentacao/agileestimation.pdf · 2011. 2....

Agile Estimation and Planning

Martine Devos

copyright Martine Devos 2007

Date: August, 06 2007 (Monday)Time: from 6:30 to 9:00 PM Place: Fundacao Carlos Alberto Vanzolini – Paulista Avenue, 967 - 5 floor -Sao Paulo - Brazil

SPIN São Paulo meetingBrazil

Estimation and Planning

Focus on AgileBeyond Agile

8/7/2007 copyright Martine Devos 3

Estimation has a bad reputation

• “Estimation is the most optimistic prediction that has a non-zero probability of coming true”

• “what is the earliest date by which you cannot prove you will not be finished”-estimating

– Tom DeMarco (cited by Mc Connell)


Urban legends• Complicated formulas are more accurate than

simple estimates

• We need to correct estimates with factors for team collocation, experience…

reality is opposite – the more chances for subjectivity to creep

• “They will not let us…” management does not want correct estimates, they just want a date…

Many so called estimation problems arise from misunderstanding what an “estimate’ is and blurring other similar-but-not-identical concepts

with estimation.


What is an “estimate”?1. A tentative evaluation or rough calculation.2. A preliminary calculation of the cost of a project3. A judgment based upon one’s impressions; opinion

(source: American Heritage Dictionary, Second College Edition, 1985)

Does this sound like what we are asked for (asking for) an estimate?

When executives ask for an estimate, they’re often asking for a commitment or for a plan to meet a target.


Glossary• A Target = a statement of desirable (often much needed) business

objective• A Commitment = a promise to deliver defined functionality at a

specific level of quality by a certain date.Commitment can be the same as an estimate, it can be more aggressive

or more conservative. It does NOT have to be the same as the estimate.

• An Estimate should be treated as an unbiased, analytical process –the goal is accuracy, not to seek a specific result

• Planning should be treated as a biased, goal-seeking process – the goal is to seek a particular result

Combining estimation and planning ends up in a poor estimate and a poor plan or both

• We refine estimates over time and we improve the plan

8/7/2007copyright Martine Dweevos

8

A typical conversation• Executive: How long do you

think this project will take? We need to have this ready in 3 months for a trade show. I cannot give you any more team members, so you will have to work it out with your current staff. Here is the list of features we will need.

• Later, the project lead: We have estimated it will take 5 months.

• Executive: Five months? Did not you hear me? I said we needed it ready in 3 months for the tradeshow.


A better conversation• Executive: How long do you think

this project will take? We need to have ….

• Project lead: Let me make sure I understand what you are asking for. Is it more important for us to deliver 100% of the feature, or is it more important to have something ready for the tradeshow?

• Executive: We have to have something ready for the tradeshow. We would like 100% of those features if possible.

• Project lead: I want to make sure I follow through on your priorities as best as I can. If it turns out that we cannot deliver 100% of the features by the tradeshow, should we be ready to ship what we have or should we plan to slip the date beyond the tradeshow?

• Executive: We have to have something for the tradeshow, so we have to ship something even if it is not 100% what we want.

• Project lead: OK, we will come up with a plan for delivering as many features as we can in the next 3 months.

8/7/2007 10

What if there is Mismatch between goal and estimates?

• Tell a lie to keep our job?• Negotiate the estimate?

• If the mismatch is allowed to persist the options will be far fewer

• There are NO white lies.

• NO ! • The detection of a

mismatch between the project goal and the project estimate should be interpreted as useful, early-in-the-project risk information.

• And allow the project-team to make the right decisions

11

AGILE PLANNING


Planning and Project Parameters• Keeping the project in equilibrium• Time, cost, and resource availability bound scope

and quality


TPM –Project plan identifies time, cost and resource availability to deliver scope and quality – “creep”

See: Wysocki, McGary

8/7/2007 copyright Martine Devos 2007 15

Velocity

turning Product Backlog into increments of functionality

Product Backlog

Time

Other variables: Quality, Value

Project Management Variables

Learning from the “Burndown”

8/7/2007

copyright

Martine

Devos

16

Start date Current date Target date

Planned

Actual

stories

Making a plan

• We need units• We need measure of capacity and

progress

• Units: Story Points…:ITD (Ideal Team Day), IPD (Ideal Person Day)

• Measure of Progress: Velocity – Easier to know after the facts “yesterday’s

weather”8/7/2007 copyright Martine Devos 2006 17

Reducing Encertainty

• Why do we plan? Why do we estimate?

high

high

low

low

Wha

t?

How?Waterfall Approach

high

high

low

lowW

hat?

How?

Agile Approach

Agile and Traditional Breakdown Structures

• Traditional focus on input– Work Breakdown Structure -- WBS

• Agile focus on output– Focus on outputs– Feature Breakdown Structure -- FBS

• Feature Sets– Architecture – Component Breakdown

Structure -- CBS


Value Creation in Agile Methods


Val

ue

Time

Core to agile success is feedback


Reduce the Black-Out PeriodsDone is Binary - done/not done

Important: What does it mean to be done?

• We report Done or Not Done binary• No “90 percent done” or “Almost there”


Focus of Agile Planning –multilevel

• Levels of Planning– Strategy– Portfolio–Product

–Release–Sprint– Day

Agile focus is on planning between product (considered +/- defined) and iteration.Daily planning is team’s concern

Mike Cohn calls it the Planning Onion

Cone of uncertainty


Vision estimate -75% - + 300%

Exploratory estimate-50% - + 100%

Budget estimate-20% - + 25%

Commitment estimate -10% -+ 10%

Correspondence with 3 Levels of Precision in agile

• Stories in story points

• Tasks in hours(estimate)

• Looking back at daily scrum: I worked for X hours on the UI and I will be able to finish before the end of the day (actual time)

• Car rental system

• As a user, I want to…• As a renter, I want to…• Write test fixture• Code UI…


Release

Writing Product Backlog Items

The items in the product backlog are described a various levels of detail and granularity: “Newspaper style”


Stories Refine the Project BacklogBacklog items come inmany shapes and sizes

Transform backlog

to actionable stories

Stories are small, and only come in a few sizes

In an iteration: from story to task

Code UI 12Code database

5Script tests 12… 6

….….

…

Story a 5Story b 6Story c 4Story d 3Story e 5

Story f 5Story g 3Story h 3Story i 5Story j 5Story k 3Story l 8Story m

2

Cone does not improve itself• Estimates improve

– When we collect data– Reflect on estimates– Remove variability

• Making decisions• Keeping team stable…

• NOT by spending more time estimating


Strong stimulus for Product Owner and Managers to make decisions

ESTIMATION


Accuracy and (Unwarranted) PrecisionShortest possible schedules are achieved by creating the most

accurate possible not the most precise estimatesIf you want to achieve maximum development speed avoid false

precision

An estimate of 20-50 days may be accurate but not precise

An estimate of 35 days for the same situation creates a false feeling of precision

373.2 days + or – 2 months3741 hours for a feature

Estimates in hours at Release planning (NOT enough detail available!)

= unwarranted precision

Is Pi = 3.32367 better than Pi is 3?


StoryPoints Floorplan• You are hired to paint this

house, materials will be there…

• You only have the floorplan, did not see the actual house.

• You estimate the two bedrooms to be each 5 points…

• How long will it take to paint this house.

37

Tool: Planning Poker

• Group technique • Precision decreases as story size

increases, therefore constrain estimates to pre-defined values (e.g. 1, 2, 3, 5, 8, 13 and 21 (or big)


Wideband Delphi Estimation

• Iterative approach for improved estimates• Every developer gives his estimate • Discuss differences, especially extremes • Re-estimate until convergence


Planning tools?

• Story-cards• Wall, white board…

• Later used to show to and track progress at all time


PRESENTING ESTIMATES TO OTHER STAKEHOLDERS

Start with a range indicating the uncertainty

estimateInitial concept 3-24Approved product definition

5-20

Requirements complete

9-20

User interface design

12-18

First interim release

15-18

Rather than losing the customer’s confidence by taking one schedule slip after another, you build confidence by meeting the expectations and by tightening the ranges = REFINING ESTOMATES

Quantify risk in estimatesEstimate 10 features 6 months (+3 -2)• +1 for late delivery of graphics formatting system• + 1 for new dev tools not working as well as

expected• + 0.5 for staff sickness• +0.5 for underestimating by new members

• - 1 for less delay in hiring new developer• - 1 for new dev tools working better than

expected



THERE'S NO POINT IN BEING EXACT ABOUT SOMETHING IF YOU DON'T EVEN KNOW WHAT YOU'RE TALKING ABOUT.—JOHN VON NEUMANN

Killer: We already have all the requirementsRelating stories to requirements and legacy backlog

Market assessment

User wantedbehavior

Technical realization

Customer profiles

User stories requirement specsrequirement 1

F1.1F1.2

requirement 2

F2.1F2.2

F2.2.1

…8/7/2007 copyright Martine Devos 46

CARD

Conversation

TEST

STORY

The Planning Bucket

• Once the bucket is full, the planning stops– Maintenance, ….

• Be aware that skills and knowledge distribution within the team can also constrain the team’s capacity

Gro

ss h

ours

Net hours

Over-

head

The Planning Bucket

• Martine Devos• +32 9 3247393• +32 473 242749• Skype: mmdevos• [email protected]• www.martinedevos.org• www.scrum.be


References

• Excellent book: Steve Mc Connell, Software Estimating

• Intro to agile estimation and planning:Mike Cohn, Agile Estimation and Planning


agile estimation and planning spin spspinsp.org.br/apresentacao/agileestimation.pdf · 2011. 2....

Documents