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
“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”
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.
Why use a
● 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
Why use a
● 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
Slicing creates options
● Exposes goals from solutions and vice versa
● Slices not necessarily “smaller” than thing we
sliced, but multiply our options
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
Choosing what to do
Freq back loop
+ Team(s) if
What is and isn’t estimating,
given people form and act on
expectations of an uncertain
future every day?
● 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
○ 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
Why would we choose not to
judge likely outcomes if
worthwhile human endeavours
necessarily carry risk?
● #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
If we elect not to take on the
risk of predicting an uncertain
future, who do we think should,
● We should embrace the delicious uncertainty of software, be
excellent in what we do and aim to delight rather than “meet
● 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
Off the shelf library software
We could try building our own at
$2,500/day but might fail.
What should we do?
● 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?
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?
Neil Killick, Agile Coach / Trainer
neilkillick.com / iterative.com.au
Copyright Neil Killick, Iterative, 2013