My talk at Agile Singapore and Agile Scandinavia.

1. to Agile
natives
Alter
and...
timation
Es
the
#NoEstimates
debate
Neil Killick, Agile Coach / Trainer
neilkillick.com / iterative.com.au
Copyright Neil Killick, Iterative, 2013
neil_killick

2. What isWHAT IS
#NoEstimates?
Like “Agile”, it has come
to have many definitions
and interpretations.

3. Birth of #NoEstimates
A conversation, started
on Twitter, about ways
in which software can
be delivered with no
estimates.

4. What drove the debate?
A collection of opinions
and practical advice
from practitioners who
deliver software with no
estimates.

5. It’s now become...
A diverse and much needed
debate about when it is
appropriate to use estimates
in software, and what form
these should take.

6. The #NoEstimates Crew
Woody Zuill
Neil Killick
Vasco Duarte
Chris Chapman
Henri Karhatsu

7. Common Ground
WHAT IS
EMBRACE AGILE PRINCIPLES
FOCUS ON VALUE
DELIVER SMALL SLICES
DELIVER EARLY & FREQUENTLY
CUSTOMER COLLABORATION

8. 3 E’s of #NoEstimates
thics
mpiricism
mergence

9. ETHICS - Cycle of Mistrust
Deliver the wrong
thing, or late
Trust breaks
down
Focus on
schedule
Commitments of
scope and time

10. EMPIRICISM - Working software
allows us to monitor progress and
manage risk in a new way.

11. EMERGENCE
of cost and
value as
we get
feedback
from users
and market.

12. Predictability
Which is more
predictable -A team that estimates or
one that doesn’t ?

13. Team #Estimates
DETERMINISTIC AND REACTIVE
FOCUS ON SCHEDULE / PLAN
SCOPE DRIVES DECISIONS
LOTS OF WIP IN ATTEMPT TO “GET IT ALL
DONE”
● NO METRICS, OR INAPPROPRIATE ONES
●
●
●
●

14. High variability
12 days
1 Day

15. Team #NoEstimates
●
●
●
●
●
PROBABILISTIC AND PROACTIVE
FOCUS ON TIME AND CASH CONSTRAINTS
ITERATE DESIGN AND DECISIONS
DELIVER WITH FLOW / LIMIT WIP
ACTIONABLE METRICS (e.g. STORY CYCLE
TIME DISTRIBUTION) USING A “SLICING
HEURISTIC”

16. Better Predictability
3 days
1 Day

17. What’s a
TM
“Slicing Heuristic ”?
● EXPLICIT POLICY FOR BREAKING DOWN WORK AND
MEASURING HOW LONG IT TOOK (CYCLE TIME)
● STARTS AS A SHARED DEFINITION OF WORK TYPES
(e.g. THEME, FEATURE, STORY, etc.)
● SLICE ALL UPCOMING WORK SIMPLY AND
SYSTEMATICALLY FOR “SMALL-NESS”

18. Example Max 1 User Scenario
● Given Bob is a registered user,
When Bob logs in
Then he should be logged in.
● Given Bob is logged in,
When Bob chooses Profile
Then he should see his profile.

19. Slice into
2 separate stories

20. Slice those stories
further

21. Why use a
Slicing Heuristic?
● Agility relies on small chunks, so useful to have a
consistent and explicit way of creating them
● Improve ready-ness and done-ness
● Focus on delivering more frequent slices of value
● No need to explicitly estimate or re-estimate

22. Why use a
Slicing Heuristic?
● Story points are ambiguous, time isn’t
● Explicit policy, so can be inspected and adapted
to narrow control limits
● Outliers can be addressed at standup or retro

23. Slicing creates options
● Exposes goals from solutions and vice versa
● Slices not necessarily “smaller” than thing we
sliced, but multiply our options

24. Portfolio #NoEstimates
KEEP TEAMS TOGETHER
ENABLE CONTINUOUS DELIVERY
NO LONG PROJECTS / PROJECT THINKING
DRIP FUND (MULTIPLE OPTIONS)
BUILD THINGS ON DEMAND, DELIVER AS
SOON AS THEY ARE READY
● FLEXIBLE CONTRACTS
●
●
●
●
●

25. Choosing what to do
Present a
business case
Is initiative
still valuable
enough?
YES
NO
Stop
Approved as
viable option
Timeboxed
experiment
y
eliver
d
uent
Freq back loop
feed
&
+ Team(s) if
required
Initiative
prioritised
Team assigned

26. Scaling up and down

27. Questions

28. Question 1
What is and isn’t estimating,
given people form and act on
expectations of an uncertain
future every day?

29. Answer 1
● Estimating = Giving ranges of actual or relative time based on
past observation, WIP, team size, etc.
● Guessing = New teams, with competing priorities, asked to
give single dates in unfamiliar domains
● There is nothing intrinsically wrong with estimating, so long
as we:
○ Understand its limitations
○ Use it only in appropriate situations
○ Don’t rely on it for big up front decision making
○ Update our estimates (and everyone’s expectations)
based on real data frequently

30. Question 2
Why would we choose not to
judge likely outcomes if
worthwhile human endeavours
necessarily carry risk?

31. Answer 2
● #NoEstimates is about alternatives to estimating the cost of
delivering software, not the value it generates
● We must hypothesise (estimate) the value of things in order
to decide if we will pursue them
● My argument is that rather than estimate cost we can control
(fix) it in “drips” using fixed Agile teams
● Delivery of working software allows us to reassess value
iteratively based on the reality of user / stakeholder feedback
and market conditions

32. Question 3
If we elect not to take on the
risk of predicting an uncertain
future, who do we think should,
and why?

33. Answer 3
● We should embrace the delicious uncertainty of software, be
excellent in what we do and aim to delight rather than “meet
requirements”
● Software products and services have ongoing value, so the
final cost and value can never be known up front
● We can’t fix price and scope, but we can work collaboratively
and continuously with our customers to build the best
possible result for budget or time constraint
● We can provide flexible pricing and termination options to
our customers based on similar past work

34. Question 4
Off the shelf library software
costs $50k.
We could try building our own at
$2,500/day but might fail.
What should we do?

35. Answer 4
● Answer depends on many things like whether we have an
established team, are we capable of delivering features every
few days, etc.
● Need to establish the problem rather than decide between
solutions; Do we need the software at all?
● What are the consequences of spending more than the OTS
product costs? Is the $50k a constraint?
● How would ongoing maintenance costs compare?

36. Answer 4 (contd)
● 4 weeks not far into the future, so probably have
an instant sense of “Is it possible?” and
“Can we build something better?”
○
○
○
○
Do we know enough about the domain?
What are minimum features we need?
How many people do we have?
Do we have any other WIP?

37. Neil Killick, Agile Coach / Trainer
neilkillick.com / iterative.com.au
Copyright Neil Killick, Iterative, 2013
neil_killick