The #NoEstimates Debate

Neil Killick, Agile Coach / Trainerneilkillick.com / iterative.com.au neil_killick

Copyright Neil Killick, Iterative, 2013

the #NoEstimates debate

Alternatives to Agile

Estimation and...

WHAT IS

Like “Agile”, it has come to have many definitions and interpretations.

What is #NoEstimates?

A conversation, started on Twitter, about ways in which software can be delivered with no estimates.

Birth of #NoEstimates

A collection of opinions and practical advice from practitioners who deliver software with no estimates.

What drove the debate?

A diverse and much needed debate about when it is appropriate to use estimates in software, and what form these should take.

It’s now become...

Neil Killick Chris Chapman Henri Karhatsu

Woody Zuill Vasco Duarte

The #NoEstimates Crew

WHAT ISEMBRACE AGILE PRINCIPLESFOCUS ON VALUEDELIVER SMALL SLICESDELIVER EARLY & FREQUENTLYCUSTOMER COLLABORATION

Common Ground

thicsmpiricismmergence

3 E’s of #NoEstimates

ETHICS - Cycle of Mistrust

Trust breaks down

Deliver the wrong thing, or late

Focus on schedule

Commitments of scope and time

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

EMERGENCEof cost and value aswe get feedback from users and market.

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

Predictability

● 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

Team #Estimates

High variability12 days

1 Day

● 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”

Team #NoEstimates

Better Predictability

3 days

1 Day

● 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”

What’s a“Slicing HeuristicTM”?

● 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.

Example -Max 1 User Scenario

Slice into2 separate stories

Slice those stories further

● 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 aSlicing 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

Why use aSlicing Heuristic?

● Exposes goals from solutions and vice versa● Slices not necessarily “smaller” than thing we

sliced, but multiply our options

Slicing creates 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

Portfolio #NoEstimates

Present a business case

Approved as viable option

Team assignedTimeboxed experiment

Is initiative still valuable

enough?

NO

Initiative prioritised

YES

+ Team(s) if required

Frequent delivery

& feedback loop

Stop

Choosing what to do

Scaling up and down

Questions

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

Question 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

Answer 1

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

Question 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

Answer 2

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

Question 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

Answer 3

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

Question 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?

Answer 4

● 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?

Answer 4 (contd)

Neil Killick, Agile Coach / Trainerneilkillick.com / iterative.com.au neil_killick

Copyright Neil Killick, Iterative, 2013