Slides from my workshop as facilitated at the 2017 Music City Agile Conference in Nashville, Tennessee. https://2017.musiccityagile.org/schedule/the-noestimates-game

1. sponsor slide

2. @mattphilip

3. Big Picture
• Objective: Learn what and how much different factors influence delivery time and
understand options for forecasting
• Complete work cards to deliver the most value!
• Play in “day” rounds
• Teams play independently but have interdependency with other teams
#MusicCityAgile @mattphilip

4. • Cards depict the work needed
• Circles represent effort to complete
• Work must be started sequentially
(no peeking!)
• Some cards are urgent!
• Some have a dependency on another team
The Work
#MusicCityAgile @mattphilip

5. The People
• Each person can do 4 points of effort per day.
(Use cubes to keep track.)
• People can work in areas outside their
specialty, but they get only half the points.
• If you work on more than one team in a day,
you lose one point per extra team (context-
switching penalty).
#MusicCityAgile @mattphilip

6. Staff Your Teams!
• Divide into teams of 4-7 people –
they do not all have to be same size
• Decide as a group each player’s role
(wear a “role” name tag)
• You can share people across more
than one team.
#MusicCityAgile @mattphilip

7. Team Dependency
• Some cards have a dependency on another team.
• When you start a card that has one, draw a team
card to see which team it is dependent upon.
• To complete the card, someone from that team
must spend time helping you. (Time spent helping
another team counts against that person’s
capacity.)
#MusicCityAgile @mattphilip

8. Blockers
=
Beginning of Next Day
For each blocked card, roll the die.
= still blocked (no work can be done on it that day)
= unblocked (remove the sticky, continue work)
End of Day
• For each card in progress, roll the die.
#MusicCityAgile @mattphilip

9. Deployment
• For each card whose deployment work is complete,
roll the die at the end of the day.
• If you roll 1, the card requires rework. Move the
card back to Deployment and redo the Deployment
work.
=
#MusicCityAgile @mattphilip

10. Daily Actions
Pull in as many cards as you want and record the day for commit date
Decide how to use each person’s effort for the day
Roll to resolve any blocked cards
Tick off work on the cards and move them accordingly
Roll die for any completed card to determine if it deployed (1 = rework)
and record the day delivered
For each card in progress, roll die to determine if it’s blocked (1 = blocked)
Update the day tracker and draw an event card.
#MusicCityAgile @mattphilip

11. Scoring
Scoring is based on how long it takes you to deliver each card:
• 1-2 days: $700
• 3-5 days: $400
• 6+ days: $200
• Urgent: -$100 per day
Before we start, we need an estimate!
• Backlog = 25 cards
• Average effort per card = 21
Car
d #
Commi
t Day
Deliver
y Day
Deliver
y Time €
Prob.
Forecast
(50%/85%)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Estimate for Total Project: Day
Estimate for MVP (#1-11): Day
Re-Estimate for Total
Project: Day
#MusicCityAgile @mattphilip

12. After you complete 10 cards: Stop!
And ask the facilitator to visit your table.
=
#MusicCityAgile @mattphilip

13. Debrief
#MusicCityAgile @mattphilip

14. ”Poor Estimation Skills”
We need to find ways to accurately forecast (or remove) the non-
work time influenced by the entire system. -- Troy Magennis
#MusicCityAgile @mattphilip

15. Do You Assume Correlation?
Is the initial sizing a good predictor for when you can get your stuff?
In our case, the surprising truth was ”no.”
-- Mattias Skarin, Real-World Kanban
#MusicCityAgile @mattphilip

16. What’s Going On?
Low process efficiency (typically 5-15% in
software delivery) means that even if we
nailed the effort estimates … we would be
accurately predicting 5-15% of elapsed
delivery time!
-- Troy Magennis
#MusicCityAgile @mattphilip

17. Other Sources of Variation
Often system factors account for more of the elapsed delivery time than different
story sizes.
-- Troy Magennis
#MusicCityAgile @mattphilip

18. Sources of Variation
How many can you name?
#MusicCityAgile @mattphilip

19. Sources of Variation
#MusicCityAgile @mattphilip
• WIP
• Technology/domain/product
• Team composition
• User, client and client representative
• Multitasking/focus factor
• Market and competitors
• System dependencies
• Team dependencies
• Specialization
• Waiting for availability
• Rework
• Steps/handoffs (50%*50%*50%...)
• Stages in team development
(Tuckman)
• Selection policy
• Essential complication (How hard a
problem is on its own)
• Accidental complication (“How much
we suck at our jobs” -Rainsberger)

20. First, Know Where You Are
#MusicCityAgile @mattphilip

21. Keogh’s “Scale of Ignorance”
1. Just about everyone in the world has done this.
2. Lots of people have done this, including someone on our team.
3. Someone in our company has done this, or we have access to expertise.
4. Someone in the world did this, but not in our organization (and probably at a
competitor).
5. Nobody in the world has ever done this before.
#MusicCityAgile @mattphilip

22. What Can You Do About Variation?
How many remedies
can you name?
#MusicCityAgile @mattphilip

23. What You Can Do About Variation
• Lower WIP
• ConWIP/System WIP
• Five Focusing Steps
• Blocker clustering
• Reduce workflow stages
• Explicit policies
• Cost of Delay scheduling, sequencing and selection
Lean-Kanban
#MusicCityAgile @mattphilip

24. What You Can Do About Variation
• “Agile 101” (simple, decoupled design; thin vertical slices; pairing)
• Identify/make visible/measure dependencies
• Collaborate/Share work (Dimitar Bakardzhiev)
• Spike and stabilize (Dan North)
• Reduce accidental complexity (Liz Keogh)
Team
Why?
#MusicCityAgile @mattphilip

25. NoEstimates and the Business
• Determine what actions would be different based on the estimate
• Customer-based fitness criteria
• Budgeting: Team run rate
• Focus conversation on value, not cost
• MVP and product ownership
• Create probabilistic forecast ASAP (as soon as you have data) – together!
• Service-Delivery Reviews
• Teams: Keep teams together, dedicated (reduces context-switching, Tuckman stages)
#MusicCityAgile @mattphilip

26. The Spectrum of Estimating
Never
Estimate
Anything
Always
Estimate
Everything
Question purpose of estimating
Include all sources of variation
Focus on characterizing work
Probabilistic forecast
Use delivery data
Less effort spent
Estimation culture
Consider effort only
Deterministic forecast
Use intuition
Heavy effort involved
Tasks in hours
#MusicCityAgile @mattphilip

27. Why NoEstimates?
Even in projects with very uncertain development costs, we haven't found that those costs
have a significant information value for the investment decision…
The single most important unknown is whether the project will be canceled. …The next
most important variable is utilization of the system, including how quickly the system rolls
out and whether some people will use it at all.
--Douglas Hubbard
#MusicCityAgile @mattphilip

28. What NoEstimates is not saying
• You are evil if you estimate
• All estimates are totally useless
• Stop doing your successful estimating practice
• Stop having the conversations to understand/analyze/break down work
• Work items must be the same size
• You must place your full faith and confidence in Monte Carlo forecasts
#MusicCityAgile @mattphilip

29. What NoEstimates is saying
• Know why you are estimating
• Discover for yourself how good you are at estimating (measure)
• Keep doing the things that help you understand the work
• Upfront estimates need to be held loosely
• If you focus on delivering value quickly, you obviate the need for Iron Triangle
considerations
#MusicCityAgile @mattphilip

30. NoEstimates, Manifesto Style
… We have come to value:
Probabilistic over Deterministic
Delivery time over Development time
MVP scope over Full scope
Data over Intuition*
Reducing sources of variation over Improving estimating
That is, while there is value in the items on the right, we value the items on the left more.
*Neil Killick uses “empiricism over guesswork”
#MusicCityAgile @mattphilip

31. #NoEstimates = No (Effort) Estimates
• Estimating with minimal effort
• Not basing our estimate on effort
-- Dimitar Bakardzhiev
We need to find ways to accurately forecast
(or remove) the non-work time influenced by
the entire system.
-- Troy Magennis
#MusicCityAgile @mattphilip

32. Better Questions to Ask
• “In what context would estimates bring value, and what are we willing to do about it
when they don’t?” – Woody Zuill
• “How much time do we want to invest in this?” – Matt Wynne
• “What can you do to maximize value and reduce risk in planning and delivery?” – Vasco
Duarte
#MusicCityAgile @mattphilip

33. References, Tools and More Info
#MusicCityAgile @mattphilip
• noestimatesbook.com (Vasco Duarte)
• focusedobjective.com (Troy Magennis)
• actionableagile.com (Dan Vacanti)
• infoq.com/articles/noestimates-monte-carlo (Dimitar Bakardzhiev)
• priceonomics.com/why-are-projects-always-behind-schedule
• scrumandkanban.co.uk/estimation-meets-cynefin
• mattphilip.wordpress.com/noestimates-game
• kanbanize.com
• ronjeffries.com
• lizkeogh.com
• neilkillick.com
• zuill.us