Professional Documents
Culture Documents
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.
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
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-
Further Reading
28 thoughts on
#NoEstimates Part 1
Doing Scrum Without
Estimates
August 14,
2013 at 2:24
pm
Glen B.
Alleman
December
18, 2013 at
12:52 pm
David Lowe
Neil
Killick
December 19, 2013 at
2:48 am
Thanks for your
comment, David.
Pingback:
|
April 27,
2014 at 6:12
pm
Julie Gueho
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.
December
15, 2014 at
8:10 pm
Suamere
December
30, 2014 at
1:54 pm
Dave
Pingback: