1. The art
(and science) of
software estimation
Otto Coster
Van Lanschot Kempen

2. • Why is it so hard?
• Common pitfalls
• The estimation game
• Proven methods
• Becoming better at estimation

3. The hardest part of
software development?

5. Hofstadter’s Law: “It always takes longer than
you expect, even when you take into account
Hofstadter’s Law.”

6. Why is it so hard?

7. Known knowns
• Tapped knowledge
• Requirements
Known unknowns
• Risks
Unknown knowns
• Untapped knowledge
Unknown unknowns
• New software features

8. Common pitfalls

14. The estimation
game

16. Task A
Estimate: 3 points
Team has done already ten times in
the past
Task B
Estimate: 3 points
Never done before, or it has unclear
interdependencies

17. What estimates actually are:
they are not single numbers
but big blobby things with
uncertainties, assumptions,
and constraints

18. 8x 2 point stories
vs.
2x 8 point story

19. Proven methods

22. Breaking things
down

27. Balancing
refinement and
development

31. Estimate too low?

33. Poker points
are relative

34. 0
1
2
3
4
5
6
7
8
9
1 2 3 5 8
0
5
10
15
20
25
30
35
40
1 2 3 5 8 13 21 34

35. Use anchor stories
• Define a 1, 5 and 13 point story
• Relate (or categorize) every story to these
anchors

36. Conducting a
premortem

38. Excersise

39. A private banking
customer wants to
buy some
Lockheed Martin
stock options via
Van Lanschot
Kempen.
How can it fail?

40. Restricted stock
Not enough balance
eXimius is down
Bankview is down
Wrong type of investment account
No rights to order online
No rights to order options
Does not fit in the customer’s risk profile
VLK doesn’t offer the stock anymore
Stock exchange is closed

41. Estimating better
• Do a premortem when refining
• Break things down
• Estimate further up the hill
• If you are early on the hill:
• Add more points for uncertainty
• OR spent more time on refinement
• Use anchor stories
• Expand your Fibonacci range

42. Estimating better
• Look beyond just the code
• Testing risks
• Remember test environment unavailability or test data issues
• New technology risks
• Integration risks
• Tech debt / refactoring risks
• Non-functional requirements
• Performance, security, availability

43. Estimating better
• Push the scariest work uphill first
• Recognize your own biases: what do you generally underestimate?
• When is it really Done?
• Agile cycle: define new user stories with findings

44. Thank you