Gaetano Mazzanti

Agile42Gama-Tech

@mgaewsj

ESTEEM

AND

ESTIMATION

Rumeli hisarı

estimates are not“the” problem

the problem is inhow we use estimates

why do we estimate?

how do we estimate?

where are you?

The Marshall Model of Organizational Evolution

classic dysfunctions in

estimates

padding (bottom-up)

imposed deadlines/unrealistic goals (top-down)

planning fallacy (overoptimism)

fractional task time (multitasking)

precise values instead of confidence intervals

no specific risk estimation (known unknowns, unknown unknowns)

estimate =

= commitme

nt

“we estimate the project will take 18726.35 hours”

estiqaatsi!

(WTF)

unrealistic targets

that’s impossible!

that’s why I chose you :-/

fractional task time

essiamonoi (50%)

essiamonoi (30%)

essiamonoi (20%)

Task A

Task B

Task C

the myth of full capacityd

we live in systems

projects on target

“good”estimates

padding

being on target

!=

delivering value

being “good” at estimating

!=

being good at delivering value

failed or challengedprojects*

we live in systems...

fearstress

turnover

quality

imposed targets

R

+

-

+

*68% according to Chaos Report 2009

Critical PathCritical Chain Critical Pain

uncertaintydiscovery

impediments

more detailed planning

traditional planning:single loop “learning”

plan

estimation

delayspoor qualityover budget

Sisyphus

an eternity of useless efforts and unending frustration

judgement and decision making

under uncertainty

+ other limitations of our mind

the planning fallacy

humans systematically underestimate how long it will take to do a task

they are over confident in their own estimates

saying “estimate better” or “remember how long previous tasks took” won’t work

deadlines are more significant in determining when work will bedone than many of us realize,or would like to admit

overconfidenceclinicians in a study were completely certain of the diagnosis antemortem: they were wrong 40% of the time

appearing unsure is considered a weakness

the admission that one is simply guessing is unacceptable

estimating others and the past

people underestimate their own but not others completion times

people focus on plan-based scenarios rather than relevant past experience when predicting

people undervalue past experience (“this time is different”)

retrospective estimation

the fallacy holds also looking back to the past:

reported time is typically less than the actual time

we are good at comparative estimating

mmm not too good

illusions we cannot resist

anchoring

is the height of the tallest redwood more or less than 250

meters?

vs

what is the height of the tallest redwood?

framing effect

odds of survival one month after surgery are 90%

vs

mortality within one month of surgery is 10%

vs

mortality within one month of surgery is 1 person out of 10

loss aversion

losses cause much more pain than gains

we don’t close a project when we should for a small hope of avoiding a loss (not achieving a goal)

agreement is difficult to reach (i.e. to renegotiate a contract: your gain is my loss)

affect heuristic

“he likes the project so much that he thinks costs are low and

benefits high”

posture affects estimates (!)

when leaning to the left we produce smaller estimates :-/

Erasmus University research

http://medicalxpress.com/news/2011-11-physically-affects-decision-making.html

need for causality

we attribute causality to events in the past when in fact no cause-effect relationship exists (Retrospective Coherence)

to estimate we need to assume that causality exists

in a complex environment, this assumption is not valid

we can’t stand uncertainty

we always look for causal explanationseven when events are due just to chance

we favor certainty over doubt

welcome to uncertainty

being uncertain

!=

I don’t know

uncertain

!=

unpredictable

approximately right

vs

perfectly wrong

we need (some) predictability for

portfolio management, budgeting, release planning, etc.

Agile to the rescue?

estimates& the Manifesto

individuals and interactions

working software

customer collaboration

responding to change

processes and tools

comprehensive doc

contract negotiation

following a plan

estimate !

= commitme

nt

Agile to the rescue?

small tasks (stories)

comparative sizing

short time-scale

fast feedback

“estimating and planning can (and should) be lightweight.

you should stop when further planning is not likely to lead to improved decisions worth the extra effort”

Mike Cohn

when starting a project

we simply want a rough idea of size and an understanding of

(un)certainty

do a pre-mortem!

Agile has ritualized estimation activities

there is some goodand some bad in this

planning pokerrocks...conversation

relative estimation

story points & velocity

really?rocks

kind of rocks initially

may become dysfunctional

these should be

treated as ranges...

biggest value of theestimation process is

conversation(exploring,discovering)

instead of sizingwe should call it just

understanding

15#

18#

21#

24#

27#

30#

33#

1*Feb# 1*Mar# 1*Apr# 1*May# 1*Jun# 1*Jul# 1*Aug# 1*Sep#

average#velocity#

UCL#

LCL#

velocity#

velocity & variability

velocity related smells

all sprints end with a100% story completion rate

all sprints have thesame velocity

velocity is increasingregularly at each sprint

estimation == waste?

“time spent estimating is time not spent doing value adding stuff”

mmm, yes and no...

learning to estimatefrom

s

an alternative to Story Points?

just count thenumber of Stories

we can use historical data (story count) to predict

scope delivery on a given dateand to estimate

cost (ROI) of story delivery

counting & measuringinstead of estimating

measure cycle (lead) time

backlog to do in progress donetest

DG

H

JI

F

1 2 2

B

AE

C

cycle time

lead time

selection & pull

backlog to do in progress donetest

DG

 H

JI

F

1 2 2

B A

E

C

?

flow, pull & commitment

commitment = starting something

commit only when you pull

less WIP = less commitment = more options

“ok, but I need to sign a contract!”contract: a piece of paper to

define consequences when there's no trust and something goes wrong

use data from the pastacknowledge your ignoranceconstantly monitor progresscross your fingers

(optional) be transparent with your client

esteem and respect

respect

estimates

!=

commitments

imposed deadlines

top-down deadlines force people to compromise, motivation goes down

no control over the scope or schedule, only one variable left: quality.

if bonus is tied to delivering on-time the only way to achieve that goal is tocut corners

NO RES

PECT!

rebooting teams

execs need to understand/respect what makes a system work and what makes it (un)predictable

you can’t reboot teams, project to project, putting together different people each time and expect to have predictable outcomes

NO RES

PECT!

pretending decisions are shared

“shared” decisions (estimates)are often extorted

NO RES

PECT!

bullying

“when will it be done?”

==

I don't trust you

NO RES

PECT!

the right questions

RESPECTit will take 3 days

why not 2?

why not 4?

safe to fail culture

mistakes are fine! (within boundaries)

you need to learn from them

RESPECT

limit WIP

when you limit WIP you are helping the team:

finishing stuff

making fewer commitments

giving them options

RESPECT

in closing

1.traditional approaches fail(they ignore uncertainty and complexity)

2.our mind will anyway deceive us

3.Agile can help but beware of falling into the same trap as 1.

4.respect is key

estimates can't be wrongthey're estimates!

"accurate estimates" or"improving estimates" =>

just a waste of time

estimates are not“the” problem

the problem is inhow we use estimates

looking at our models and assuming they might be wrong

is the heart of respect

Liz Keogh

Gaetano Mazzanti

@mgaewsj

gaetano.mazzanti@gmail.com