You are on page 1of 19

neilkillick.

com
Shi!ing conventional thinking to the right with Agile and Lean

#NoEstimates Part
1 Doing Scrum
Without Estimates
January 31, 2013

#NoEstimates,

Agile

Introduction
This is the first in a series of essays exploring the
huge topic of estimation within so!ware development projects.
There are many di"erent contexts in which estimates are given, and I am going to try and cover
o" as many as I can think of in these blogs, but
the pattern of my argument will remain consistent: I believe we ought not make decisions in
so!ware projects based on estimates and that

there are better alternatives for both the suppliers of so!ware products (financially and ethically) and their customers (internal and external).
Many of these alternatives are being used in real
companies delivering to real customers with
great e"ect.
Given the vastness of the topic, this post focuses
purely on the scenario of one Scrum (or other
method of iterative product development) team
delivering a so!ware product without estimating.
Issues of scaling up or down capacity (adding or
removing teams) will be covered in a later post
about estimating at the portfolio level.

Will we deliver on time?

This is a question that o!en gets asked of a so!ware development team at the beginning and
throughout a project, and is a key reason why
many believe we need to estimate. However, the
ironic twist of seeking predictability by making
predictions based on guesses is not lost on most
people. We all know, or at least suspect, that
were plucking numbers out of thin air. That we
dont yet know or understand the solution. Or the
domain. We comfort ourselves by calling our
guesses educated or quick and dirty, to justify
our using them to make important business decisions.
Building so!ware is by its very nature unpre-

dictable and unrepetitive. While building so!ware we cannot easily break down the work into
same-sized, repeatable widgets like we can when
manufacturing car parts. Unlike car production,
the exact product we are building is unknown until weve built it, so how can we break the work
down into smaller parts up front? One increment
of so!ware is not like the next. So!ware development is a creative, variable pursuit, and solutions
are o!en revealed as we go along. For this reason,
fixing scope in so!ware projects is not really possible. Even if it were, it is becoming widely accepted that attempting to do so is undesirable
because such an approach does not allow for (or,
at least, does not embrace) emergent design, requirements, change and innovation. If we accept
that scope is always variable, we must also accept that the delivery date may end up as a moving goalpost while we scamper to deliver what we
think is fixed scope on time and on budget.
So, if it is true to say the concepts of on
time and on budget are usually based on an
estimate of how long it will take (and how much it
will cost) to build so!ware to meet a fixed set of
requirements, rather than a concrete time or
budget constraint, it is likely fair to say that we
may take longer to deliver the so!ware than we
initially estimated. Yes, we may also be quicker
than we thought. Or we may get our estimate just
right. But, regardless of the outcome, does it actually matter how correct our estimates were?
Does the act of estimating our work have any impact at all, positive or negative, on the delivery of
great so!ware or its return on investment?

Vision is key

To build so!ware we need a clear vision and


shared purpose of what success looks like. When
commencing with a potentially valuable so!ware
initiative we need well understood high level
goals, not the detail of how we will achieve those
goals. In true iterative fashion we can then align
our just-in-time decisions about how we will improve the product in the next iteration (i.e. what
we will build next, aka top items in the Product
Backlog) with these goals. I posit that trying
to estimate how long it will take to deliver so!ware to achieve one or more high level goals, and
then basing real decisions on this estimate, is a
questionable approach. Dont we want our solution and architecture to emerge? Dont we we
want to welcome and embrace changes for the
customers competitive advantage as the product
evolves and becomes more real to the users?
These are key principles in the Agile
Manifesto and I believe they lie at the heart of a
truly Agile approach to building so!ware.

Remove the unknowns

Instead of depending on an accurate estimate for


predictability we can take away the unknowns of
cost and delivery date by making them well,
known. The Product Owner can fix the delivery
date based on a concrete budgetary and/or time

constraint (e.g. 3 days before the Australian Open


starts for the Australian Open app is a concrete
time constraint, and we have to build something
for $30,000 is a concrete budgetary constraint).
Within that constraint the team can then fix incremental delivery dates (e.g. end of every Sprint) to
allow focused e"ort on iterative product evolution (its not good to have priorities changing
every day on a whim) andprovide the opportunity
to deliver early and/or under budget. This approach is also useful where there is no concrete
budget or delivery date, although the need for
interim release dates diminishes if the team (and
organisation) is mature enough to have a continuous delivery model.

Estimating sprint velocity


is waste

Rather than fix the solution up front (which is required in order to give a how long estimate), or
make forecasts every Sprint about how many
points or stories will get done, I believe teams
ought to commit at the outset to building and delivering the best possible product by a given date
and/or for a given amount of money. For me, release planning using, e.g velocity (how many
points can we deliver by the release date?,
or what is our release date given our remaining
scope and velocity) is contrary to an iterative ap-

proach (holistic, evolutionary improvement of


the product) and is more in line with a purely incremental approach (delivering a pre-defined
Product Backlog feature by feature).
When we estimate and use velocity as a planning
tool we are making an assumption of how much
can get done in a time period. For that information to be useful and meaningful we need to have
an amount of stu" in mind that we want to deliver (i.e. a fully estimated Product Backlog). I dont
think it would be too controversial to suggest that
all the time (and therefore $$$) spent on estimating backlog items that do not end up getting delivered is waste (at least in the Lean sense).
But what about all the time and $$$ spent on estimating backlog items that do get delivered? To
answer that question, I will ask one more question: Did the PO ever prioritise one story over another based on it having a lower estimated cost
(story point size)? If the answer to this question is
No then I conclude that all estimating in this
context was waste because no decision was made
based on the estimates that were given (instead
the PO simply prioritised the highest value stories). If, however, the answer is Yes then estimates controlled what I believe should be valuebased decisions. Estimating a backlog up-front
and then release planning using velocity is a costbased approach. While costs are obviously important in running a so!ware project and, indeed, a
business, if decisions are made purely on cost
then some of the great so!ware we use and rely
upon today (e.g. much of what is made by
Google, Facebook, Apple, Yahoo, Spotify, etc.)
would never have been built and we would have
one explanation as to why there is so much crap,
expensive, bloated so!ware in the world.

Iterate, dont estimate

I believe iterative (Agile) development is 100%


about making decisions based on customer
and/or business value, using empiricism over
guesswork and fixing cost by having a fixed team
(a la the Spotify squad model) with known
timeframes (frequent, predictable release
dates as opposed to deadlines, which are release dates for fixed scope based on imaginary
constraints). Knowing our costs and delivery
dates gives us certainty which allows us to embrace the delicious uncertainty of building great
so!ware.
btw Having a fixed delivery date doesnt mean
that we will necessarily stop building our product
on the delivery date. We may have already
stopped or we may choose to continue. What it
does mean is that we will continually make
go/no-go decisions based on the emergent or potential value of what we are building rather than
estimating the cost of a particular solution.

Shift focus to small

From the teams point of view, I believe it is far


more valuable to get better at breaking down stories JIT (and only JIT any earlier is potentially
wasteful) to be as small as possible (or, at least,
as is practically possible) than to increase velocity. For me, a high-performing team has the ability to deliver frequent done increments to the
product that can derive immediate feedback
and/or potential value for those using it. Clearly
the smaller the increments the more frequently
delivery can happen, which leads to shorter feedback loops and increased learning and flexibility
for the PO to prioritise emergent features over
features she originally thought she wanted/needed that have diminished in value, or even take a
complete change in direction. This, in my opinion, is far more in tune with true business agility.
The importance of how many stories or points
gets delivered in a Sprint becomes truly insignificant when the team is delivering frequent
changes to the product and putting them in the
hands of users. This, for me, is the crux of why
so!ware projects are trying to embrace an Agile
approach. But until the estimation stops I believe
were being held back from true high performance which can deliver awesome outcomes for
customers.

Further Reading

Splitting user stories by the quality of solution Neil Killick


What price estimation? Neil Killick
Should we estimate so!ware projects
at all? Neil Killick
If you found estimates bring no value
what would you do? Woody Zuill
A thing I can estimate Woody Zuill
Can we code without estimates? Woody
Zuill
Story points considered harmful or why?
Vasco Duarte
Stop using story points Joshua
Kerievsky

28 thoughts on
#NoEstimates Part 1
Doing Scrum Without
Estimates

Pingback: #NoEstimates Part 2 Contract


Negotiation and the Old Banger | neilkillick.com

August 14,
2013 at 2:24
pm

Glen B.
Alleman

All famously good stu". My


hands on example is with
PayPal and their approach
to delivering features
needed by the business on
short cycles to handle the
completely unpredictable
demand from the market.
On our flight avionics
systems, the iterations are
larger, but the instability
of the requirements is the
same. The total mission of
manned space flight has
changed 3 times over the
life of the Orion program.
Rolling Waves, iterative
work packages, 44 day
deliverables, astronauts in
the same building as the
engineers.
But in the end all projects
have a budget and the
business people need to
know what they are going
to get for their budget.
PayPal does an annual
budget for the operating
baseline, then teams
commit to development
within that budget on fine
grained cycles. They are
essentially doing what you
describe in principle.
Same for flight avionics.
Teams get a budget
flowed down from NASA
for, then partition the
work into chunks (work

packages of similar size),


execute those package,
measure their productivity
(e"iciency) and use that to
confirm the next rolling
wave.
But in all cases of
spending other peoples
money (internal for PayPal
and external for NASA),
some end to end set of
needed capabilities must
be in place, otherwise no
one knows why were
doing this. And an end to
end (at least on the
budget cycle) estimated
cost, otherwise the CFO is
not going to sign o" on the
balance sheet for the
committed funds (FASB 86
rules in the states for
commercial) and
(FAR/DFAR rules for
federal funding).
The #NE approach has yet
to address any of these
governance issues, which
is why for project that
spend non-trivial amounts
of other peoples money
its simply a non-starter.

Pingback: Forecasts, Estimates and Cost


Accounting | Think Di"erent

Pingback: Sano Ei turhille tymrarvioille |


Mystes Oy

Pingback: Breaking up so!ware projects into


small, focussed milestones | Robert Daniel
Moore's Blog

December
18, 2013 at
12:52 pm

David Lowe

Did the PO ever prioritise


one story over another
based on it having a lower
estimated cost (story
point size)?
I get your point on costbased planning, but I
dont think its a bad thing
that a story might be
de|prioritised in light of
the cost of development;
sometimes there might be
10 ideas of similar value,
but the business will
choose to have the one
that costs least developed
first.

Neil
Killick
December 19, 2013 at
2:48 am
Thanks for your
comment, David.

One of the key issues I


see with the situation
you are advocating
(i.e. using a
comparison of
estimated dev e"ort to
make a go/no-go
decision) is that the
PO is trying to
calculate ROI on
something that I
believe is too granular
(a story or feature).
Not only is this
immensely di"icult to
do with any kind of
accuracy, to then
dismiss an option
because it has been
estimated as taking a
little longer to develop
than another option is
foolhardy in my
opinion.
If a few days or even
weeks of development
cost is so significant
such that an option is
borderline not worth
doing then I would
argue that the
potential value is not
great enough to make
the risk worthwhile.
For this reason, I think
if we are going to
estimate at all it
should only be at the
higher initiative level
where it is easier to
make an assessment
on which options we
will pursue. We can
also use more e"ective
prioritisation
techniques than
estimated dev e"ort,

such as cost of delay.


Another flaw in the
approach you
advocate is that we do
not know the cost of
development it is
only an estimate (and
as we know that is
usually *far* from
knowing). Even if we
did know it for sure,
the emergent value
the initiative will
generate (positive or
negative) is even
harder to estimate. We
should certainly not
assume that the R
part of ROI is going to
remain consistent to
our estimate, any
more than the I will.
My take fix I by drip
funding iterations at
the portfolio level, see
what R emerges from
the initiatives you are
investing in and make
continuous go/no
decisions at that level,
*not* at the
story/feature level.

Pingback:
|

Pingback: Being SAFe on the train | Andy Kelk

Pingback: Conference Catchup | Kurt's Blog

Pingback: Are all Models Wrong? | Principles of


So!ware Flow

Pingback: Consolidating the


#Estimates/#NoEstimates Debate | quantmleap

Pingback: Mike Laurie Agile as a mindset, not


methodology

Pingback: Estimating on agile projects: whats the


story, whats the point? | Agile Product Analysis

April 27,
2014 at 6:12
pm

Julie Gueho

Very interesting article


with lots of things to think
about. I agree that team
shouldnt spend too much
time and e"ort doing
accurate estimate because
such a thing does not
exist.
To my opinion, the main
problem is that people are
using estimate based on
the false assumption that
they are accurate whereas

they arent.
The main reason for using
estimate for me is
communication. If
developers are doing very
di"erent estimates, they
can talk about why. Same
with the PO when he finds
out that a story he
thought was really quick
and easy is actually huge.
In most of the cases, it
means that there is a
misunderstanding about
what the story actually is
and it leads to clarify the
specs and the
expectations. It allows the
team to align on what the
result should be.

Pingback: The Board - Episode 31, no estimating


and mob programming

Pingback: 5 trend z Agile Prague pro zlepen


vaich firemnch proces | IT mag - novinky z IT

Pingback: Is Estimation Really Worthwhile? |


Martin Milsom's Blog

Pingback: Tiene sentido estimar? Quiz no


deberamos estimar proyectos #NoEstimates
explicado - Javier Garzs | Javier Garzs

Pingback: No Estimates...No plan? - Infinite


Creative Alliance

Pingback: #NoEstimates Part 1 Doing Scrum


Without...

December
15, 2014 at
8:10 pm

Suamere

Though my logical brain


finds this page of your talk
as possibly true and/or
lets see what else he has
to say, its di"icult to
convince myself to
continue when the words
Agile and Iterative are
so easily exchanged and
tightly coupled. When I
think Iterative, I think
Waterfall and/or
structured releases. Agile,
Scrum, and Sprints are
supposed to be built on
change-response and
short timeframes for
potential releases for
parts (or all) of a feature.
Not saying anything is
wrong here, it just hits me
as messy an deters me
from continuing.

December
30, 2014 at
1:54 pm

Dave

I worked in one company


where estimates and costs
were not calculated we
just did what was right,
but the company did have
plenty of cash to splash.
For the rest of us doing the
thing that delivers most
value sounds attractive.
But actually for a business
it is the thing that delivers
most PROFIT that is
required. And to know the
profit you need to know
the cost. True we will
never get the cost right up
front but if I need to
decide what to build then I
need to have some idea of
the likely profit rather
than just the value. If I can
sell product A for $10 and
product B for $3 then it
makes sense to make
product A surely but if
product A costs $15 and
product B 5c to make then
it is better to produce
product B.
The biggest thing people
shy away from is telling
bosses that estimates are
just guesses, that there is
risk associated, it maybe
that it is even di"icult to
quantify the risk (although
perhaps some historical
evidence of how
inaccurate previous
guesses were might help).
The second thing people
shy away from is keeping
people informed you
know we said it would
take 12 months, well we
are now a month in and
have uncovered a few

nasties which means it is


most likely to be at least
18 months, most likely 24
months is a message no
one likes to give, but it is
better to give it than
pretend you will somehow
squeeze a quart in a pint
pot.

Pingback: #NoEstimates book summary and


commentary | Zombie Code Kill

Pingback: You Want an Estimate? Give Me Odds. |


DaedTech

Pingback:

Pingback: The Estimates in #NoEstimates | Liz


Keogh, lunivore

Pingback: In Agile SCRUM, how do you handle


even distribution of work in a sprint between
"experts"? | DL-UAT

You might also like