my presentation at BetterSoftware 2012

1. ESTEEM
AND
ESTIMATION
Gaetano Mazzanti
Agile42
Gama-Tech
@mgaewsj

2. Rumeli hisarı

3. estimates are not
“the” problem
the problem is in
how we use estimates

4. why do we estimate?

5. how do we estimate?

6. where are you?
The Marshall Model of Organizational Evolution

7. classic
dysfunctions in
estimates

8. 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)
itm ent
= c omm
mat e =
e sti

9. estiqaatsi!
(WTF)
“we estimate the
project will take
18726.35 hours”

10. unrealistic
targets
that’s
impossible!
that’s why
I chose
you :-/

11. fractional task time
Task A essiamonoi (50%)
Task B essiamonoi (30%)
Task C essiamonoi (20%)
d
the myth of full capacity

12. we live in
systems
projects “good”
on target estimates
padding

13. being on target
!=
delivering value

14. being “good” at estimating
!=
being good at delivering value

15. we live in
systems...
fear
stress
turnover +
R
- imposed
targets failed or
quality challenged
+ projects*
*68% according to
Chaos Report 2009

16. Critical Path
Critical Pain
Critical Chain

17. traditional planning:
single loop “learning”
uncertainty
estimation discovery
impediments
delays
plan poor quality
over budget
more detailed planning

18. Sisyphus
an eternity of useless efforts
and unending frustration

19. judgement and
decision making
under uncertainty
+ other limitations
of our mind

20. 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 be
done than many of us realize,
or would like to admit

21. overconfidence
clinicians 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

22. 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”)

23. retrospective
estimation
the fallacy holds also looking
back to the past:
reported time is typically less
than the actual time

24. we are good at
comparative estimating

25. mmm not too good

26. illusions we
cannot resist

27. anchoring
is the height of the tallest
redwood more or less than 250
meters?
vs
what is the height of the
tallest redwood?

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

29. 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)

30. affect heuristic
“he likes the project so much
that he thinks costs are low and
benefits high”

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

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

33. we can’t stand
uncertainty
we always look for causal
explanations
even when events are due just to
chance
we favor certainty over doubt

34. welcome to
uncertainty

35. being uncertain
!=
I don’t know

36. uncertain
!=
unpredictable

37. approximately right
vs
perfectly wrong

38. we need (some) predictability for
portfolio management, budgeting,
release planning, etc.

39. Agile to the rescue?

40. estimates
& the Manifesto
processes and tools
individuals and interactions
comprehensive doc
ent
working software omm itm
e ! = c
sti mat
e contract negotiation
customer collaboration
following a plan
responding to change

41. Agile to the
rescue?
small tasks (stories)
comparative sizing
short time-scale
fast feedback

42. “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

43. when starting a
project
we simply want a rough idea of
size and an understanding of
(un)certainty

44. do a pre-mortem!

45. Agile has ritualized estimation
activities
there is some good
and some bad in this

46. planning poker
rocks.. really?
.
conversation rocks
relative estimation
treated as ranges...
kind of rocks initially
these should be
story points & velocity
may become dysfunctional

47. biggest value of the
estimation process is
conversation
(exploring,
discovering)
instead of sizing
we should call it just
understanding

48. velocity &
variability
33#
30#
27# average#velocity#
UCL#
24# LCL#
velocity#
21#
18#
15#
1*Feb# 1*Mar# 1*Apr# 1*May# 1*Jun# 1*Jul# 1*Aug# 1*Sep#

49. velocity related
smells
all sprints end with a
100% story completion rate
all sprints have the
same velocity
velocity is increasing
regularly at each sprint

50. estimation == waste?
“time spent estimating is
time not spent doing
value adding stuff”
mmm, yes and no...

51. from
learning to estimates

52. an alternative to
Story Points?
just count the
number of Stories

53. we can use historical data
(story count) to predict
scope delivery on a given date
and to estimate
cost (ROI) of story delivery

54. counting & measuring
instead of estimating

55. measure cycle (lead) time
backlog to do in progress test done
1 2 2
F C A
E
G D B
H
I
J
cycle time
lead time

56. selection & pull
backlog to do in progress test done
1 2 2
F C B A
G
E
D
H ?
I
J

57. flow, pull &
commitment
commitment = starting something
commit only when you pull
less WIP = less commitment =
more options

58. “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 past
acknowledge your ignorance
constantly monitor progress
cross your fingers
(optional) be transparent with
your client

59. esteem and respect

60. respect
estimates
!=
commitments

61. 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 to
cut corners
C T!
S PE
RE
NO

62. 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
C T!
S PE
RE
NO

63. pretending decisions
are shared
“shared” decisions (estimates)
are often extorted
C T!
S PE
RE
NO

64. bullying
“when will it be done?”
==
I don't trust you
C T!
S PE
RE
NO

65. the right questions
RES
it will PEC
T
take 3 days
why not 2?
why not 4?

66. safe to fail
culture
RES
PEC
T
mistakes are
fine! (within
boundaries)
you need to
learn from them

67. limit WIP
RES
PEC
when you limit WIP you are T
helping the team:
finishing stuff
making fewer commitments
giving them options

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

69. estimates can't be wrong
they're estimates!
"accurate estimates" or
"improving estimates" =>
just a waste of time

70. estimates are not
“the” problem
the problem is in
how we use estimates

71. looking at our models and
assuming they might be wrong
is the heart of respect
Liz Keogh

72. Gaetano Mazzanti
@mgaewsj
gaetano.mazzanti@gmail.com