The document discusses common pitfalls in project estimation and provides advice on how to create more accurate estimates in software development. It emphasizes the importance of understanding the boundaries of estimates, managing expectations with clients, and considering risks and team dynamics. The author encourages a collaborative approach, such as using planning poker, and stresses the need to document lessons learned to avoid repeating mistakes.

1. Estimation
Or,
“How to Dig your
own Grave”
Rowan Merewood

2. Who

3. Who
●
Software Engineer
●
& Team Lead
●
at Ibuildings

4. Who
●
Software Engineer
●
& Team Lead
●
at Ibuildings
●
@rowan_m

5. Why

6. Why
●
I've seen (& made)
mistakes

7. Why
●
I've seen (& made)
mistakes
●
You can avoid them

8. Why
●
I've seen (& made)
mistakes
●
You can avoid them
●
Make your own

9. What could possibly go wrong?

10. Sales create estimates

11. Sales create estimates
●
Use skills correctly

12. Sales create estimates
●
Use skills correctly
●
Send a dev with sales

13. Sales create estimates
●
Use skills correctly
●
Send a dev with sales
●
If you're sales & dev...

14. Sales create estimates
●
Use skills correctly
●
Send a dev with sales
●
If you're sales & dev...
remember which hat
you're wearing

15. Lone developer creates estimates

16. Lone developer creates estimates
●
It's ok, he's a
ROCKSTAR

17. Lone developer creates estimates
●
It's ok, he's a
ROCKSTAR
●
Independent
estimates

18. Lone developer creates estimates
●
It's ok, he's a
ROCKSTAR
●
Independent
estimates
●
Or, at least review

19. Estimate from detailed task lists

20. Estimate from detailed task lists
●
You know it will
change

21. Estimate from detailed task lists
●
You know it will
change
●
Gives misplaced
confidence

22. Estimate from detailed task lists
●
You know it will
change
●
Gives misplaced
confidence
●
Encourages micro-
management

23. Estimate a day as 8 hours

24. Estimate a day as 8 hours
●
16 hr. task == 2 days

25. Estimate a day as 8 hours
●
16 hr. task == 2 days
(ha ha – you're cute)

26. Estimate a day as 8 hours
●
16 hr. task == 2 days
(ha ha – you're cute)
●
You are not a code
machine

27. Estimate a day as 8 hours
●
16 hr. task == 2 days
(ha ha – you're cute)
●
You are not a code
machine
●
Even if you are,
your team is not

28. Estimate a day as 8 hours
●
16 hr. task == 2 days
(ha ha – you're cute)
●
You are not a code
machine
●
Even if you are,
your team is not
●
Dev: 6 hr. Lead: 4 hr.

29. Estimate in hours

30. Estimate in hours
●
Still too much detail

31. Estimate in hours
●
Still too much detail
●
Use ¼ days

32. Estimate in hours
●
Still too much detail
●
Use ¼ days
●
¼, ½, 1, 2, 3 days

33. Estimate in hours
●
Still too much detail
●
Use ¼ days
●
¼, ½, 1, 2, 3 days
●
1, 3, 5, 7 days

34. Estimate in hours
●
Still too much detail
●
Use ¼ days
●
¼, ½, 1, 2, 3 days
●
1, 3, 5, 7 days
●
Larger increments,
larger projects

35. Just estimate coding time

36. Just estimate coding time
●
Remember your
overheads

37. Just estimate coding time
●
Remember your
overheads
●
Remember team
overheads

38. Just estimate coding time
●
Remember your
overheads
●
Remember team
overheads
●
Think about
dependencies

39. Estimates as commitments

40. Estimates as commitments
●
Well, yes and no...

41. Estimates as commitments
●
Well, yes and no...
●
List and quantify risk

42. Estimates as commitments
●
Well, yes and no...
●
List and quantify risk
●
Estimates != schedule

43. Waterfall estimates are useless

44. Waterfall estimates are useless
●
Fine, stop calling
yourself an engineer

45. Waterfall estimates are useless
●
Fine, stop calling
yourself an engineer
●
Lots of work in
“off-the-shelf” tasks

46. Waterfall estimates are useless
●
Fine, stop calling
yourself an engineer
●
Lots of work in
“off-the-shelf” tasks
●
Cone of Uncertainty

47. Agile means we can't estimate

48. Agile means we can't estimate
“Yeah, well, you know, that's just like, your opinion, man.”

49. Agile means we can't estimate
●
Over-reaction to
Waterfall
“Yeah, well, you know, that's just like, your opinion, man.”

50. Agile means we can't estimate
●
Over-reaction to
Waterfall
●
Excuse to drop
software engineering
and just hack it
“Yeah, well, you know, that's just like, your opinion, man.”

51. Enough mistakes, time for a treat

52. Help your client understand
●
Estimates as a
budget

53. Help your client understand
●
Estimates as a
budget
●
The Holy Triangle
●
MoSCoW
●
Kano model

54. Holy Triangle
Good
Cheap
Fast

55. Holy Triangle
Good
Scope
Quality
Cost
Cheap
Time
Fast

56. MoSCoW
●
Must
●
Should
●
Could
●
Won't

57. MoSCoW
●
Must
●
Should
●
Could Density
●
Won't
Capacity

58. MoSCoW
●
Must
●
Should
●
Could Density
●
Won't

59. MoSCoW
●
Must
●
Should
●
Could Density
●
Won't

60. MoSCoW
●
Must
●
Should
●
Could Density
●
Won't

61. MoSCoW
●
Must
●
Should
●
Could Density
●
Won't

62. MoSCoW
●
Must
●
Should
●
Could Density
●
Won't

63. Kano Model

64. Kano Model
●
Basic functionality
●
Performance
●
Exciters

65. Kano Model
●
Basic functionality High Satisfaction
●
Performance
●
Exciters Exciters
Performance Feature
Present
Feature
Absent
Basic
Low Satisfaction

66. Earn their trust, then get agile

67. Earn their trust, then get agile
●
Low risk, fixed price
to start

68. Earn their trust, then get agile
●
Low risk, fixed price
to start
●
Create a roadmap

69. Earn their trust, then get agile
●
Low risk, fixed price
to start
●
Create a roadmap
●
Move to sprint-based
work

70. Gamble with Planning Poker

71. Gamble with Planning Poker
●
The whole team
makes the
commitment

72. Gamble with Planning Poker
●
The whole team
makes the
commitment
●
Combines
independent
estimates and review

73. And now mistakes during projects

74. Lose track of time

75. Lose track of time
●
Developers hate
time-tracking

76. Lose track of time
●
Developers hate
time-tracking
●
Automate if you can

77. Lose track of time
●
Developers hate
time-tracking
●
Automate if you can
●
Include it in
stand-ups to update
the burn-down

78. Estimate bugs

79. Estimate bugs
●
“Nein, nein, nein! Das
ist verboten!”
-- @dzuelke

80. Estimate bugs
●
“Nein, nein, nein! Das
ist verboten!”
-- @dzuelke
●
You do not know the
size of the problem

81. Estimate bugs
●
“Nein, nein, nein! Das
ist verboten!”
-- @dzuelke
●
You do not know the
size of the problem
●
Spend 3 days
investigating –
change 1 line of code

82. Try to catch up

83. Try to catch up
●
[wo]man up and
admit you're wrong

84. Try to catch up
●
[wo]man up and
admit you're wrong
●
Don't burn yourself
or your team out

85. Try to catch up
●
[wo]man up and
admit you're wrong
●
Don't burn yourself
or your team out
●
Work overtime and
you set a precedent

86. Skip the review

87. Skip the review
●
Make time to learn

88. Skip the review
●
Make time to learn
●
Share your mistakes,
so others avoid them

89. Questions?
●
Feedback
http://joind.in/6321
(don't make me send the clown)

90. Credits
●
All sculpture/photos
© Tamra Kohl
http://www.flickr.com/photos/claylindo/
(Used with kind permission)
●
Thank you!
●
Photo jiggery-pokery:
http://pixlr.com/o-matic/
●
Background:
http://www.colourlovers.com/pattern/635/Death_Flowers