The document discusses estimates and managing uncertainty in projects. It argues that estimates are often blamed for project failure, but the real issue is variance between estimates and actual outcomes. The document advocates for keeping work items small to reduce uncertainty and variability. It suggests splitting work into predictable chunks and using frequent learning from small changes to continually improve estimates. An activity demonstrates that humans can more accurately estimate small numbers of items. The key takeaway is to keep tasks, batches, cycles, timescales, changes, and planning small to reduce context switching costs and improve predictability.

1. What’s Wrong With Estimates?
A Journey with LEGO and Maths

2. In My World (Agile-EA)

3. In My Head (Helpful?)

4. …And It Works!
Example: Custom Load
Balancing Algorithm in
2000
Focused on computational
cost of calculating
Averages <- SERIOUSLY!!

5. …And It Works! (Contd)

6. Healthy Respect for New Stuff!

7. Estimates
• Traditionally Blamed for Project Failure
• We Don’t Like Being Held to Them
• Blame Ensues
– “You told me it would take this long” (external)
– “I failed to hit my own deadline” (internal)

8. However, Estimates…
• Never Killed A Project!
– Variance Between Estimate & Actual Time/Cost Killed it!
• Set Expectations
– Uncertainty & Stakeholder Expectation Badly Managed
• Deliver one ‘half’ of Value Equation
– Like it or not, cost is the other
• Salaries, Recruitment, Capex, Opex, SaaS…
• Stakeholders Don’t Understand Variance
• Larger Estimates = Uncertainty Higher
• Humans Better At Smaller Estimates!

9. ACTIVITY: Audience Participation
• Score-sheet Coming
Round
1. Shown Patterns of Red
Dots for 2 seconds
2. Count/Estimate
Number of Dots
3. 5 Second Countdown
4. This will be repeated
10 times
5. Swap Scorecards &
Total Results
Yes, there is 3!

10. Question 1

11. 5
4
3
2
1

12. Question 2

13. 5
4
3
2
1

14. Question 3

15. 5
4
3
2
1

16. Question 4

17. 5
4
3
2
1

18. Question 5

19. 5
4
3
2
1

20. Question 6

21. 5
4
3
2
1

22. Question 7

23. 5
4
3
2
1

24. Question 8

25. 5
4
3
2
1

26. Question 9

27. 5
4
3
2
1

28. Question 10

29. 5
4
3
2
1

30. End of Activity
(You can now relax)

31. Relevant Concepts…
• Humans Naturally Remember (& Process) 5 to 9
items
– More Leads to Confusion & Complexity
– Less and You’re Easily Confused :o)
– Stories of 8+ Points Need Breaking Down
• Regularity Makes Estimates Easier
– Low/Zero Variance
– Use Lessons Learned/Code Libraries As-is
– e.g. Squares Easiest to Estimate (measure one side
and square it)

32. However…
• Coder’s World is [Mostly]
Uncertain!!
• Regularity Doesn’t Exist!
– No two projects/Components
are exactly the same.
• Usually > 9 items of
ANYTHING
– Components
– Classes
– Methods
– Lines of Code
• Continually look at points
distribution! Or do ‘1-point’
stories (e.g. #NoEstimates)
Time
Frequency
Actual Client Data

33. Tackling Uncertainty
• Split into Predictable Chunks, Then Aggregate
• Use Small Chunks - Lowers Variability (& Confusion)
• Beware Relationships! Any Relationship is Complex! Especially if Shared!
• Use what you know as a baseline and LEARN!
• = More ‘Accurate’ Delivery!
4 = 14,
4
3
3
= + = 10
9 1

34. Cone of Uncertainty
Large Chunk Project
(BDUF/RUP) = Long
Feedback Cycle. Slow
journey to certainty
Small Chunk Project
(Sprint/Iteration) =
Frequent Learning, Moves
towards Certainty,
Descends Cone Faster
Predictability
Time
Uncertainty Curve
KEY

35. So, Get Feedback Fast!
• Make Small Changes
• Change one thing!
• Deploy & Evaluate Efficacy
Bigger Tasks Lose Accuracy, Reduce Certainty
and ‘Quality’ of Knowledge!

36. Which Looks More Accurate?
Hamley’s Queen Ethar’s Lego Queen
OR

37. Small tasks, small batches, small cycles, small timescales, small change,
small planning…
TAKEAWAY: KEEP STUFF SMALL!

38. BUT…

39. ACTIVITY: Can it be Too Small?
Team A: 2 Dev + Product Owner
• 8 sticks x 5 blocks each
• Each block is a task
• Each task
– Pull in stack
– Take 2 blocks from stack
– Place into ready
• Pay Per Delivery
Team B: 4 Dev + Product Owner
• 8 sticks x 5 blocks each
• Each block is a task
• Each task
– Pull in stack
– Take 1 block from stack
– Place in ready
• Pay Per Delivery
Question: Who Wins? Why?

40. Beware Context Switching
• What are context
switches?
– Task Done that Doesn’t
Add Value!
• The ‘Zero’ cost switch…
– …Doesn’t exist!
• Switching yourself
between tasks…
• But what else?
Tasks Between Stages!!
– Columns, People,
Boards…
Total Replatforms
Large Business Pivots
Mass Change
Programmes
Entire Codebase Rewrite
…

41. Small tasks, small batches, small cycles, small timescales, small change,
small planning…
TAKEAWAY: KEEP STUFF SMALL!
(INCLUDING CONTEXT SWITCH COST)

42. Thanks for Watching
Links
Kanban Simulator
http://www.kanbansim.org/
Queuing Theory
http://en.wikipedia.org/wiki/Queueing_theory
Attribution
All images courtesy of Google images and are the property of their respective owners
Ethar Alali @EtharUK @Dynacognetics
Managing Director & Chief Architect
Polymath-MathMo. Programming since 9 years old. TOGAF 9 Certified, change
agent.
Blog: GoadingtheITGeek.blogspot.co.uk
About Me
Managing Director/CEO of Dynacognetics.
Specialist Agile-EA, ICT Strategist & Advisor.
Member of HiveMind Network.
Accredited Growth Voucher Advisor
certified to deliver IT & Web Growth
Consultancy to SMEs and Startups as part of
the government’s Growth Voucher Scheme.
Accreditations & Associations

43. Q & A