NoEstimates - Quick Access PDF Version - Check Membership Site For All Files and An Extra Video Keynote

DO YOU WANT TO DELIVER ALL YOUR
PROJECTS ON TIME?
• Are you losing money because you deliver projects late?
• Are you frustrated and depressed at the “on-time” delivery
rate of your projects?
• Do you want to avoid burn-out and make your projects
reach the mythical “sustainable pace”?
With the #NoEstimates practices we focus on understanding

REAL progress in a project. Not the progress against an estimate,
which only tells you if you are already late or not. But the kind of
progress information that tells you WAY IN ADVANCE if you
will be late.
Are you confused by Monte Carlo simulations? Me too! They are
overly complicated to do right, and in the end you don’t have the
luxury of running the same project twice or even a 1000 times!
You need to deliver THIS project on time!
Here’s the thing, in this book I explain how to know (a long time
in advance) how to know if you are going to be late. But the key
part of the process is what you do once you
know that!
Here’s a deal. I’m offering you a free one
hour call to review your current project, and
devise a strategy to deliver it on time, no
matter what the current situation is!
The call is free, and you will get a very good
idea on how to “reign in” any project, and delivery on time.
Best case? I’ve helped my customers save millions by delivering
projects on time, and I believe I can do the same for you. But you
will see it, first-hand, in our call. If you are not convinced, no
worries! You don’t need to pay.
Worst case? You spent one hour asking questions and
understanding better progress in your project, which will help you
make the right decisions.
Schedule Your 1h Call With Me Right Now And (Potentially)
Save Thousands Or Hundreds Of Thousands In Late Projects.
PLUS: help your projects reach that sustainable pace, that ensures
you will be able to continue to deliver projects in the future
without burn-outs and loss of talent!
Schedule your call at the following link:

http://bit.ly/schedule_a_call_with_vasco
ii
NO
ESTIMATES
HOW TO MEASURE PROJECT PROGRESS
WITHOUT ESTIMATING
VASCO DUARTE
iii
NO ESTIMATES
Copyright © 2015 by Vasco Duarte.
All rights reserved. This book or any portion thereof may not be
reproduced or used in any manner whatsoever without the express
written permission of the publisher except for the use of brief
quotations in a book review.
Publisher: Oikosofy Series, www.oikosofyseries.com
Illustrations by Ángel Medinilla
Cover design by Sebastian Hermida
v
.
Welcome to the #NoEstimates book. Join the conversation on twitter
under the #NoEstimates hashtag.
This book is part of a larger project that includes video interviews with
some of the early adopters of the ideas described in this book.
Sign-up at www.NoEstimatesBook.com/print_gift to get an exclusive
essay on Capacity Planning with #NoEstimates.
Visit
oikosofyseries.com/noestimates-book-order
to find the following extra material:
Two mini e-books on contracts and planning

ü The Ultimate Guide to Capacity Planning with NoEstimates by
Tomas Rybing
ü How Much Does it Cost?: A Guide to Agile Contracts by Evan
Leybourn
The #NoEstimates Pioneers on Video:

ü Woody Zuill, the creator of the #NoEstimates hash tag on twitter
ü Neil Killick, the creator of the Slicing Heuristic, a great way to
reach #NoEstimates quickly
ü Henri Karhatsu, greatly experienced #NoEstimates practitioner
with many stories to share
Four video interviews with #NoEstimates practitioners

ü Chris Chapman, inventor of the #NoEstimates game
ü Clinton Keith, game developer using #NoEstimates in his
projects
ü Marcus Hammarberg, author of Kanban in Action
ü Allan Kelly, author and #NoProjects movement founder
Two interviews with CEO’s applying #NoEstimates

ü Sven Ditz, CEO of Sitegeist.de in Germany
ü Diego Cenzano, CEO of biko2 in Spain
Visit
to know more
vii
WHAT OTHERS ARE SAYING ABOUT
NOESTIMATES, THE BOOK
“The way this book was written helped me not only to understand the
main ideas behind #NoEstimates but to internalize the concept with the
real examples behind the story.”
– Hermes Ojeda Ruiz, LogicalBricks
“Finally! The most meaningful text book about project management and
governance! This piece of project fiction will become the real “don’t
panic” guide to project management!”
– Tapio Järvenpää, Beer Executive Officer, Hops United OÜ
"Anyone interested in deliver their projects on time should read this

book. It´ll make you forget the idea that you can predict the future with a
crystal ball. Instead of that you´ll learn to use your data and be more
effective. Take of red pill!"
– Emiliano Sutil, Project Manager al Xeridia S.L
“You’re doing it wrong. Estimates that is, and #NoEstimates tells you
why. Most importantly, however, the book tells you what you should be
doing instead. The compelling mix of theory with story means you’ll
quickly learn the lessons and start benefiting from the book. Read, think
and apply #NoEstimates today."
– Dr. Bruce Shcarlau, Senior Teaching Fellow at University of Aberdeen
“I was sold on this book after reading the table of contents of the first
chapter.”
– Nick Mein, Engineering Manager, Trimble Navigation.
“Do the most important thing is not a startup thing only! In my 15 years
of experience with software development I've seen a lot of patterns of
projects failing. I've experienced myself every example described in
#NoEstimates. I've worked for a startup, where it is obvious what's
important without estimating. With the help of the #NoEstimates book I
can do the same within a multinational corporate organization.”
– Jeroen Knoops, Software Developer
ix
CONTENTS
FOREWORD ....................................................................................... 15
THE #NOESTIMATES PREMISE ............................................................ 21
THE PROBLEM WITH ESTIMATES ....................................................... 27

DO ESTIMATES WORK? ........................................................................... 29
WHY DON’T ESTIMATES WORK? ............................................................... 33
HOFSTADTER’S LAW ................................................................................ 33
PARKINSON’S LAW .................................................................................. 34
ACCIDENTAL COMPLICATION ..................................................................... 34
MORE THAN MEETS THE EYE: WHY ESTIMATES ARE ACTIVELY HARMFUL FOR
YOUR PROJECT ....................................................................................... 37
ENTANGLED: HOW COMPLEXITY DESTROYS PREDICTABILITY ........................... 39
CHANGE REQUESTS, CHANGE EVERYTHING .................................................. 42
ALL OR NOTHING: DEATH MARCH PROJECTS ............................................... 44
IS THERE HOPE FOR SOFTWARE PROJECTS? ................................................. 46
WHAT ARE ESTIMATES? ..................................................................... 48

#NOESTIMATES AS #NOINVENTORIES ........................................................ 53
ESTIMATING VS. FORECASTING .................................................................. 55
THE IRON TRIANGLE ................................................................................ 57
THE START OF A PROJECT IS THE WORST TIME TO ESTIMATE ITS DURATION OR
COST .................................................................................................... 61
UNCERTAINTY AND BUFFERS ..................................................................... 62
CLASSIC METHODS FOR CRAFTING ESTIMATES ............................................. 65
ESTIMATING IN THE AGILE WORLD ............................................................ 69
RETHINKING ESTIMATES .................................................................... 75

THE (ALLEGED) NEED FOR ESTIMATES: DEADLINES, COSTS AND SCOPE ............ 75
WHY DO WE NEED ESTIMATES? ............................................................... 77
PROJECT DRIVEN DEVELOPMENT ............................................................... 82
SET-BASED DESIGN VS. POINT-BASED DESIGN ............................................. 85
VARIABILITY ........................................................................................... 87
ESTIMATION VS. PRIORITIZATION ............................................................... 92
SO… RETHINKING ESTIMATES ................................................................... 96
THE PREDICTABILITY PARADOX .................................................................. 97
HOW NOESTIMATES CAN HELP YOU MANAGE A PROJECT IN CRISIS 100
VISIBLE PROGRESS ................................................................................ 105
ACTIONABLE INFORMATION .................................................................... 110
WHAT ARE INDEPENDENT STORIES? ......................................................... 111
THE FAST TRACK TO NOESTIMATES ................................................. 120
SLICING USER STORIES TO ASSESS PROGRESS AND MANAGE SCOPE ............... 125
OTHER SLICING HEURISTICS .................................................................... 131
DETERMINING PROGRESS FROM HISTORICAL DATA ..................................... 135
MULTIPLE LEVELS OF GRANULARITY ......................................................... 137
HOW DO I MANDATE THE SIZE OF A FEATURE OR A USER STORY? ................. 138
WHY SHOULD I MANDATE THE SIZE OF A USER STORY OR FEATURE? ............. 140
EXTRAPOLATING FROM USER STORY TO OVERALL PROJECT PROGRESS ........... 141
1-2-3: STEP BY STEP TOWARDS #NOESTIMATES ........................................ 145
THE FIRST STEP TO DELIVER A PROJECT ON TIME IS TO RECOGNIZE
THAT WE ARE LATE .......................................................................... 150
HOW TO RECOVER FROM A LATE PROJECT? ............................................... 153
FLEXIBLE REQUIREMENTS MANAGEMENT FOR MAXIMUM SCOPE VISIBILITY .... 157
CREATING OPTIONS BY SLICING FEATURES ................................................. 164
HOW TO COMMUNICATE PROGRESS? ...................................................... 165
GAIN THE CUSTOMERS TRUST WITH ROLLING WAVE FORECASTING 168

THE NEVER-ENDING POOL OF IDEAS ........................................................ 169
REPORTING PROGRESS WITH NOESTIMATES .............................................. 170
ROLLING WAVE FORECASTING ALLOWS YOU TO ADAPT YOUR PLANS,
CONSTANTLY ........................................................................................ 175
PRESENTING THE ROLLING WAVE FORECAST TO A CLIENT ............................ 178
ACKNOWLEDGEMENTS .................................................................... 184

13
14
FOREWORD
"Transformation comes more from pursuing profound questions than

seeking practical answers."
Peter Block
I’m pretty good at getting comfortable in my ways. Perhaps we all are.

Still, I'm certain this is not a good thing so I work hard to keep an open
mind about making things better. I suspect that our biggest problems are
hidden within the things we trust the most.
A few years back I noticed there are a number of practices and
techniques used in the management of software development done "by
default". That is, we do them without question. Perhaps we assume that
this must be the "right way" since everyone does it this way. Maybe it's
how we were trained for our job, or that we've been doing it so long we
don't even remember why we started. It could be it is a practice someone
has documented in a textbook, or we learned through some training
sessions at a conference on "how to manage software development." The
problem for me isn't whether the practice is good or not, but rather that
many often accept it as the only way and don't question its applicability.
Simply following a practice or methodology by default indicates to
me that there are likely some hidden problems we might not be willing to
uncover. Are we being willfully ignorant, or are we unaware that we are
missing something here? When the feeling of control and certainty is
more important to us than knowing the truth, and the fear of change
holds us back from seeking better, it's time to do some questioning. It's
time to face our fears.
"Humans are allergic to change. They love to say, 'We've always done
it this way.' I try to fight that." - Adm. Grace Hopper
Although I love that quote from Admiral Hopper, I'm not so sure that
humans are allergic to change. I actually think we are pretty good at it,
and in some things we welcome change once we get the idea that change
is needed.
Estimates are one of those things where "we've always done it this
way", and there is little scrutiny of the use of estimates. When estimates
don't seem to be serving us as we wish they would, the natural or
common approach is to simply try to get better at estimates. As business
people (and as humans), we need to have confidence in the methods we
15
use - "getting better" is a less than meaningful approach unless we have
sufficient faith in the thing we need to get better at. And even still, we
must keep a close watch on whether things are getting better overall, and
not just the estimates themselves.
So naturally, I want to dig a bit deeper. Estimates themselves are not
bad, and in some situations they can be very helpful. However, estimates
are often part of an unquestioned process of managing software
development, so I want to learn more.
When I become aware of a situation like we have with estimation I
want to question, explore, and validate (or invalidate) the practice or
method. Is it suitable for the purpose to which it is put? To accomplish
this, I start by asking questions of myself. I want to find the "profound
questions" that will lead to a better understanding.
I have a number of questions I've posed to myself about estimates.
Here are a few examples of the sort I find useful to ponder as a starting
point:
"If I found estimates are not informing the decisions they are meant to
inform, what would I change about the way I use them?"
"If I found estimates are not useful for a purpose, in what way could
that be the fault of the estimates themselves? In what way is that an issue
with the purpose?"
"In what way would getting better at estimates help if the estimates
themselves are of questionable use?"
"What ways can we meaningfully validate decisions we've made
based on estimates?"
"If we believe that getting better at estimates is our only choice, what
are the possible pitfalls?"
"If the decisions that we currently think are important are not as
important as we think they are, what should we do?"
16
Early October, 2012: I had just met Neil Killick in Twitter, and read a
blog post of his named "Should We Estimate Software Projects… At
All?" After a few Tweets back and forth, Neil introduced me to Vasco
Duarte. I believe that the first blog post from Vasco that I read on this
topic was "A better way to predict project release date!" What a great
starting place. Alone, I had my suspicions about estimates, but with
others such as Neil and Vasco also questioning the practices of
estimation and use of estimates I was encouraged that some real progress
can be made.
So now there were three: Neil, Vasco, and myself. Little did I know
how much I would learn from my on-going conversations with these two.
Even more wonderful was that new folks were joining the conversation
daily. One notable luminary is Ron Jeffries who has now written
extensively on the topic, and over time many others such as Allen Holub
and Kent Beck have shared their ideas on the topic. But I'm jumping
ahead.
I noticed an interesting thing very early on: While we were all
questioning the "de facto" use of estimates in managing software
development, we had different ideas about what the core problems might
be, and what to do about them. I took this as a good sign. I seek a broad
spectrum of ideas, especially at the beginning. We were all noticing that
something was amiss.
If the use of estimates and estimation are suspect, I'm more interested
in learning all about that than what to do about it. The "how" reveals
itself when we understand the "why" about the "what." This is where the
power of pursuing profound questions comes into play for me. The
"how" of estimates is a moot point if they are not serving us well. It's of
little value to solve a problem we don't yet understand; we are just a
likely to be addressing a symptom rather than the underlying problem.
Let's get that settled first, and then explore the alternatives.
Getting better at estimates (which the entire industry has been trying
to do for a long time) doesn't help if the underlying motivation for using
them is not valid. Rather than jump to the possible solution of getting
better at estimates, I want to do whatever it takes to understand the
underlying reasoning and purpose of the estimates. That is an area worth
exploring.
17
Along the way it became apparent to me that some decisions we make
when managing software development efforts are probably not the right
decisions to be making. Why do we feel that knowing the cost of
something "up front" is useful? Is that really important, or simply just
something we've convinced ourselves that we can't do without? Why is it
that we think we have "limited funds" for software development? If we
are good at generating income from the work we do, are these limits even
meaningful at all?
What if there are alternative models that lessen or eliminate the need
for knowing the cost? Consider that it might be better to become great at
creating software, and delivering it into actual, meaningful use early and
often, and earning a return almost immediately. Would knowing the cost
be as important if we can start re-cooping whatever costs there are almost
immediately? Maybe by following this model the desire and interest in
estimates will simply fades away. Maybe not. Let's find out.
Estimates are used in many ways, and there are seemingly countless
methods of estimation for devising those estimates. What if we could
forecast some aspects of our project without estimates at all? This is
something I find interesting, and it's a possible game-changer.
Vasco has been exploring one such alternative that is of particular
interest to me, and he covers it nicely in this book. His ideas about
forecasting based on the data collected in the doing of a project eliminate
the need for certain estimates for that project, and the results are easily
verified. If we find that forecasts are helpful, what if we could find a way
to forecast without estimates that works at least as well as estimating
does? What if it is actually better? And easier? How would that change
our dependence on estimates? How would that change our regard of
estimates? Should we at least experiment with ideas like this? What if we
could try this and prove it for ourselves while still working in the same
way we always have? Powerful stuff.
I'm glad you are reading this book, and exploring along with Vasco.
While this is still a very new effort, many people are gathering around
these ideas and questions, and exploring for themselves the method that
Vasco shares in the #NoEstimatesBook. Business people, Managers,
"Customers", Developers, Analysts, and just about anyone will find this
book useful.
18
We all see a need for better, and insist that regardless how well
entrenched the "way things are" might be, it's time for a change. And we
welcome it.
Woody Zuill
#NoEstimates Pioneer, and Software Industry veteran
www.MobProgramming.org, http://zuill.us/WoodyZuill/
19

THE #NOESTIMATES PREMISE
If you have been around Agile and Lean for some time you might be
familiar with the Japanese-born concept of “no inventories”. Between the
sixties and the eighties, Japanese companies – Toyota being one of the
most prominent examples – embraced a new paradigm of production
founded on the premise of maximizing value for the customer and
seeking continuous improvement. In order to maximize value, all
activities and investment that were not directly adding value to the
customer were labeled as “waste”. In this sense, moving materials from
one place to another is waste; reworking, overworking or overproduction
are waste; fixing defects is, of course, waste; and unfinished materials
waiting in a queue to be used (inventories) are waste.
The golden rule to determine if something in your organization falls
in the category of waste is: “do we want to have more of this? Like
double or triple it?”
Companies seldom want to ask this question. If you ask it too much,
you’ll find that Managers are waste - you don’t want more of them.
Meetings are waste. Code is waste.
But, if mostly everything around us is labeled as waste, shall we get
rid of it? The answer, of course, is no. The premise is that you want to
have as little waste as possible, and not more. Once you reach the state of
minimum waste, you should try to go even further and reduce it a little
bit more – continuous improvement or Kaizen.
Of course, you don’t want to double or triple your inventories.
Inventories are a hidden bank account, money lying around doing
nothing but deteriorate. Even worse, it requires investment in the form of
space, maintenance, rotating stocks, security… You even lose inventory
pieces due to aging, bad storage or warehouse mismanagement. You
have to maintain stock records and reconcile inventory periodically – and
if you’ve ever done something similar, you know how soul crushing this
process can be.
So what’s the only reason we keep inventories? Organizational
dysfunction, or so believed the Japanese companies. People need
inventories so they have access to materials between resupplies. These
resupplies were separated by several hours, sometimes days. Each
resupply needed to be huge so workers would have materials until the
next resupply. Huge resupply needed space, storage, management,
rotation, movement… Waste everywhere.
The Japanese breakthrough was to imagine a company where
21
resupplies were happening constantly, Just In Time. By imagining how
work would look like in a world with no waste, they could forge new
production paradigms like one-piece-flow, single-minute-exchange-of-
die, zero-defects or total-quality.
Of course, you could be picky and observe that each worker on a
Lean factory might have a small inventory of pieces around, maybe a
handful, maybe a dozen. You could then claim “Look! Look! That’s
inventory! It is not actually true that they work with #NoInventories!”
The point is that these Lean factories have been able to reduce the
resupply period from days to minutes, and their stock, inventory or
storage needs from stadium-sized warehouses to drawers.
So, #NoEstimates…
It is obvious to me that estimates do not provide more value to the
customer than inventories. People who find value on estimates are just
addicted to a practice (estimation) to get something they find valuable:
plans, comfort, uncertainty reduction, financial projections, sales
proposals… But, again, these are not customer value. Applying the
golden question, you don’t want to triple plans, estimates, reports and
proposals. Hence, you want as few as possible – not less, but not more.
So they immediately fall under the label of waste.
Of course, you will always find someone that defends that inventories
are in fact customer value, the argument being that inventories protect
the customer against accidents and company dysfunctions. No serious
Lean discussion can be forged around this argument nowadays.
Interestingly enough, when it comes to reducing the need and
dependency on estimations, people can be quite belligerent – you just
have to wander around the twitter conversations around #NoEstimates to
get a taste of it.
I imagine that, in the early days of Lean, when Womack and Jones
were just starting to spread the news about this crazy Japanese
production system, several people would be as baffled as some are
nowadays with the #NoEstimates movement. I can clearly imagine
western managers protesting, “just in time production? Resupplies every
few minutes? Are you CRAZY? Why are you trying to debunk the
proven practice of accumulating inventories? What are you, smarter than
all of us, than all managers that have been promoting stocks and
inventories for the last four-plus millennia?”
Ah, human beings… ‘gotta love ‘em.
I have faith and patience. When some people in the Agile community
started talking about zero defects or continuous delivery, more than a few
voices rose against such concepts stigmatizing them as ‘delusional’ and
‘misleading’. Even the ideas behind the manifesto, which are
22
enthusiastically defended nowadays, were difficult to promote mostly
everywhere just ten years ago.
I feel there’s a natural learning curve towards #NoEstimates. It is
common nowadays to hear from teams that moved from Work-
Breakdown-Structure (WBS) like estimation – estimating each and every
task, then adding up all estimates – to story estimates, point-based
estimates, t-shirt sizes and counting stories and finally dropped the
estimation-based conversations to focus on throughput, cadence and
flow.
I did my first public talk on #NoEstimates at Agile Lean Europe
Berlin 2011. Many well-known European Agilists were in attendance,
and I could metaphorically hear the sound of their neurons crashing into
each other while I presented the idea of reducing the estimation effort
and focus on stabilizing the team throughput and using past information
to drive forecasts. People rapidly organized an Open Space around the
topic, and the usual question was “yeah, but… You need estimates,
right?” Not a question, in fact, more of a desperate cry in the middle of a
withdrawal syndrome. My answer was direct – no, you don’t need
estimates. You are using estimates to produce some other stuff, so the
question is, can we produce that other stuff in a better way that using
estimates?
Unfortunately, several people still ask for better ways to estimate. It is
a flawed question. For me, it is like asking for better ways to win the
lottery, or better ways to guess what team is going to win a sports match.
But I have faith in the capacity of human beings to change, and patience
to watch that change happen.
A year ago I decided I wanted to push this change a little further and I
asked my good friend Vasco Duarte if he was up to the job of writing a
first book on #NoEstimates. Vasco had enthusiastically defended this
approach based on his own experience. A few months after my talk at
ALE2011, he presented a similar topic at OOP2012, and have been very
active on the #NoEstimates debate since the very start.
We started this work together, but I had to quit after some months –
my job engagements and workload were keeping me behind the intended
pace, and I was basically endangering the project. To be honest, we also
had “creative differences”, as artists say, and decided to “pursue our own
careers and personal projects”. No problem. We are still good friends,
and I kept illustrating Vasco’s work - sort of – and providing my
feedback and insights. We still collaborate on some other projects, and
I’m sure we’ll keep finding opportunities to promote innovation on the
Agile world.
My final word to you, reader of this book, would be to remember the
23
fact that mind is like a parachute, it only works when it is properly open.
Too many people have lost the track of the #NoEstimates premise to dig
into inane details. For instance, some people would say “oh, but you are
forecasting results based on past information – isn’t that an estimate?” Or
maybe “oh, but you are breaking big stories into small, one-or-two day
sized stories, but in order to do that, won’t you need to estimate the story
size?” Remember that #NoEstimates is not about no estimation ever, but
about the minimum amount of estimates that will do, and then look
carefully at ways to reduce that need even more. In that sense, I love J.
B. Rainsberger concept of #MehEstimates, like in “Oh, estimates…
Meh!... Yeah, I guess we’re doing some, we are just not very concerned
or serious about them.”
So, here’s to life, the #NoEstimates book. Enjoy.
Ángel Medinilla
Agile Coach, #NoEstimates practitioner, Book illustrator
http://www.proyectalis.com/
24

CHAPTER 1
THE PROBLEM WITH ESTIMATES
Carmen came into the office bright and early in the morning. She was
surprised when her boss unexpectedly called her into his office. Any
other day he would greet her; invite her into the break room for coffee;
have a friendly one-on-one chat with her, and talk about life… But not
this time.
This time her boss looked nervous. He made sure the door was closed
the door before saying a word. Carmen appreciates her boss because she
has learned a lot from him. But his behavior made her feel nervous.
What could her boss possibly want that required them to meet behind
closed doors? What could be so secretive that it couldn’t be overheard
by anyone else in the office?
“Carmen, we have a big project coming in. This is potentially the
largest software project our company has ever won.”
“A big project you say?” Carmen’s interest grew. “It’s about time
they consider me for a big project” she thought.
“Yes! This project alone could finally make us profitable! And I want
you on it. I trust you and appreciate your work greatly. I know you can
pull it off…”
28 Do Estimates Work?
Carmen was surprised. She had heard of a new, secret client project
that they called Big Fish, but she did not expect to be assigned to this
project. After all, she still had the Telemark project going on.
Carmen shifted in her chair and tried to think of something to say.
Something didn’t feel right.
“Well… That’s a surprise. I still have the Telemark project, which
will be landing soon. I thought you wanted me to finish that before
moving on to other projects…”
“I did, but his came up suddenly.” Carmen’s boss interrupted, “I
only just heard about it yesterday. Our CEO was able to find a way for
us to bid on this project. It will be huge!”
“Errr, Okay. What should I know about this project before I take this
assignment?” Carmen was unsure about this. Her boss seemed almost
too eager for her to say yes.
“Well… Basically nothing. It’s just another software project. The
only difference is that this project is bigger than the others you’ve
worked on.”
“How much bigger are we talking about?” Carmen asked.
“Well…” She felt uncomfortable. Her boss wasn’t being upfront with
her.
“Is it twice as big as the Telemark project?” She asked, but her boss
didn’t reply. “Five times bigger?” Still no comment. “Ten times
bigger?”
The Problem with Estimates 29
“Actually, it is a public sector project, so I guess you could say that

it’s several orders of magnitude bigger than your Telemark project….”
He finally admitted.
“Oh…” Carmen was speechless. This could potentially be the largest
software project in the country, and she was being lined up to manage it.
“And we’ll need to present a bid by the end of next week!” Her boss
looked excited. “So get your team on it. We need to close this deal now
Carmen; it could change our company’s future! We need to submit our
proposal as soon as possible!”
Do Estimates Work?
If you were Carmen, you’d probably feel nervous too! I know I
would. Estimating a software project is never an easy task, and the
situation gets even worse when you have to do it without first
understanding the context or the requirements well enough. Add that to
the pressure to create a winning bid, and you have an explosive mix! And
not in a good way.
When I talk about #NoEstimates I get the most serious questions from
people like Carmen. Questions such as, “How can I win a bid if I don’t
estimate?”, or “My customers will not award me the contract unless I
give them an estimate!”
Fair questions, but before we tackle them, let’s tackle the real
question here. A key question for both you and Carmen is “Do estimates
work?”
Some researchers have already proposed what a “good” estimate
should be. In 19861, they proposed that a good estimation approach
would provide estimates “within 25% of the actual result, 75% of the
time”.
What this means is that, for all the projects you estimate, you should
complete those projects within 25% of the original estimate for 75% of
the time. Another way to put this is that you don’t have to always be
within 25% of your estimate, but that you should be for 75% of all of
your projects. Let’s examine the track record in the IT industry to see if
we’re consistently able to estimate correctly.
First we look at the Chaos report, a study that is run every few years
to assess the “success” of software projects worldwide:

Figure 1 – Project success rate over the many CHAOS report surveys from 1994
to 2004. Graph adapted from Steve McConnell's book, Software Estimation:
Demystifying the black art

1 Steve McConnell, Software Estimation: Demystifying the Black Art
This picture looks grim. If Carmen works for an “average” company

her chances of success are slim, about 25% if you believe in the accuracy
of the Chaos report. Not good.
You can improve your chance of success by using certain software
development practices like Agile, but even then the success rate is a poor
42%2.
But let’s look at this from another angle. Even if you agree that being
within 25% of the original estimate is a good result, what about the
outliers? The tasks and projects that exceed the original estimates by so
much that they run the chance of jeopardizing the entire project or
portfolio? You may think that your projects don’t include such tasks.
…Bad news…

Figure 2 - Project estimates vs. Actuals (in days), track record for one
organization. Graph adapted from Steve McConnell's book: Software
Estimation, Demystifying the Black Art.

2 CHAOS report for 2011-2012 shows 42% successful agile projects.
Look at the project on the top-left of the chart. That project was
estimated to last 7 days, but ended up taking more than 250 days to
complete. This is a difference of 1 week to nearly 9 months! While this is
only one outlier, the potential impact on the company is tremendous. A
project like this can drive a company bankrupt.
There are several examples in our industry that look like this. In a
famous UK contract walk out, Accenture avoided up to £1bn in
penalties3 in a contract with the National Health Service (NHS) in the
UK. Some will argue that this is an extreme case, an outlier. But do you
want to bet your company on one project if the possible result is
obliteration? I don’t think so!
Beyond the problem with outliers, let’s look at examples of sustained
performance. Here’s the project delay (in % from original estimate) for
17 different projects from one single company spanning a period of 4
years.
Figure 3 Percentage delay to estimates at approval, and estimates at

requirements completed phase for one organization. Adapted from data
collected by me in one company between 2001 and 2003 for 17 different
projects.

3 Accenture avoids £1bn penalty for walking out of a contract with the NHS
http://www.theregister.co.uk/2006/09/29/accenture_nhs_penalty/
This company had an average (yes, average) delay of 62% for their
projects. This means, for every project that should have lasted 3 months,
it lasted nearly 5 months! As I look at the graph above I can’t help but
ask: “Can we really trust estimates as a reliable tool to manage our
companies?”
Would you bet your entire company on a work-method (estimates)
that delivers 60% to 80% of the projects late or over budget? This is the
question that Carmen had to ask herself in the scenario above. Can she,
in all honesty, risk her company’s future on a method that has that large a
failure rate?
Why Don’t Estimates Work?

“Carmen, I want you to know that you have my full trust. I know that
you can pull this project off.”
“Thank you sir, that means a lot to me.” Carmen said, while thinking:
“and I may need to call on that trust. Hopefully you are not bluffing.”
Estimates don’t really work. Specifically, not in the way the software
industry practices estimation. And not in the way that many, including in
the Agile community, propose estimates should be done. There are three
clear, intuitive, and proven reasons as to why that is so.
Hofstadter’s Law
Hofstadter's Law: It always takes longer than you expect, even when you
take into account Hofstadter's Law.
Douglas Hofstadter4
Douglas Hofstadter observed that, no matter how much work went

into developing computer programs to play chess against Grand Masters,
the winning program always seemed to be 10 years away.
Even though Hofstadter was referring to chess programs, this
observation was picked up by several other writers, such as Brooks in
The Mythical Man-Month and Beck in Extreme Programming Explained,
as a way to highlight just how difficult it is to estimate programming, or
other software development related tasks.
However, Hofstadter’s Law is only one of several explanations for the
continued failure to correctly estimate software development work.

4 Gödel, Escher, Bach: An Eternal Golden Braid. 20th anniversary ed., 1999, p. 152.
ISBN 0-465-02656-7.
34 Parkinson’s Law
Parkinson’s Law
Work expands so as to fill the time available for its completion.
Parkinson’s Law
Parkinson observed that bureaucracies seemed to expand and

therefore create more work for themselves. He was commenting on the
British colonial bureaucracy, but the rule was picked up later by
Alessandro Natta in Italy and Mikhail Gorbachev in the Soviet Union
who famously stated that “Parkinson’s Law works everywhere5”.
Indeed, it works everywhere; even in software development
environments where the modern formulation of Parkinson’s Law is
“work always expands so as to fill all the time available for its
completion”.
Another way to put it is: “If you wait until the last minute to complete
a task, it only takes a minute”... Or does it?
Parkinson’s Law is a description of the phenomenon that work will
consistently expand to use all the time allocated to it. In other words,
projects that get delayed, rarely catch-up. This, in turn means that if you
have one task that is delayed, you should consider all subsequent and
dependent tasks to take at least the time they were allocated, meaning
that they will end after the originally scheduled time. Therefore, having
one task late can potentially derail the whole project. How about that for
a shot in the dark?
Accidental Complication
Another reason why estimation is so hard goes by the name of
accidental complication. J.B. Rainsberger introduced this concept at
Oredev 20136.
The gist of the argument is this: every feature or functionality added
to an existing project has two cost elements (what you’ll want to
estimate):
• Essential complication or g(e): How hard a problem is on its

own. For example, implementing tax handling is hard, because
the tax code is complex in itself. That is what J.B. Rainsberger
calls essential complication or g(e).

5 O'Sullivan, John (June 2008). "Margaret Thatcher: A Legacy of Freedom". Imprimis
(Hillsdale College) 37 (6): 6.
6 Watch the full video here (duration ~8 min): http://vimeo.com/79106557.
• Accidental complication or h(a): The complication that creeps

into to the work because – as J.B. Rainsberger puts it – “we suck
at our jobs”. Or more diplomatically, the complication that
comes from our organizational structures (how long does it take
to get the approval for a new test environment?) and from how
programs are written (no one is perfect, therefore some things
need to be changed to accommodate the new functionality).
The cost of a feature is a function of both essential complication and
accidental complication:
cost of feature = f(g(e), h(a))
In software, estimates of cost are often done by analogy. If features A

and B are similar, then if feature A took 3 weeks, feature B will take 3
weeks. But then J.B. Rainsberger asks: “When was the last time that you
worked on a perfect code base, where the cost of the accidental
complication (how messy the code base was) was either zero or the same
multiple of g(e) as when you implemented feature A?”
He concludes that often the cost of accidental complication – dealing
with organizational and technical issues specific to that code, and that
organization – dominates (yes, dominates!) the cost of a feature. So, if
h(a) is much larger than g(e) the cost of a feature cannot be determined
by relative estimation. In turn, this means that the most common
estimation approach, Story Point estimation, cannot work reliably. What
this means for you is: you can only determine the real cost of a feature by
recognizing and measuring accidental complication, or – like I suggest in
this book – by using the #NoEstimates approach.
36 Accidental Complication
As Troy Magennis 7shared with me in an email conversation:
When we ask someone to estimate how long it will take to

develop a feature or project they think about how long it would
take hands-on, with perfect hand-off between teams and other
staff with the specialist skillsets. This never happens. Work sits
in queues; people work on more than one project at a time;
people take vacations. We estimate the work, when we need to
estimate how long that work takes to go through a complex
system given all of its foibles.
Systems thinkers like Goldratt, Reinertsen, and Deming

understood this well. Work spends considerable more time idle
and blocked by system constraints than progressing towards
completion. Given that for inventive knowledge work the hands-
on time through a system is considered exceptional at 30%, even
if we were PERFECT at estimating that 30% of the time, we
would be off by a factor of 70% without compensating. Even the
commonly used doubling what you are told method would still
be 20% low.
The delays involved in a complex system are unknowable in

advance. Just like travelling to work along the same highway
each day, you can't know there is going to be an accident
blocking all lanes three weeks from now, you can't know that the
test environment will “catch fire” three months from now
blocking all testing work. It's these unknowable system delays
that make forecasting software projects exceptionally difficult.
The only way to estimate and forecasting a system is by

estimating the system impacts and the easiest way to do that is by
observing prior history of work flowing through that system.
#NoEstimates is a strategy that considers the system on its own
terms, allowing some ability to predict completion times in
advance.
What Troy refers to is a critical insight: work flows through a system.

Without understanding how that system works through metrics like
cycle-time, lead-time, etc., the best we can do is estimate a “perfect”

7 Troy Magennis writes about software projects in his blog:
http://focusedobjective.com/news/
engineering day. You and I both know how many of those “perfect”
engineering days we’ve enjoyed in our lives. Not many.
More Than Meets the Eye: Why Estimates Are Actively

Harmful for Your Project
“Carmen, one more thing,” her boss said as she was about to leave
the office.
“Yes?”
“We have a lot riding on this project. It is important that we give
them the right estimate for this project!” Carmen did not fully
understand the meaning of this statement.
“What does right estimate mean? Why would it be important to have
the right estimate instead of whatever else he thinks I may give? Does he
want to set me up?” Carmen’s thoughts nearly spiraled out of control.
She decided to keep them quiet for now, and answered: “of course!”

I would not like to be in Carmen’s shoes. What should she do? The
average person would first find out what the right estimate for the project
was, and then deliver that. And at first they would be hailed as heroes.
But, what if the right estimate at the time of the project bid is actually
the wrong estimate in the end?
38 More Than Meets the Eye: Why Estimates Are Actively Harmful for
Your Project
Deming8 was quoted as saying that “if you give a manager a target he
will do anything to meet that target, even if he has to destroy the
company in the process”. This is why targets are so important, but at the
same time so dangerous. Carmen will probably go to her team, do the
best job she can, knowing full well that the goal is not to give the
customer a realistic expectation of how much time and money is needed
to complete the project, but rather that she is responsible for winning a
contract – no matter what it takes.
Wanting to meet the target is a very strong pattern in organizations.
So much so that at the end of every quarter we see a frenzy of meetings
and busy people trying to meet that quarterly target, be it sales or
operations. Estimates are no different and help make projects prisoners
of the targets they set. And this is one reason why estimates can
transform from useless but harmless, to influential and harmful targets.
Look at what happened at Enron in 20019 where the “compensation and
performance management system [that] was designed to retain and
reward its most valuable employees, [...] contributed to a dysfunctional
corporate culture that became obsessed with short-term earnings to
maximize bonuses.”
But there are more reasons and tempting shortcuts that make
estimates actively harmful in certain situations. Below are 4 situations
that are possible because of the use of estimates in software
development:
• Internal politics become a problem when deadlines are set
because top management wants something done by a certain
date, with fixed scope and fixed resources. Despite advice to the
contrary, in these cases the HIPPO (Highest Paid Person’s
Opinion) overrules any potentially “good” estimate created by
the team.
• Estimate bargaining occurs when a team has created the
estimate and defined a possible release date, and then they suffer
pressure from stakeholders to change their estimates. Symptoms
of this dysfunction include calls for “more efficiency”, or “more
commitment”, generally followed by phrases such as “we are all

8 W. Edwards Deming, American writer, author and coach that helped propel Japan to
the most productive nation status with his work after the Second World War.
9 For details on the Enron scandal, visit http://en.wikipedia.org/wiki/Enron_scandal

in this together”.
• Blame shifting happens when people outside the project team
estimate the work (e.g. experts), and then the project team
members are blamed for not meeting those estimates.
• Late changes are a form of Estimate bargaining, whereby
changes are added to the project, but the schedule is not allowed
to change for whatever reason.
These are only some of the possible dysfunctions associated with
estimates. This list is an illustration of how estimates can be used and
abused for purposes other than actually understanding the project and the
work that needs to be completed.
Entangled: How Complexity Destroys Predictability

The biggest conundrum of all however, is how to deal with
complexity. How complex dependencies in software projects hide the
really big risks.
Software projects present challenges that are unique to the software
development domain. Unfortunately, many in the software industry still
fail to recognize this. I often hear that “a good software project must, like
a house, start on strong foundations of good architecture and good
requirements”. My usual answer is: “sure, if you consider that you can
start by building a tent, then evolve it into a hut, then increment it into a
trailer, and later on deliver a castle, then yes, you could say that building
software is the same as building a house.”
Clearly, software is far more flexible and susceptible to evolution
than a house. And that leads to creating a Complex10 environment where
simple A causes B causality links are not always possible to determine.
Software does not follow simple causality links. Rather, it follows
complex causality links. A complex link is, for example, when a small
change (like a single line) can cause a catastrophic failure. Take Apple’s
famous “goto fail” debacle11, where one simple line of code completely

10 For the remainder of the book we will use the term ”complex” to define an
environment where the relationship between cause and effect can only be perceived in
retrospect, but not in advance. This definition comes from the Cynefin model
(https://en.wikipedia.org/wiki/Cynefin) developed and popularized by Dave Snowden.
11 For more details on the Apple Goto Fail details, visit:

http://www.digitopoly.org/2014/02/26/apples-goto-fail-is-pretty-interesting-and-worth-
reading-about/ Read also Uncle Bob’s take on the “sensitivity problem” that software
development suffers from:
http://butunclebob.com/ArticleS.UncleBob.TheSensitivityProblem
40 Entangled: How Complexity Destroys Predictability
destroyed all the hard work to keep their product safe.

No matter how strong the foundations of Apple's products were, this
single line addition was enough to completely destroy that foundation.
How about that for a house project?
Apple’s example above illustrates one additional property of software
systems: non-linear causality, i.e. when a small change can have very
large impact.
When it comes to estimates, and estimation in general you have to be
aware that no matter how thorough you are at estimating the work you
must complete, it is unlikely you will uncover all the small problems
with disproportionally large impacts. And there’s a very good reason for
that: we wrongly perceive these examples of extreme non-linear
causality to be rare12. We perceived to be so rare we usually call them
outliers. The problem is: in software, an outlier may completely destroy
all the effort that went into creating credible, solid estimates.
Does this mean that we cannot estimate? No. But it does mean that
our estimates are built on quicksand, no matter how strong we think the
foundations are.
Don’t believe me? Check out this collection of quotes that emphasize
how unstable the ground underneath estimates is.
Berard’s Law13
Walking on water and developing software against a written
specification is easy if both are frozen.
Humphrey’s Law
The user of the software won’t know what she wants until she sees
the software.
Ziv’s Law
Requirements will never be completely understood.
Wegner’s Lemma
An interactive system can never be fully specified nor can it ever be
fully tested

12 In Black Swan, Taleb describes how often we ignore extreme conditions because we
don’t consider the nature of systems we analyze. He describes 2 types of systems:
”mediocristan” where linear causality rules; and ”extremistan” where non-linear causality
is prevalent. He then explains how we tend to classify the systems we study in
”mediocristan” because we don’t consider the potential for non-linear effects which
should drive us to classify those systems as ”extremistan” systems.
13 From: http://en.wikiquote.org/wiki/Edward_V._Berard
Langdon’s Lemma
Software evolves more rapidly as it approaches chaotic regions.
Medinilla’s Law for Software Contracts
The 80 000 lines of code won’t fit into a 20-page contract.
Do you have some more quotes to share? Send them over, I would
like to collect them. Email me at vasco.duarte@oikosofy.com
Quotes about late changes in projects
• Thank you Andres Lundsgård for the following quotes.

• “A late change in requirements is a competitive advantage.”
Mary Poppendieck
• “The only thing certain in life is change.” Anonymous
42 Change Requests, Change Everything
Change Requests, Change Everything

And then there were changes. You have been there before. You work
hard to try and plan a project to the best of your knowledge. The team
starts to get the hang of the project and is able to deliver some software,
only to see the changes start flowing in. First they flow in at a trickle,
one by one. But later on, as the testing progresses, changes come in like
an avalanche.


Figure 4 Number of cumulative open defects and the daily rate for closed and
submitted defects during a project. Includes indication of development and
testing phases. This is an illustration based on data collected during the
lifecycle of a project where I worked as project manager.
Hopefully you have some margin (aka buffer) in your project. Right?
Sure, but how much of a margin is margin enough? According to the
definition of a good estimate cited earlier in this chapter, you should
count on at least a 25% margin - assuming the estimation was “good” to
begin with.
Are you safe if you add a 25% margin to your project? The answer is
no. And if you believe it helps, just re-read Hofstadter’s Law again.
In software development, changes have (sometimes very large) side
effects. As you discover problems you find that the consequences of
those problems go beyond what some call “bugs”, you discover blind
spots: complete sets of functionality that require rewriting; or new
functionality that was missing. As a friend once described to me:
“building software is like when you try to unclog the pipes in your
bathroom and end up having to build three more houses just to get the
toilet working again”.
Can you predict all the significant changes you will get, and the
impact of those changes? If you answer yes please send me your CV. But
you will probably answer “no”, just like many people do when asked the
44 All or Nothing: Death March Projects
same question. The bottom line is that estimation is a very poor method
to predict the future, and change requests only amplify that problem.
All or Nothing: Death March Projects

Estimations can become a life or death game for teams and companies
alike. But nowhere is the effect of bad estimation more visible than in the
statistics of mental health problems in overworked and overstressed IT
industry folk14.
The idea of the death-march project15 can be summarized like this:
you estimate that you need five days to cross a desert, so you pick five
water containers, one for each marching day, and you start walking. But,
at the end of day five, you are out of water and you are still in the middle
of the desert.
What can you do? You cannot go back, as you know that it will mean
five days walking through the desert and you don’t have any water for
that. All you can do is keep walking until you either find more water,
reach your destination, or die.

14 Article on the incidence of burn out and stress related illnesses in IT http://www.net-
security.org/secworld.php?id=14666
15 The idea of death-march projects was made popular by Edward Yourdon in his
popular book Death March: The Complete Software Developer's Guide to Surviving
'Mission Impossible' Projects http://www.amazon.com/dp/0130146595/

In a similar way, some projects follow an “all or nothing” strategy.
This strategy borrowed from poker means that a team either delivers
everything (“all”) or the project has no value (“nothing”). In this context,
the estimation process becomes a battleground between the teams and the
customers for that project. The teams want to survive at the end, and the
customers want the certainty they will get everything they want – and
when they want it.
At the end of the estimation process the project will start, and the
people trapped in that project can easily fall into a death-march
mentality. They battle everyday to get the project on track, but a
combination of estimation problems with constant change requests
transform that project into a constant struggle.
You work every day to the best of your ability and deliver concrete
work. But instead of feeling confident and enjoying the progress, you
feel like Sisyphus16: pushing a boulder up a hill that will invariably slide
down, again and again. Making you - and the team - feel that there is no
hope. A death-march project is caused by the all or nothing mentality and
a utopian faith in estimation.

16 The myth of Sisyphus: http://en.wikipedia.org/wiki/Sisyphus
46 Is There Hope for Software Projects?
Is There Hope for Software Projects?

If it is so hard to estimate software work, can you predict when a
particular project will end? Yes, you can. And that is the right question.
Instead of asking how long the project will take, ask instead: “given the
rate of progress so far, and the amount of work still left, when will the
project end?” Or, a similar question: “Given the rate of progress, how
much of the work can be finalized by date X?”
These are much more powerful questions. Here’s why:
These questions don’t assume an all or nothing mentality because, for
example, you can remove work from what is left.
These questions don’t assume that it is possible to predict the future.
Instead to answer them, you can use data about past progress and
constantly update your answer to the questions.
To answer these questions, you can use available data that the project
team has already collected (aka actuals) in the form of “rate of progress”,
instead of having to guess at future events without considering the
current rate of progress.
In this book we will cover how Carmen will answer the question
“when will X be done?” using something other than estimates in Story
Points or hours. We will also cover the main challenges that come from
the traditional approach to project estimation, and how to avoid, or
reduce the impact of those challenges. But before exploring how a
#NoEstimates practitioner would predict an end date for a project or how
much work can be done by any given date, let’s review some of what the
software industry today considers “best practice” methods for software
estimation. This review will be essential for us to clarify the stark
contrast between Estimates and #NoEstimates.

CHAPTER 2
WHAT ARE ESTIMATES?
“The right estimation for this project.” The boss’ words were still on
Carmen’s mind as she walked down the hallway to her desk. This was
not Carmen’s first project, but until now she had managed to give fair
estimates on her projects because they were small and somehow similar.
Take this system we already installed here, then install it there. Create a
customized copy of that other system for a new client.
But this was a different kind of beast. New technologies, new client,
new domain, new product. Until now, Carmen had just looked at how
long things took in the past, then added some contingency buffer that
could be accepted by the client. So far, so good. Of course, she also knew
that keeping estimates ‘good’ during the project involved a strong
management of the project. She was known to be very kind and empathic
with clients, but 110% uncompromising when it came to scope creep and
project changes.
“Carmen delivers.” That was the usual comment of managers when
they talked about her, and she liked it.
Now, her reputation had put her in a tight spot. For the Big Fish
project there was no useful historic information she could rely on, and
still she was asked to give ‘the right estimate.’
Anyway, what was the ‘right’ estimate, or the ‘wrong’ estimate? Was
this a game of guessing?
Carmen sat silently for some minutes trying to assimilate it all. One
thing she knew: once she would cast a number, an estimate, it wouldn’t
matter if it was ‘right’ or ‘wrong’. That number would instantly become
known as ‘the plan’ and for the following months she would be measured
against it. But on the other hand, if that number was ‘too large’ the
company might lose the contract and she would be held accountable.
Carmen opened a drawer and pulled her old project management
books in search of something she hoped would help her find the ‘right
estimate’. If she failed to produce the right estimate, at least she wanted
to have the opportunity to say “hey, I did it by the book! Literally!”
It might seem like an obvious question. Everyone involved in some

kind of project-oriented environment will have much experience using,
WHAT ARE ESTIMATES? 49
producing or asking for estimates.

Because of that experience, most people tend to form paradigms,
models and pre-conceived ideas about estimates. In order to fully
understand the #NoEstimates principles, let’s contrast them with the
inherent meaning of the term estimates. What are estimates and what are
they not?
The Merriam-Webster Dictionary provides a good starting point,
defining ‘Estimate’ (transitive verb) as ‘to give or form a general idea
about the value, size or cost of something’. From this, we can deduce that
estimates are ideas. Sometimes those ideas are vague, and other times
they are very precise or accurate, but they are ideas nonetheless.
Hence, estimates are guesses, not facts.

Every single time you provide an estimate, you are basically saying “I
don’t know”. If you were 100% sure of what something is going to take
in terms of time, resources or effort, then you wouldn’t be estimating -
you would be providing concrete facts. This is not the case with
estimates. When you estimate, you rely on task description, past
experience and other available information to form a general idea and
provide what feels likely to be a reasonable number.
This number usually takes the form of a precise quantity, like in ten
days or five thousand dollars. As soon as the human mind understands
this number, it will likely tend to stick to it and give it the category of a
fact, in an interesting form of grasping and clinging. As an interesting
piece of trivia, Buddhists believe that grasping, wanting and clinging are
the source of suffering – but that is a topic for a whole other book.
Every estimate has an undetermined amount of uncertainty included.
When you estimate ten days you would better be saying “roughly ten
days on average; it could be eight days if we’re lucky, and it shouldn’t be
more than thirteen days unless all hell breaks loose.”
Hence, every estimate is also a probability cloud17.

Figure 5 - Probability distribution for meeting a specific estimate. Note how the
cumulative probability (area of the curve) of being late is much higer than the
cumulative property of being earlier.
Another important fact to understand about estimates is that, once you

place an estimate on something and there’s someone interested in that
something – for example: your client – the clock usually starts ticking
and will not stop. It’s Monday, you are asked for an estimate, you say
“four days”, and your client automatically starts to expect something

17 Probability cloud is used figuratively in this context to help the reader visualize an
estimate as a fuzzy construct, just like the position of an electron around the nucleus of an
atom. We know the region, but not the absolute position, and the position is constantly
changing in time.
delivered by Thursday.
But estimates are not commitments, nor are they a promise.
Estimates will need to be carefully placed in a plan for them to make
any sense at all. An estimate of three days depends on when we are be
able to spend three days on the task. It also depends on many other facts
like, for instance, if we will be able to focus on the task full time or we
will need to split our attention between several projects. For now, we just
need to make the difference between an estimate: “It will take three
days”; and a commitment: “It will be done on Thursday.”
Imagine that I provide an estimate of five days. Then, I show up early
at work every day with my best smile, I do the best I can, I work harder
and smarter than ever, I even stay a little bit later every day… And, after
five days, the task is not done. Would you say that is my fault? Of course,
it might be my fault that I provided a guess and I did not make clear to
you that it was not a commitment or a given fact.
Hence, many people tend to think “oh, what we need are better
estimates; if we have good enough estimates, then all deadlines will be
met”. Given that estimates are probability clouds, the statement above is
like playing lottery and saying “oh, what we need is to choose the right
number”, or investing in the stock market and saying “what we need is to
invest in the right stocks.”
Estimates in some very controlled and determined domains might
come from a carefully developed mathematical model, and in this case
all people involved will agree to these estimates because they agree on
the model. In some other domains, people will observe the system, notice
that there is a small variance or deviation from an average behavior and
then use that behavior to forecast18 future outcomes – provided that there
are no unknown changes to that behavior in the future.
But for complex environments, where estimates come mostly from
personal experience and knowledge, these estimates will be different for
every person. Experts might estimate some work as easy and fast, while
novices might estimate the same work as difficult and long lasting. Some
team members may see risks and estimate the impact on the schedule,
while others may ignore those risks.
Hence, in most environments estimates are personal.
Because estimates are ideas and they are personal, there are several
psychological aspects that affect them. For instance, if you are bound by
your estimate and you will be judged, even fired because of the outcome,

18 Editor’s note: Please notice the difference used here between forecast and estimate.
This difference is further discussed later in the book.
you will tend to be more conservative. On the other hand, if winning a

project or making a sale depends on your estimate, you might be tempted
to make a more aggressive estimate.
If you add uncertainty, missing information, unknown factors that
will affect the project, personal and psychological aspects, what you have
left is a very inaccurate number that will sometimes result in an
overestimation19 and, most of the time, in an underestimation.
The usual difference between the estimated duration of a task and the
actual duration of that task varies greatly depending on many factors.
Some authors draw a cone of uncertainty20 with 60% variability at the
beginning of the project, meaning that anything could happen between
0.4 times and 1.6 times the original estimate. In some cases, however, the
difference between estimate and actual can be closer to 400%. This
means that sometimes, the cost, time or size of the actual product ends up
being four times bigger than the original estimate.
Given the wide variation of between estimated and actual values, it is
impossible not to cringe when some companies ask their people for
estimates that are 10% accurate or 25% accurate. The only way to
produce such accurate estimates, we have discovered, is to actually build
the thing, then report the actual cost, size and duration as our 100% sure
estimate.
Another possible strategy to create the perfect estimate is to create a
huge buffer for uncertainty. For example: estimating one month for
something that shouldn’t take more than a week. Note, however that this
approach will destroy your competitiveness: your direct competitors
might be offering one or two weeks as estimates for the same work.
And you shouldn’t forget Parkinson’s Law: once the one month
estimate is approved, people will tend to use the whole month to add
scope and functionality to the project – therefore increasing the risk of
being late after all!

19 Overconfidence as a very common bias leading to underestimation of task duration:
https://en.wikipedia.org/wiki/Overconfidence_effect Thanks to Pier Lorenzo Parachinni
for the reference.
20 Cone of Uncertainty by Barry Boehm, as described by Laurent Bossavit in

Leprechauns of Software Development: How folklore turns into facts and what to do
about it, LeanPub, 2013. Note that Cone of Uncertainty idea has been discredited in the
software industry by the work of Todd Little and Laurent Bossavit.
#NoEstimates as #NoInventories
Estimates are seen as useful by many, but even those that want to
continue to use estimates do not advocate that we spend as much time as
possible estimating a project. This type of activities, where more is not
necessarily better, is labeled as waste in Lean Manufacturing (Lean).
Lean defines waste as any activities that don’t directly add value to
the product from the client’s perspective. Companies that adopt Lean
work to eliminate or reduce waste to a minimum.
Inventories, for example – partially produced or fully produced
products not being delivered and instead kept in the warehouses – are a
well known example of waste in Lean Thinking. But meetings are also
waste. Consider this: if we double the amount of meetings, we are
probably not giving a proportional amount of more value to the client.
Use this heuristic to label waste: anything that we don’t want to do
more of in order to make our customer happier is waste. Some people say
“oh, but meetings add value, and inventories are valuable in some
situations” - and they might be right. But from a Lean perspective, you
don’t want to have as many managers as possible, as many meetings as
54 #NoEstimates as #NoInventories
possible, as much inventory as possible. You want the bare minimum,

and then you should try to figure out ways to operate with even less.
You don’t want to spend double, three times or even five times more
effort in estimates. You want to make as few estimates as possible.
And, if possible at all, eliminate them.
Hence, estimates are waste in the Lean mindset.
This is the main premise behind #NoEstimates: estimates do not
directly add value to your process, so we want to find ways to reduce the
estimation process or even stop it where possible.
#NoEstimates does not mean that there are no estimates at all, just
like in Lean environments ‘zero inventories’ does not mean that there is
no inventory at all. It is very usual in Lean factories to find small
inventories of unfinished goods or pieces on every production cell, but
compared to the old production paradigm these inventories have dropped
close to zero.
The same is true for #NoEstimates – do as few estimates as possible,
ideally none. In an attempt to make this this concept even more clear,
J.B. Rainsberger has suggested the hastag #MehEstimates as a possible
alternative to #NoEstimates.
However, the goal is clear: reduce estimation work to the minimum
necessary, and then reduce it a bit more. Reduce it until you find it
painful to work without those estimates, then adapt and reduce the use of
estimates even more.
For ideas on how to do this and be successful just keep reading.
Estimating vs. Forecasting

Although these two words are used many times as if they are
synonyms, they are significantly different.
The Merriam Webster dictionary defines forecasting as “to calculate
or predict (some future event or condition) usually as a result of study
and analysis of available pertinent data”. If you compare this with the
definition of estimates (“to give or form a general idea about the value,
size or cost of something”) you can see that there is a fundamental
difference between the terms: in the case of forecast, we use actual data
to make calculations instead of using experience and other information to
guess at something.
Hence, when you study estimation methods you can divide them into
pure estimates and forecasting methods – those that use specific data,
correlation and system dynamics to predict future outcomes.
Another way of looking at the difference between estimates and
forecasts is that forecasting is viable only when uncertainty and
variability are understood. For instance, let’s say that you are trying to
predict the behavior of a system that is bound by certain physical
variables. Some examples could be:
• The properties of an electrical system, which are determined by

the properties of its components, each of these properties with its
own tolerances or variability.
• The robustness of a physical structure, which is determined by
the strength of its materials, which again have certain tolerance
or variability.
• A simpler example, let’s say you want to predict how many
lemons will your crew collect this morning from your lemon tree
plantation, which depends on the man-power of your crew and
the amount of lemons each tree produces.
In the examples above, and under normal conditions, you can inspect
existing data and find maximum values, minimum values, average,
deviation and variability. You can then use that data to predict what is
going to happen in the future with some accuracy. On the other hand,
tomorrow may change the conditions substantially, it might rain, or some
people might stay at home ill, and you should then react and update your
forecast. This inspection of the existing data, together with building a
model to predict future performance is what we call forecasting.
56 Estimating vs. Forecasting
As a counter example, if you used your own data on how fast you
collect pumpkins as a basis to predict how many lemons a group of five
people would pick, that would be estimating. You would have to make
many assumptions: the walking distances are different; picking lemons
from a tree is different from finding and collecting one pumpkin at a
time, etc. The reason for this is that you don’t have available data on the
same task and you don’t understand the possible performance when five
different people are given this new task, you assume that it will be
relatively similar to picking lemons.
However, estimation is possible and relatively easy in some domains.
Let´s say that my friend and illustrator for this book, Ángel Medinilla is
an average motorcycle-racing aficionado (editor’s note: which he is!),
and he can race around the Jerez fast track in 2:15 (editor’s note: ahem!),
which is pretty fast for most street bikers. When you compare that to the
usual Spanish Motorbike Championship times that range from 1:50 to
1:42, it means that the Spanish Champion is roughly 25% faster than
Angel. And then you have the world record for the track, which is Jorge
Lorenzo’s 1:39 (only 10% better than the average championship race
lap). In this domain we observe that there is not much difference between
‘average’ race lap and ‘world’s best’ (at least when it comes to
percentages). You could forecast the time Ángel would take to complete
two hundred laps with a relatively small margin, not more than 20 or
30%. In this domain estimation would be relatively simple and accurate.
In software projects, however, the situation is different. Even if you
don’t believe that the best developers are 20 to 50 times more productive
than average, just consider the following story: Jon arrives at the office,
energized after a good night’s sleep. He is focused, and is ready to get
into the groove of delivering high-quality software. A few minutes later
Karl, a star programmer, with many years experience arrives as well.
However, he just spent the crappiest night of his life. His daughter was
sick all night and he had to take care of her. He basically slept a few
minutes during the whole night and is feeling like he was steam rolled.
Which of these people will complete the tasks they had estimated with
less variation to the original estimates? Whatever your answer was: can
you be sure of your answer?
In software development there are many factors affecting
performance on the job, and those factors are not predictable nor do they
exhibit ‘predictable’ variation. Karl’s daughter had not been sick for the
last 5 years, now she is. Jon just lost a dear friend to cancer, and he is
trying to come back to his full potential with the help of friends and
doctors. Life is not predictable, and life is the key ingredient in software
projects: our intellectual performance is the key-determining factor of
our productivity and many factors affect us.

Finally, estimation is affected by the expert knowledge fallacy.
Experts are asked to estimate the average time a task will take and some
understanding of the possible variation (in some cases). But experts can’t
factor in the performance of other processes. A programming expert (e.g.
an architect) cannot predict the time it takes to allocate testing staff to a
particular task. Experts are good at predicting certain aspects of work,
but you need to consider the whole flow of work before you can have
reliable data to help forecast (data from several iterations for example).
When you base estimates solely on expert estimation you fail to account
for many aspects that affect directly the performance of the project.
When you use data from the project to update your forecast, you are
factoring in all aspects of the current project, and will be able to detect
when the project performance changes (more on that later).
The Iron Triangle

Carmen realized that she had no way to forecast results for this
project. There was no team selected, so there was no past information on
performance. There was also no previous experience with this client,
technology, product, or domain… There simply wasn’t any historical
data.
Undoubtedly, the amount of uncertainty in this project was too big to
create an accurate estimate, if that was even possible. According to her
experience, uncertainty would find it’s way into the project, usually in
the form of delayed deliveries or increased costs. On top of that, she
knew most of the time many of the requested features were never used, so
maybe having some sort of variable scope would be a better way to deal
with uncertainty; but as usual this was out of the question: this was a
government contract after all. Old school. Closed contracts, up-front
definition, zero tolerance to deviations from the original plan once this
plan was given the GO-decision.
As Carmen thought about the best approach to this project she
doodled a triangle on a blank page.
A discussion on the topic of estimation is incomplete without some

mention of the well-known figure of the Iron Triangle.
The Project Management Institute, in their Project Management Body
of Knowledge (PMBOK), described nine domains for project
management. Those are integration, scope, time, resources, risk, quality,
communication, human resources and procurement. But it is commonly
understood that there are three main variables that will place your project
in the ‘project space’, and those are:
58 The Iron Triangle
• Time: when will the full scope of the project be completed given
the investment and people assigned, or how much time is needed
in order to finish the project given those constraints.
• Cost: How many people, investment and resources are assigned
to the project, or how many people, investment and resources are
needed in order to complete the full scope in the projected time.
• Scope: the work that must be completed in order to consider the
project finished.
These three variables are linked together: once you define scope,
there will be a non-linear equation that will give you different
possibilities on time and cost - the more cost, the less time, but with
certain ‘crash points’ where spending more won’t cut time down, and
using a longer schedule won’t reduce costs.

These three variables define the so-called Iron Triangle. In the center
of the triangle lays a big question mark that symbolizes uncertainty.
Once you understand these three variables as a single equation, you will
understand the iron law of the triangle, which is that you can fix one or
two of those variables, but you can’t fix all three of them. As a corollary,
when you fix two of those variables, the third one will absorb all the
uncertainty on the project, and expand as necessary.
Imagine that you want to print the complete Wikipedia. You fix scope
by downloading the Wikipedia content to a massive storage device. Then
you decide to print it in the next 50 days. At this point you have fixed
scope and time, so you can start calculating how many pages, printers
and people you need to successfully print the whole of Wikipedia in 50
days. Let’s say you calculate 9.6 million pages, 20 pages per minute with
one printer, you’ll print eight hours a day, with infinite resources of
paper, toner and people, and a simple calculation will give you an
amount of just 20 printers to get the job done.
Of course, this sounds like a very reasonable, and simple calculation.
What could go wrong? But again, this is your estimate. You defined an
Iron Triangle of 9.6 million pages; 50 days; 20 printers. In the center of
the triangle, uncertainty will find a way to get into your project...
Let’s say you start printing on day one, and on day five you decide to
look at the numbers… And they show you that you are behind schedule!
You call a meeting with your people and they tell you that, yes, paper
and toner are infinite, but they need to stop a printer for two minutes in
order to change paper, which happens after every 400 pages (20
minutes), and that every day they have to change the toner, and that takes
another ten minutes. So, on average, every day there are 58 minutes
where you are not printing. And, multiplied for 20 printers, that means 1
60 The Iron Triangle
160 minutes, or 23 200 pages lost every day!

In the next weeks, several other unknown factors will affect your
project - printers will stop working, unplanned vacations and holidays,
power outages, urgent tasks that will need the attention of your people,
the list goes on.
What you did when planning the printing of Wikipedia was
estimation - you tried to predict what was going to happen, taking into
account some nominal values and trying to imagine how the project
progress would look like. On the other hand, once you started managing
actual progress data you were forecasting.
At this point in the Wikipedia printing project, you have committed
scope, time and people and resources with your client. What can you do?
You cannot add more printers, as your contract does not allow you to.
You cannot add more time, as you would miss the deadline. And you
cannot cut scope down and print the Wikipedia only from A to U, you
need the whole A to Z.
The common answer in the software industry would be to drop
quality: print in lower definition or make printers print two 50% size
pages on every paper; or make your people stay longer every day to meet
their planned printing quota.
The latter is a terrible idea both morally and rationally. It is
reprehensible from a moral point of view as you are asking your people
to give more than they are paid for, as they were not responsible for your
failure to properly estimate this project. From a rational point of view it
will make your people angry, frustrated, demotivated and will probably
increase your turnover as people leave. In knowledge work environments
– like software development – motivation is crucial to productivity,
performance, creativity and innovation. By asking people to reduce their
standards or stay over time, you destroy their motivation because of a
commitment made based on an estimate!
As this is a simple, repeatable project, the experience you gained the
first time will help you reduce uncertainty in the future. The next time
you are asked to print Wikipedia very few things will change when
compared to the previous time you tried to complete that project: the
content of the document will change, but you will have the same printers,
same people, same time schedule, etc. Armed with a deeper
understanding of the project: you will plan for paper change, toner
change and maybe check the ‘Mean Time Between Failure’ (MTBF)21

21 Mean Time Between Failure, Wikipedia:
http://en.wikipedia.org/wiki/Mean_time_between_failures
statistics of your printers so you can plan for malfunctions. You can even
create a risk management plan that involves some spare parts and a
limited inventory of spare printers.
Still, even the second time around, there will be some uncertainty that
involves all the Unknown Unknowns, all the things that could go wrong
and you could not know about. And when the domain of the project goes
beyond a simple, repetitive, algorithmic tasks, and involves even
rudimentary knowledge skills, the task of providing an accurate estimate
proves to be really challenging, if at all possible.
The Start of a Project Is the Worst Time to Estimate Its

Duration or Cost
“How can I estimate the cost of the project or the time it will take? I
don’t even have a team yet!”
“Carmen, I think you understand how critical this project is for our
company. Our CEO gave his personal commitment that this project
would be done before the next election. Carmen, we can’t fail our
company or our CEO!”
“I understand sir, but I don’t even have a team yet. You can surely
understand that these are not ideal conditions to make an estimate for a
project that is this critical.”
“Carmen, I chose you for this project from all of our project
managers. I know you can pull this off. I’ve seen how well you tackle
crisis situations. This is just another one. I expect your bid ready by the
end of this week. Now I have to take a call with the board of directors.”
Carmen turned to leave, but her boss had one more thing to say.
“Oh and Carmen, don’t forget. This is our chance; one strike and we
are out. Don’t let us down!”
“Tell me something I don’t know!” She thought.
At the start of a project is when we know the least about the project.
Yet, in many cases it is when we make the most important decisions. We
decide on timelines, functionality, technology, architecture, and other
critical variables for the project.
Many questions went through Carmen’s mind:
• Can one developer estimate a project that other developers will

work on?
• How many people do I have to assign to this project? Will other
projects be starved of people?
• I need to balance price (part of the bid) with assigned people,
62 Uncertainty and Buffers
resources and time. How do I do that? – In estimating we have

two variables, cost and time, that are interdependent, but how?
How do we quantify that dependency? Is a larger team more
productive than a smaller team?
• What if the team changes during the project? – Other projects
will be started during this project. What if some of the people in
this project’s team get assigned to another project? How will that
affect the project?
Uncertainty and Buffers

Carmen had a just a couple of facts to work with. Fact 1 was the
expected delivery date: this was a fixed date, as the system should be
ready for a major integration event with another project – which of
course was out of Carmen’s control. Fact 2 was the scope defined in the
request for quotations. The scope was particularly problematic because
of the way it was written. Just like any other written document, there
were many ways to interpret that document. For example, in some
paragraph you could read ‘the system shall be able to export information
to the most common data interexchange formats’. Of course, if this
meant to create comma-delimited files, this wouldn’t be a problem, but
she could recall projects where similar clients asked for PDF, Excel,
OpenOffice, XML and even some really arcane formats. How could she
tell up-front what was the meaning of this high-level scope definition?
One way to try to limit the impact of the lack of scope understanding
was to make some assumptions on the proposal and try to delimit what
was included and what was not, but anyway there would always be a
certain level of uncertainty and lack of definition. So no matter how
many disclaimers she added, at the end the successful mutual
understanding of the scope would be down to feature-by-feature
negotiation, customer collaboration, win-win relationship and good will.
“How likely is this client to behave this way? Not much…”, she had
to acknowledge.
Carmen realized that she needed more ways to deal with this
project’s uncertainty. She needed new ideas.
Every project has some uncertainty in it. In some domains, this

uncertainty can be constrained in a way that ensures the project should
(under certain conditions) not be off by more than a predictable margin –
for example: plus or minus 20%. But in other domains the deviation from
the estimated time can be orders of magnitude larger. In some cases the
estimation errors can be the 300% or 400% range, i.e. projects that take 3
to 4 times more than estimated.
Most projects, at the advice of planning textbooks, build into the
schedules and plans an uncertainty absorbing device, also known as a
buffer. The idea is: we can’t know everything, so let’s add some buffer.
A buffer adds some security margin to your project’s estimate. It can
take many forms, although all of them are closely related by the Iron
Triangle rule:
• Time Buffers: once we estimate a deadline, we add some more

time to deal with project uncertainty (which also means more
cost, as people will be assigned to the project for a longer period
of time).
• Scope Buffers: instead of planning for N features, we plan for N
+ X%, where X% is the ‘scope creep’ expected, i.e. changes,
new features, unexpected requests, feature size deviations, etc.
Planning for more features means of course that you will need
more time and money.
• Cost, investment and people assignment Buffers: if you think
you need a group of people or an amount of money Y to get the
project done by some given deadline, you will plan for assigning
Y+Z% money or people so you have a better chance to meet the
deadline.
Equally important to buffer definition is to decide how to manage that

specific buffer. The buffer should not be just some extra time added to
each task. Instead of that, every small deviation on the original plan
should immediately be logged against the buffer, so we have constant
metrics on project completion / progress rate and buffer consumption
rate. Eli Goldratt described this approach in his Critical Chain Project
Management22.
Goldratt noticed that when every task estimate has some specific
mini-buffer (padding), Parkinson’s Law would kick in and all tasks
would expand to consume the available buffer. Tasks that take shorter
than estimated will take advantage of the buffer and extend a little bit, or
people will see that the next task is not supposed to start until next week

22 See Critical Chain by Goldratt, more information at:
http://www.goldratt.co.uk/resources/critical_chain/
64 Uncertainty and Buffers
and will take care of other pending tasks (HR policies, old projects, etc.)
until it is time to start on the new task. Even worse: tasks that take longer
than expected will consume their buffer and a little bit more. This
phenomenon will affect the whole project. That’s the reason Eli Goldratt
proposed using a single buffer for the whole project, instead of individual
buffers for every estimate.

Buffers are dangerous as they give implicit permission to be late, as
stated in Parkinson’s Law. Eli Goldratt noticed this, and suggested hiding
the buffer from the project team. In fact, he even proposed to cut all
estimates by half in an attempt to fight the negative effects of
Parkinson’s Law, and then use the other half as a project buffer. Success
is unlikely if your project management strategy consists of hiding
information, scheming, conspiring and deceiving. And by the way, the
project team will soon find out your strategy and will balance things out
by doubling their estimates.
The sad truth is that buffers don’t solve all estimation errors. Buffers
can help you balance the expected schedule impact of bugs, rework,
scope creep and other predictable risks. The type of risks that can affect
software projects go far beyond slips of schedule or unplanned down-
time. Hence why instead of managing risks, you should design strategies
to reduce their impact when they materialize. One such strategy includes
having a working product (potentially shippable increment or PSI) as
early as possible. This PSI can work as an interim or ‘beta’ solution until
you finish the whole product. Later we will discuss other ways in which
you can use a PSI to actively reduce the impact of risks on your project.
Classic Methods for Crafting Estimates

As Carmen worked on the project plan, things started to make some
sense, but as understanding increased, her intuition told her that the
overall size of the project was getting bigger and bigger. Even if she
were to improve her skills as a project manager and as a leader, she
wasn’t sure that there was a way to comply with all the project
constraints and requests.
She thought of just calling it quits and rejecting the project, but this
would be a bad career move. Rejecting responsibility just when everyone
was relying on her to save the day would definitely force her to look for
work somewhere else.
Carmen had a reputation for facing problems head-on and being
open about finding solutions. So she resorted to the oracle of all project
managers: Google.
She sighed deeply, typed “how to save a failing project” on Google
and started browsing.
All she could find was the good old “get better at estimating” advice,
which obviously was not an option for her. Her project did not have
more time, or more people, or some magic silver bullet to help her find
the “better” estimates all project management specialists were
suggesting she should find.
Estimation continues to be the preferred method for project definition

and planning.
The Project Management Institute (PMI) has been the powerhouse for
Project Management in the last decade. They issue the reputed Project
Management Professional (PMP) certification, based on their Guide to
the Project Management Body of Knowledge, the PMBOK23.
The PMBOK has a full chapter for Project Scope Management,
another for Project Time Management and yet another for Project Cost
Management. Interestingly enough, the chapter on scope management

23 A Guide to the Project Management Body of Knowledge (PMBOK Guide) Third
Edition
66 Classic Methods for Crafting Estimates
does not talk about estimates – in other words, scope is implicitly

considered fixed and defined. Both time and cost management chapters
have several pages on how to estimate against this fixed, up-front defined
scope. In practice most project management practitioners will face a
flexible scope in their projects, whether by design or necessity.
This difference between the prescribed approach and the actual
practice creates a dilemma for all project managers practicing their craft
in software projects. They can either accept a fixed scope approach or
look for an alternative, for example, the value centered approach.
The value centered approach accepts a fixed time and cost which are
most likely to be determined by contract and availability of people and
money, and accepts that scope will be variable. In practice, this is
translated into a practice of adding or removing scope from the project as
needed to compensate for unplanned work or risk events. In other words:
to compensate for uncertainty. The value approach focuses on specific
practices, like prioritizing scope and delivering the most valuable and
necessary part of the scope early, leaving all the ‘nice to have’ and ‘bells
and whistles’ for the last part of the project, where uncertainty is more
likely to affect the project.
After some hours of writing high-level work packages on a Gantt

chart, Carmen decided to ask for help estimating all of those work
packages. She was looking for dependencies by dividing work into
smaller work packages and analyzing their dependencies. She needed
some experts to help her.

During the following days, Carmen desperately tried to book some
time with the architects and technical leads in the company.
Unfortunately, they were all too busy with ongoing projects. Other
project managers even asked her not to disturb ‘their people’. She
managed to gather some insights on the technical side of the project, but
barely enough to understand the meaning of some terms – not even close
to craft a meaningful estimate.
“Darn, I need to continue to dive deeper into this project. I’ll go and
interview the Business Analysts (BA) at the client site. Maybe they can
answer the questions I have from reading the requirements document.”
Carmen picks up her jacket and starts walking to leave the office. She
dials the number of the contact person at the client.
“Caroline, hi! It’s Carmen from Carlsson and Associates. I’d like to
come in and interview the BA’s for project Big Fish. Is it ok if I drive
over and meet with them after lunch?”
“Hi Carmen, nice to hear from you. Yes, you can come over but I’m
afraid that the BA’s have already been assigned to other projects and are
out of the office during this week for kick-offs. Oh wait, Travis is still
here. Let me check if he is available…”
Carmen hears Caroline ask something. Silence. After a few seconds:
“Carmen? Still there?”
“Yes, Caroline. I’m here.”
“Yes, so you can come in and meet with Travis, but he is very new on
the project and may not be able to answer all your questions.”
“It’s better than nothing,” – Carmen thought to herself. “Ok, I’ll be
there at 13:00. Talk soon.”
As Carmen drives to the client’s offices, she starts thinking about
uncertainty.
“What is the uncertainty level in this project? If I could quantify it,
how large would it be?”
She decided that the uncertainty level for this project is a solid 5 on a
scale of 1 (no uncertainty) to 10 (complete unknown). Usually this would
mean that she would give a margin of 50% to the project estimate. But
she knew it would not be acceptable this time. She thought about it and
decided that a margin of 20% was all her stakeholders would accept.
A few hours later, on the way back to her office and after having
spent 2 hours grilling Travis the Business Analyst, Carmen reflects on
the questions she could not get answered and concludes: “If this is how
sure they are of the requirements of this project, then it is clear that the
requirements are going to change a lot during the project.”
“With this level of expected changes and the uncertainty on our side,
68 Classic Methods for Crafting Estimates
the uncertainty level should be raised to a 7 or 8, but that is not

sustainable in the current situation. I’ll have to spend a lot of time
breaking down those requirements with our Senior Architect. We must
win this bid.”
As Carmen enters the office her boss calls her into an empty meeting
room.
“Carmen, I just got word that Accent Partners delivered their bid for
Big Fish. You have an email with the details of their bid. Make sure we
win this bid. I have faith in you.”
Back to the PMBOK, the cost and time estimation sections provide
several tools for crafting estimates. A short summary of those techniques
is:
• Expert judgement: as the name suggests, you find someone

who is an expert on the domain and ask about his or her estimate
– which is the expert’s guess.
• Analogous Estimation: consists on using information from past,
similar projects or tasks and assume that this project won’t be
very different from past projects.
• Published Estimation Data, Vendor Bid Analysis: the study of
similar projects from other organizations can provide data that
we can use to refine our estimates.
• Bottom-up Estimating: the idea is to divide the whole project in
small, estimable work packages or tasks and then add them all
together to obtain a whole-project estimate.
• Parametric Estimation: also known as sampling. If there are
simple, repetitive tasks, then you can estimate the duration or
cost of one or a few of those tasks and multiply by the total
amount of tasks in the whole project.
• Group Decision-Making Techniques: the main rationale for
this approach is that a group of experts can produce a better
estimate than one individual on his own. Brainstorming
(producing several ideas and then analyzing them) or Delphi and
Wideband Delphi (asking several people separately and then
putting their estimates in common and discussing them) are some
of the known approaches.
Estimating in The Agile World

Agile practitioners have suggested several agile specific practices and
tools. Possibly, one of the first approaches was the Extreme
Programming planning game, which used a group decision technique to
decide on how much work to take on into an iteration. Team members
would discuss and collaborate to describe the work they were
considering undertaking, and finally decide on what they could commit
to. The discussion and conversations during the planning game helped
build a common understanding among the team members.
Poker planning and estimating
Another well-known technique is the planning using cards with
numbers, in which team members will select and later discuss around the
size and complexity of work the team wants to plan for a particular
iteration. This approach is often called planning poker, and helps the
team discuss each work item (typically user story), followed by a blind
estimation vote to avoid team members from being influenced by other’s
votes. Once the vote is completed, the team will discuss the highest and
lowest estimates to try and reach a consensus or, if needed they will
estimate again.
Once the team agreed on a particular size and complexity for a user
story, they would assign a story point value to the user story and discuss
the next, until they felt they had reached the limit of possible work for
the next iteration.
Planning poker is typically used by agile teams to do relative size
estimation: the relative effort necessary to one work item, when
compared to other items in the team’s backlog. This gives the team a
measure of size and complexity in the form of a story point value
assigned to each story. All stories of similar size and complexity will
have a similar story point value associated with them.
Using past velocity to estimate future capacity
The Scrum framework also introduced the term velocity as a measure
of the team’s capability to deliver completed (aka Done) work in each
iteration. After collecting some data from several sprints, then teams can
use the average velocity to analyze a prioritized and estimated backlog
and forecast delivery dates and costs. The caveat is that the
understanding of the work to be done changes over the course of a
project, which in practice means that some teams end up re-estimating
their backlog items several times during the project.
Prioritization vs. estimation
These tools and techniques assume that some kind of prioritized
70 Estimating in The Agile World
backlog has been created with the customer or their representative.

However, most frameworks fail to establish a prioritization technique,
they just assume that the client will know what is more important and
valuable. This is a major flaw, but fortunately frameworks and tools –
like the Lean Startup ideas – were developed to formalize prioritization
methods.
These prioritization methods are very much in line with the ideas in
this book. Most noticeably Kanban and Lean Startup place a greater
emphasis on the prioritization process than on having estimates of the
backlog items. The rationale is that once you know which is the one
single most important thing in the universe for your company right now,
there is little value in knowing how much is it going to cost when
compared to other items in the backlog. For these methods the value of
the work in the backlog is the driver for decision-making.
Estimation vs. flow

Lean, and Kanban highlight the importance of limiting the work in
progress and helping the system flow. Flow improves as we reduce the
number of work items in progress, which in turn reduces the time to
complete each individual work item. Once there is a prioritized list of
work items, the Kanban ideal is to be able to process work items one at a
time, non stop, and do that with as little delay as possible. As a way to
help the work items flow from backlog to production, variability in the
work and/or processes should be addressed, understood and, if possible
reduced. The use of historical data for flow metrics can then be used to
forecast results, deadlines and projected costs, without having to estimate
every individual work item.
Selection method: riskiest assumptions first
Lean Startup focuses on identifying the most important assumptions
about your business model: those that, if proven wrong, would invalidate
your whole project. It then urges you to define experiments to prove
those assumptions right or, if they are wrong, create new assumptions
through a pivot24. These validated learning cycles should be performed as
quickly as possible, ideally several times a day. If you are able to
perform this series of strategically critical experiments so quickly, then
spending time trying to estimate the length or cost of each experiment is
pointless.
When are estimates reliable?
Estimates are often used in agile projects to provide information that
helps prioritize the backlog of work items. However, those estimates are
so often wrong that the only appropriate use is to separate clearly the
items that are sufficiently different from each other. This clear difference
would help us with the decision to drop one of them. For example, if one
item is estimated to last one week, and another item is estimated to last
for 10 weeks, then it is easy to believe the first item will be delivered
faster. However, if the difference in estimation is small (e.g. 10 weeks
vs. 12 weeks), the errors in estimation can easily defeat the purpose of
making a decision based on the estimated duration of that item.
Focusing on value
Additionally, experience shows that only a fraction of all product
features deliver the bulk of customer valuable functionality. Identifying

24 Pivot is a structured course correction designed to test a new fundamental hypothesis
about the product, business model, and engine of growth.
72 Estimating in The Agile World
which features are the ones that deliver most value is therefore more
important than finding which of them are small and which are big.
In essence, cost is not proportional to value. Once the cost difference
between features is reduced (by splitting the work into small, verifiable
work items focusing on value), prioritization based on customer value for
each work item provides better results than deciding which are the
cheapest or the most expensive work items.
But don’t we need to estimate to know when the project will be done?
This is the most common objection to #NoEstimates that I hear over and
over again. In the next chapter we explore the reasons why this question
is asked. In other words: why do we really need estimates?

CHAPTER 3
RETHINKING ESTIMATES
The (Alleged) Need for Estimates: Deadlines, Costs and Scope

Carmen was exhausted. She had been working 14 hours a day for the
entire week in order to produce a document that made sense. She had
highlighted all the risks she could think of, all technical dependencies,
all sources of uncertainty and interpretation, and all key boundaries and
constraints. Still, she couldn’t think of a good way to define a vision of
success without actually asking the client about it. Of course, the client
was not available to clarify.
Carmen’s boss started to gently press her to produce an estimate
three days ago. Two days ago he had started to send her e-mails and
copying all relevant stakeholders up the corporate ladder. The day
before, he had started to phone her almost every hour to ask about the
progress with the document, and drop last minute recommendations such
as “oh, by the way, it is absolutely mandatory that you find a way to
introduce our Business Analysis, Automated Testing and Architectural
Support consulting services into the proposal”. This was not what
Carmen needed a few hours before the proposal was to be ready.
At that moment, looking at her nightmare-ish document that already
counted 300 pages, Carmen felt as if her life was a Dilbert cartoon.
“Maybe it is because I’m exhausted,” Carmen thought, “but right
now I cannot think of a reason we are producing this monster of a
document. There are too many loose ends - it will just never work the
way it is described here. Worse: everyone knows that! Very probably,
even the client knows that, at this point any fixed definition of what the
future will look like is just W.A.G. – Wild A** Guess. So what’s the
reason everyone is so excited about having it as soon as possible?”
“Why don’t we just start working on it and find out what really needs
to be done?”
Carmen shook her head, took a sip of her coffee and thought, “wow,
I’m just losing it… I need to go on and finish this as soon as possible. I
need to focus on how we can win this contract and move on to the next
problem as soon as possible.”
It was 22:00 and she could hear the distant sound of young people
partying the night away at the pubs nearby.
76 The (Alleged) Need for Estimates: Deadlines, Costs and Scope
Let’s review for a moment the situation Carmen is in:
• She is responsible for a bid on a very important project for her

firm.
• She is being pressured by her boss and her company to deliver
the project under a certain time/cost.
• She knows that uncertainty regarding the project itself is high,
and the stakeholders do not want to have that uncertainty affect
the estimate.
• She does not yet have a team – after all, they are only in the
bidding phase.
Many projects suffer from these same dynamics. They suffer from
unrealistic expectations.
How do you estimate a project like that? Can you avoid that part of
the project, can you drop estimates altogether?
The answer is not simple. When a bidding process is required, you
can’t avoid providing an estimate. And there are many ways in which
you can try to be precise, honest and create an estimate that you believe
in.
But when you go through a bidding process, even if you can provide
an estimate you truly believe in, the start of the project is when you know
the least about the project in all its dimensions: content or scope, costs,
technology and, most importantly, people and teams.
We need a different approach.
All parties involved in a bidding contest use estimates to “win”.
Providers use estimation as a tool to win the bid. Clients use the bidding
process to create a pressure on the estimations by the providers. Clients
want to create that pressure to win the cheapest or fastest project they
can. But estimates – no matter how good they are – cannot give you what
you really need: visibility to progress; and actionable information.
Rethinking Estimates 77

Now that we have a common base to discuss estimates, we can move
to one of the fundamental questions around the use of estimates in
software projects.
Why Do We Need Estimates?

Common answers to this question include:
• To know when the work will be completed and delivered.

• To know how much the project will cost.
• To know how many features we can fit in the project, given time,
and other constraints.
Of course, this does not mean that estimates will help you to actually
know time, cost or scope of the project, but you can have a better idea
and constrain the outcomes to a minimum or maximum time, cost and
scope.
It is important to know that estimates, on their own, have no actual
value unless they can help us understand better when the deliverables are
going to be ready or how much the whole project will cost. If there were
78 Why Do We Need Estimates?
any better way to know the answer to these questions, estimates would
be a waste of effort and time. For example, if you could know when a
box is going to be delivered by asking the courier company, it would be a
waste of time to conduct an estimation meeting and try to estimate when
the box will be delivered.
But there are deeper, human reasons to estimate and ask for estimate.
One is emotional - you just need to know them so you can sleep better
and reduce your stress. This is very common when I travel. When I travel
early in the morning, the night before I make a careful prediction (or
estimate) of how long it will take me to reach the airport. I check the
weather and road conditions on the way to the airport and come up with
an estimate for that trip. Then I book a taxi for a time that would give me
a 30 min or so buffer because the security line at the airport may be slow
that day. Making this estimate helps me sleep better. In any case I always
setup 2 different alarms to make sure I wake-up on time. Without this
estimation I probably wouldn’t sleep very well.
Another possible reason is that you might need to give some answer
to your client so that he stops calling you every five minutes, or you need
to tell something to senior management and other stakeholders so they
trust your ability to manage the project.
You can probably think of other scenarios of when the people
involved in the project just need to hear an estimate – no matter the
accuracy of the estimate – so that they can feel safer, or that the project is
in control. These human reasons are understandable, but they don’t make
your estimates critical to understanding the project progress. They are
part of working with other people, who have different needs.
Without really thinking what she was doing, Carmen speed-dialed her
boss’ number. He picked up the phone after just two rings – bad sign, he
was expecting the call.
“Hi Carmen! Do you have news for me on the Big Fish bid? I have
the client’s people all over me…”
“Er… I am almost done, sir. I understand that our company’s future
depends on this project. I understand that we must present our bid soon,
but I’ve been trying to get a team together for the past few days and no
one is available.”
“Well Carmen, that’s why we put you in charge, we’re sure you’ll
find the way.”
“I was just wondering…”
“Yes Carmen?”
“You know… There’s no easy way to put this...”
“Come on, Carmen, you know I absolutely support you, you can tell
me anything.”
“It’s just that… I don’t really understand, sir. It doesn’t matter how
much work I put into this document, it just makes no sense. There are too
many loose ends, too much uncertainty. Above all, why do they need such
a complete plan now?”
There was silence on the line.
“Sir?”
“Er… Yes, Carmen, it’s only that I’m not sure what your question
was about.”
“It’s simple, why do they need an estimate?”
“Well, Carmen, I assume you are asking that because it’s Friday and
it’s late. This is a very easy question: they just need something to show to
the business.”
“Yes, but why?”
“C’mon, Carmen, you’re kidding me… They need something that
shows them that the project will be done on time, something that makes
them trust us.”
“I understand, sir, but… If this is a trust issue, not a planning and
analysis issue, wouldn’t it be better solved through communication? I
mean, we don’t actually know if the project, and I mean the whole
project, is going to be ready on time. We can just give them an idea of
what might get done and what’s the uncertainty range. It’s like…”
“Look, Carmen,” her boss interrupted, “it seems to me like you feel
insecure. I understand that you are under a lot of pressure. But you know
that we need to deliver the bid or we will lose the project.”
“Well, if it’s just a matter of showing something, then I could have
just made up those numbers instead of overworking myself through the
last week.” Carmen was starting to feel anxious and frustrated. After all
her hard work, her boss seemed to be telling her that whatever she wrote
on the document it didn’t matter.
“Carmen… Calm down. You are under a lot of pressure, I
understand.” Carmen’s boss said in a harsh voice, “but it’s not like we
could just put together some random numbers. These need to be accurate
estimates, and you will need to live up to them. We will commit to these
numbers, and you will be responsible to deliver according to them.”
“This is not fair, sir. If you are going to hang me with my own
estimates, then I’d prefer to keep them conservative. I’d rather say that
we are going to do just some of the 400 features in the backlog, and that
it will take us a year to do so.”
“Carmen, don’t over react, please. We need to commit to the whole
project scope. And it has to be delivered before the defined deadline.
Period. This is non-negotiable.”
80 Why Do We Need Estimates?
“But sir…” Carmen felt her voice trembling, “you already have your
estimate. All the features, right before the deadline. It’s like we already
know what the estimate should be even before completing the due
diligence work…”
“Carmen.” Her boss said and paused for a few seconds. “You know
what you need to do, that’s why I chose you. I pay you to solve the
hardest problems in our projects. I know you can pull this off. Now I
better get some sleep, we have serious work to do through the weekend. I
hope you will see things differently tomorrow.”
<click> The phone line was dead…
What Carmen’s boss is asking her to do is to use her magic touch and
convert an impossible project into a viable one. She will do just that a bit
later in the story without the use of estimates, but before explaining how
she does it; let’s review her situation.
Winning a bid no matter the consequences is a very common anti-
pattern in the vendor-buyer relationship for software projects. The bigger
the project, the more often it happens – because there is a lot of money,
status and reputation at stake. And because there is so much at stake, we
invest significant time and money to try to reduce the uncertainty of our
decisions. Not knowing what is going to happen in the future causes a lot
of stress to the untrained mind.
Any projected deadline, cost or feature catalog crafted using estimates
is a guess, no matter how well researched, prepared and reviewed. These
guesses help reduce uncertainty, but not eliminate it. Sometimes, a very
inaccurate estimate acts as a sedative: it will provide you with bad
information that will make you feel secure, but when you realize the
estimates were wrong it might be too late and at that point stress levels
go through the roof and everybody loses their cool.
In some other cases, estimates are used as a weapon to assign blame.
In these cases, the estimates will turn into a deadline and all involved
will be blamed when the deadline is not met. How can estimates used in
this manner add value to a company? Is this a valid reason to spend so
much time and money on estimates? Is it the best way to manage projects
and mitigate risks?
Often organizations will start a project that just needs to be done, no
matter what, and then will spend some time estimating size, costs and
deadlines because they need to know when it is going to be done, or how
much will it cost, or what features will be delivered. In those cases, when
you ask them what decisions will they take depending on the projected
cost or delivery date of this project, what usually happens is that they
stare at you as if you were speaking Klingon. “Because we can’t
continue selling our product if we don’t do this project!” – I can hear

them say. In these cases, what is the value behind these estimation
efforts? If you just need it, start doing it and deliver something as soon as
possible. You can report throughput and forecast future results later
based on the first deliveries, and this information will be much more
valuable and accurate than any estimation done at the start of the project.
In other cases the reason why you might need to know scope, cost or
time is rational: you will decide to start or to contract a particular vendor
depending on the estimates. If we can have it before this date, or if it
costs less than this budget, or if it has at least these features... This is also
the case for clients who need to know what vendor to contract depending
on the information they provide on expected cost, deadline and features
included. Of course, you should notice that these decisions are being
made based on estimates (guesses), and that an estimate is not
necessarily equal to a commitment.
As an example, a client recently needed to decide whether to invest
time and money introducing better engineering techniques into their team
or just maintain the low quality levels but have more chances to meet a
projected deadline. As usual, they asked for an estimate: “How long will
it take to introduce these techniques? What will be the impact to the
team’s velocity at the beginning? When will the velocity stabilize and
increase? And how long will it take to recover this initial investment?”
There is no bulletproof way to know the answer to these questions in
advance because the answers depend on many factors. Instead of a guess,
you need to make a trade-off decision between short-term goals and
long-term improvement you seek. If you choose short-term goals, you
should then make the necessary decisions to deal with the long-term
negative impact of that decision. However, if you decide to support the
long-term goals, you have to make the necessary adjustments to your
short-term goals.
No amount of time invested in estimates will help you make the
inevitable adjustments, because predicting the exact impacts of either
decision is impossible. Maybe your best engineer will quit because he
hates Test-Driven Development, or your best tester will quickly recruit
even better testers once she understands that you really mean quality
when you say quality – thanks to your decision to focus on quality.
In that particular case the teams were asked to invest at least 15% of
their time on engineering improvement while keeping the deadline fixed.
This meant that if we thought that the deadline wouldn’t be met, we
would start cutting down on learning and training time. What happened
didn’t surprise me: velocity didn’t change a bit once we started using
15% of the time to improve the engineering practices, while during the
82 Project Driven Development
next six months quality increased dramatically! This was true win-win
situation, which could not have been predicted by estimating.
Magic? Not really. But it does take a great deal of experience to
understand that not all activities have a linear impact on schedule or
costs. This is what Agile Software Development is all about, exploring
the non-linear relationships between time invested and benefits gained,
just like #NoEstimates.25
Some argue that the process of estimating a project, will help the team
get a better understanding of the requirements, the architecture or
technologies needed to succeed in that project. The assumption is that
estimating a process will result in a better analysis of the project details.
This is not always the case. Having a conversation about the scope of a
project or even the technological alternatives is very different from the
process of estimating cost and time to implement. Estimating and
analyzing are two different things, and although you might need analysis
to estimate, the contrary is not true.
Estimation and analysis are potentially linked techniques, but they are
not dependent on each other. You can estimate a project without
analyzing it (like I propose in this book), and you can also analyze a
project without estimating its size or cost. The conflation of estimation
with analysis leads to sub-par analysis, and that in turn, leads to bad
estimation.
Project Driven Development

The reasons discussed above as justification for estimation are part of
what Ángel Medinilla calls Project Driven Development, a term he
coined to clearly distinguish this approach of developing software from
other approaches.
In this approach, the most important project goals are not customer
value, quality, product success, time to market, adaptation, learning,
market share or even profit. The important goal is to meet the established
deadline, within the defined budget, with all scope included. Simple.

25 An interesting rabbit hole for the statistic mind if the concept of Confounding
variables (https://en.wikipedia.org/wiki/Confounding). This is a concept that begins to
unravel why estimation is such a hard problem. Thank you Pier Lorenzo Parachinni for
the hint to include this reference.

People that evaluate their performance through those very same
metrics – not surprisingly – introduce project Driven Development to
their organization. Other metrics, such as quality; product-market fit; or
speed of delivery end up being ignored in favor of being on time and
budget.
In these projects developers and customer support teams will feel the
pain of bad quality. The lack of product success will be blamed on the
customer “not knowing what they wanted” or the marketing team.
The negative effects of Project Driven Development will affect
multiple people and teams in different departments; hence the blame will
be distributed while the project life-cycle process – the real root cause for
product failure – remains unchanged.
The Project Driven Development paradigm is characterized as
delivering any scope on time, under budget and within the defined scope.
Even if this approach might maximize your chances of receiving a short-
term bonus, in the long-term it is does not help your company or your
client’s company to be more competitive, nor is it maximizing value
from the perspective of the customer.
However, some will find a lot of value on Project Driven
Development. But are they maximizing value for their customers with
this approach? A commonality between organizations that follow this
approach to software development is that they often have little or no urge
to compete or survive, sometimes because they are a de-facto monopoly
in some industry. Other times because the real goal of the organization is
84 Project Driven Development
not survival or success, but rather to maintain their status quo. Yet
another case is when the organization is very successful despite their
software practices, and have no motivation to change because of that
success. In these cases, Agile or Lean makes little if any sense, as there is
no perceived need to maximize customer value, reduce waste or adapt to
change.
For example, let’s say you approach a traditional consultancy
business and tell them “hey, I can show you how to turn that 8 year - 500
people - 250 million euro project for your customer into a 1 year - 10
people - 0.9 million euro Agile project.” The typical reaction will include
an incredulous stare, followed by: “Why on earth would I want to do
that?”
Another example of Project Driven Development: maximizing project
size, cost and perceived outcomes instead of searching for better ways to
deliver customer value faster.
Set-Based Design vs. Point-Based Design

One of the many things that distinguished the most productive car
company in the world, Toyota and its Toyota Production System26 from
its American counterparts was the use of Set Based Design, sometimes
also called Set Based Concurrent Engineering. In this approach, the
Japanese designers of new products would go to great lengths to make
design commitments as late as possible in the project (a goal of set-based
design). In contrast, the Americans were committing to sub-optimal
decisions very early in the project, and then having to re-work those
designs due to unforeseen performance or quality problems (point-based
design).
At Toyota, the production engineers would simultaneously start to
design the production line and prepare manufacturing long before the
new car designs were finished (hence, concurrent engineering), instead
of waiting until all decisions about the design were closed. This, in the
end, provided Japanese manufacturers with an astonishing competitive
advantage that let them design and produce the Toyota Prius in about 3
years27, from idea to first sale! When the industry average for the time it
took to introduce an improvement in an already existing car model was
closer to four years.
I sometimes wonder if this principle of “defer commitment” was not
influenced by Japanese martial arts. When training Kenjutsu, Ángel
Medinilla’s Sensei often says “you have to wait until the last responsible
moment; if you move too early, your enemy will spot your movement and
neutralize it; but if you wait too much, your opponent will strike you.”
Making hard decisions early in the design process – when we have the
least information – may force us to take the wrong path very early in the
project. Later on some of those decisions will be very hard to reverse as
decisions stack on top of each other as the project progresses.
When you keep the scope flexible and do not limit features by a pre-
defined estimation, you will be open to explore new possibilities as you
gain more knowledge on the project. This will enable you to explore
different solutions for the critical decisions, which is one way to use Set

26 More on the Toyota Production System at:
https://en.wikipedia.org/wiki/Toyota_Production_System, and the very enjoyable book
by Liker: The Toyota Way: 14 Management Principles from the World's Greatest
Manufacturer
27 Wikipedia: http://en.wikipedia.org/wiki/Toyota_Prius_%28XW10%29
86 Set-Based Design vs. Point-Based Design
Based Design
If your company is asking for detailed plans before any work actually
begins, there's a good chance that you are practicing a linear method, aka
waterfall. Product development experts nowadays advise against this
approach in complex environments28. If you don't have a clear and
detailed blueprint of what you need to build (like in cars, motorcycles,
bridges or buildings) it would be far more productive and safe to start
with a low-fidelity prototype and iterate it frequently in an evolutionary
manner, obtaining direct feedback from your customer as you go and
reducing uncertainty progressively.
When the Toyota Prius team started their project, the whole definition
they had from Toyota's Chairman, Takeshi Uchiyamada, was to make a
green car and "question everything you know about cars". This project
gave Toyota a high-single digit or low double-digit year advantage when
compared to other automakers (exception: Honda)29.
In the Prius example we see that the project starts with a bold goal,
and a clear direction. No estimates.
When the Honda City engineering team, which averaged 27 years
30
old , started their work, the project definition they got from management
was "we want you to build the kind of car that the youth segment would
like to drive."
How does this compare to estimated, fixed, inflexible project plans?

28 For a comprehensive discussion of linear vs incremental planning see Larman’s Agile
and Iterative Development: A Manager's Guide. For a discussion of complexity, see
Snowden’s explanatory video at: https://www.youtube.com/watch?v=N7oz366X0-8
29 Wikipedia: http://en.wikipedia.org/wiki/Hybrid_electric_vehicle
30 HBR, The New New Product Development Game by Takeuchi and Nonaka:
https://hbr.org/1986/01/the-new-new-product-development-game
Variability
The estimation process is an attempt to reduce uncertainty and
variability in projects. In an environment with no uncertainty and no
variability, estimates would have no meaning - you would always be
certain about cost, time and scope.
Once uncertainty and variability kick in, it is difficult to know the
exact cost, time and scope up front. If your estimates are proven wrong
this will impact heavily the results of your initial decision. Hence why
you need to constantly check how the project is performing according to
the initial estimates and re-plan and re-estimate again.

Re-planning usually results in your client and stakeholder saying “but
you committed to this deadline! You cannot change the plan now! Do
whatever it takes to maintain the delivery date – but, of course, with no
changes to budget or scope.”
A lot of effort is invested into estimation, but not so much to reduce
sources of uncertainty. On the contrary, companies that apply Lean
Thinking (Lean companies) have been developing ways to reduce
variability since the start of the Lean adoption. Lean companies use an
88 Variability
approach they call heijunka31 to reduce variability in the work where

possible. This leveling out of the work load (for example, by having
small User Stories) will help you reduce variability in task duration as
well as help you identify the unexpected variability early on.
When the rhythm of work is steady enough, the estimation process
loses importance and forecasts are more useful and more accurate.
Below is a list of 8 possible sources of variability for software teams.
Technology: if a team which developed a Cold Fusion application for
fifteen years is asked to create a .NET application, all the previous data
on velocity, feature size, cost and time will be basically useless for the
purpose of forecasting their throughput in this new project. On the other
hand, using technologies that are immature or buggy will dramatically
increase accidental complication: the work necessary to work around that
unstable technology. Lean companies try to use only proven, reliable
technologies, no matter how fancy, trendy or innovative a platform might
look. The use of established and well-maintained frameworks is a good
example of this principle on more technology or software related
environments.
Domain or product: even when you don’t change the technology,
there can be a lot of variation if the team is forced to develop a new
product or have to work on a different knowledge domain. For example,
if the team have been developing a micro-payment solution and now they
are asked to develop a warehouse management software they will
probably need to learn many new things, and their pace of work will vary
highly until they reach a level of proficiency with the new product
domain that allows them to focus more on delivery and less on learning a
new domain.
Team composition: some often-overlooked sources of variability are
changes in team composition and team dynamics. Many people assume
that, if you reduce team size by 10%, the throughput should drop 10%,
and if you double team size you should be able to cut development time
by half. This is not the case. If you have a team of 10 people and you fire
the only business analyst in the team, the effective productivity rate will
drop way more than 10%. On the other hand adding more people to a
project that is late is likely to delay the project even more because of the

31 A Japanese word that means “leveling.” When implemented
correctly, heijunka elegantly – and without haste – helps organizations
meet demand while reducing wastes in production and interpersonal
processes. Wikipedia: http://en.wikipedia.org/wiki/Production_leveling
increased complexity and the need for the team to adapt to its new
composition. In other cases, removing someone from the team will
actually increase throughput, while adding someone will dramatically
backfire. Human teams are not bound by arithmetic - you cannot add,
subtract, multiply or divide people!
User, Client and client representative: as we will see later, one of
the most effective enablers of a #NoEstimates approach, is a savvy client
representative. No matter if it is a Scrum Product Owner, or someone
from your client’s organization or even a team of people performing this
role as a Product Management team: if you have someone that is able to
divide your work in chunks of small enough work-items and prioritize
them according to business value, it will make your life easier in so many
ways that I wrote a book about it - this book, of course. On the other
hand, a ‘bad’ Product Owner or client representative can have a very
negative impact in organization by not helping them focus on the most
valuable deliverables, or worse: trying to get so much work started that
the whole organization grinds to a halt. Given the potential impact of a
Product Owner in the organizational performance, it amazes me that the
main focus of many organizations seem to be on training only team
members or Scrum Masters. While they ignore the education and
improvements necessary in management and product ownership.
Workload and / or focus factor: having teams constantly changing
their focus between different projects or having to attend to bug fixes
every day, small requests, or side projects can dramatically increase
variability in the pace of work. Not to mention the effect on teams’
morale, product quality and organizational performance. In my
experience, teams constantly shifting from project to project have a
significant performance decrease when compared to teams that are
allowed to focus on one project at a time. On the other hand, at the end of
the day, both teams will report ‘8 worked hours’, and many companies
will consider that both teams ‘produced’ the same.
Market and competitors: introducing your products to new markets
can bring variability in the form of new requests, adaptation needs,
regulations compliance and other requests for changes. Similarly, when
new competitors or new products enter our market, our plans will
change, which will inject unexpected variability in the project.
Dependencies / specialization: in environments where the norm is
high specialization and dependencies between production units,
departments and even team members, variability is higher because of
bottlenecks that constantly emerge when and where we least expect.
Hence why methods such as Scrum advocate the cross-functional team as
the unit of productive work in software development organizations.
90 Variability
Cross-functional teams reduce variability by reducing dependencies. But

there are also other causes of variability, for example, some companies
assume that every Story requires X% analysis, Y% development, Z%
unit testing, with X,Y and Z all being fixed. But for some items, it could
be that doing a lot more analysis could even lead to 0 development: the
feature could be configured Instead of developed. Therefore the
composition of the team will cause variation in the estimation of the
work being analyzed and therefore cause variation in the overall
project.32
Waiting for availability: Waiting happens when a work-item is
ready to be worked on (the requirements are ready, or the design is
ready, or the code is written), but it must wait for the people with the
right skills to be available. The time work-items spend waiting to be
picked up can amount to more than 90% of the calendar time it takes to
deliver the work item. These wait times are also very hard to estimate
because they depend on many factors. When you ask teams to estimate
their work, don’t forget that they will only estimate the time they actually
work on the item, not how long the item will spend waiting. These wait
times can have a very large impact on the overall schedule for a project.
With all these sources of variability in performance, it is amazing that
people ask for accurate, precise, fixed estimates and commitment at the
beginning of a project. This is the time in the lifecycle of the project
when we know less about what is going to happen. And don’t forget: the
people making commitments to deliver on a particular deadline, scope
and budget usually have neither control over these sources of variability,
nor authority to re-negotiate deadlines, budget or scope when variability
kicks in!
The higher the variability, the harder it will be to predict the
throughput of completed work; therefore, any investment on reducing
variability will impact the product development team’s reliability and
predictability. Here are some techniques you can use to reduce sources of
variability in throughput for your organization:
• Stabilize your teams and avoid constantly changing people from

one team or project to another.
• Define clear priorities, reduce dependencies and allow people to
work on one thing at a time, finishing it before starting a new
work item.

32 A special thank you to Maikel Vandorpe for the explanation regarding dependency on
the team composition.
• Build quality into the whole production process, do not try to

inspect quality in33 at the end of the line; ensure that no defects
are passed down to the next step in the line.
• Enforce cross-functional work groups and generalizing-
specialist34 teams, which can solve problems in parts of the
product for which the specialists are absent, yet focus on specific
areas where they have long-term experience (aka T-Shaped
professionals).
• Standardize and automate where possible. This will allow your
teams to focus on actually getting the maximum amount of work
done that is possible.
• Protect the team from outside interruptions that disturb their
focus and typically cause uncontrolled multi-tasking.
• Freeze scope inside iterations and allow the team to work on
delivering the most important work, without context switching
that costs them time and takes focus away from the most
important work.
In the software industry, teams and organizations are forced to adopt

new technologies, to change their domains of knowledge, or simply work
in new projects. It is precisely in these cases that the #NoEstimates
approach delivers the best results. It is much more appropriate to look at
actual throughput (work delivered to the quality expected), than trying to
estimate work done in a previously unknown domain, with a new
technology, a new team, for a new project or client, etc.
For example, assume you are a competitor to Facebook or Google.
Can you estimate how much Facebook or Google are going to innovate
during the next 12 months? Not likely. It is a much better strategy to
improve your capacity to respond to whatever will come your way, no
matter what your competitors will come up with, or come up with

33 Inspecting quality in: using reviews, or quality checks to help increase quality, instead
of designing a work method that prevents mistakes from happening. The latter is often
referred to as error-proofing.
34 A generalizing specialist is a specialist that can help the team progress by working in
other areas where they are not the expert, but have enough knowledge to be able to help
deliver certain work items. This is important because it reduces wait times, a major cause
of variability in software development processes.
92 Estimation vs. Prioritization
strategies that force your competitors to respond and adapt to you

instead. When you are ready to respond quickly, no matter what your
competitors come up with, you will be able to respond and adapt.
Estimation vs. Prioritization

Scrum teams all over the world are asked to estimate the Product
Backlog.
The Product Backlog should be a description of the product, feature
by feature in priority order. Once you know what is the most important
functionality to help your customers and grow your business, you then
break that functionality down – in priority order. And this is a very
important approach when you want to focus on business value:
prioritization comes before estimation.
It is common that managers and business people say “I need to know
the estimate, the cost of every feature, so I can properly prioritize.” The
immediate consequence of this statement is that estimates become the
real “value” for a feature. No one wants to commit a team or a project to
a long feature because we have “lower hanging fruit”. This dynamic will
slowly, but surely, destroy the value of your product and lead you to
create a mediocre product. No matter what you try to do, the estimates
for features will drag you down to mediocrity. And the reason is simple
and easy to understand: because it is so easy to do first what is
considered “cheaper”.
My advice is simple: focus on value first, and then figure out how to
deliver that value as quickly as possible. Don’t estimate your way into
excuses. Deliver it, bit by bit, incrementally.


Delivering value in minimum sized increments (also known as:
Minimum Viable Product or MVP) is not just a trendy software
development approach. It is a risk mitigation strategy that uses the Agile
principle of delivering working software early and often for your
business benefit: lower risk and more value.
Estimating the whole Product Backlog up front does not reduce your
main risk: business risk, also known as the risk of delivering the wrong
things. But having the right prioritization will. What this means is that
you should invest your time in spotting the most valuable features in the
Product Backlog that could constitute a first, rough, small version of the
product (hint: ‘all of them’ is not the correct answer). Then make
relentless progress in delivering the minimum subset of those features
that will deliver the necessary value to your customers.
Walking at Random
The traditional approach to estimating a project consists of breaking
the project into work packages, creating a list of tasks, studying
dependencies, estimating every task, adding them all together to see
when the project could be completed. When asked for a more accurate
estimate, teams will estimate to an even finer level of granularity,
perhaps estimating tasks that could be implemented in 2 or 4 hours. Then
they add them all in order to have a more accurate estimate.
94 Estimation vs. Prioritization
But that is not the only way of doing things, nor the most advisable in
many situations.
Let’s say that you want to predict how the stock market is going to
perform in the next ten years. You could go study each stock and try to
figure out how it is going to perform, then add all performances together
and obtain a 'grand total'. But no market analyst will advise that
approach. Instead, what they would do is study how the stock market
performed during the last 100 years, then see if we can use that in order
to forecast performance over the next several years.
What would this idea look like when applied to a software project?
Let's say we conduct an analysis of the last 200 features and we end up
with this kind of graph:

Let's say that you find that the average feature duration was 3 days,
and there's a standard deviation of about 1.5 days. Now let's say that
there's a new project coming in and it has 100 features. You probably
don't know the size of feature 1 or feature 37, since you have not done
any kind of estimation, just a functional definition. But would it be
unreasonable to expect that these hundred features will require sometime
between 300 and 450 days? Compare that to an estimate of 100 or 1000
days for the same features.
There are some situations where this forecasting can't be made, and
those are the ones where there is higher variability expected in the next
project because of a change in technology, team, customer
representative… But in those cases, would a feature-by-feature estimate
be more accurate, even feasible?
Let’s do a thought experiment – a Gedanken or Gedanken-
experiment. Ángel Medinilla, this book’s fantastic illustrator, calls this
the ‘Perfect Product Owner’ Gedanken.
Imagine a perfect Product Owner. This Product Owner has the mutant
superpower of being able to divide any project into stories of only 3
relatively small sizes. For every story size, there’s a statistical outcome
in terms of how long does a team need in order to finish it – like, for
example, small stories are finished in one to three days, medium stories
are finished in three to six days, big stories are finished in six to twelve
days.
We don’t know up-front if a story is small, medium or big – we only
find out when it is finished and we realize how long it took us. If this
super Product Owner existed in reality he would produce stories so that:
• There would be nothing bigger than ‘Big’.

• Sizes would be coming randomly – e.g. not all the small stories
are at the beginning of the project and all the big ones are at the
end.
• Even not knowing if the next story would be small, medium or
big, the statistical distribution of the sizes would be constant and
known over time.
96 So… Rethinking Estimates

You don’t know what’s coming next, but you can predict the overall
behavior over time. If you were to create a histogram, characterize the
statistical distribution in the form of a median and a standard deviation
and, if a project is divided in 100 stories and the median is 3.5 days, with
a standard deviation of 1.5 days, would it be crazy to say ‘it absolutely
looks like a 350 days project, worst case 500’?
The only “trick” we required in the Gedanken was a savvy Product
Owner that is able to consistently divide projects into stories that are
small enough. Even if you can’t perfectly determine what’s going to
happen in the future; this ability to slice the work into “small enough”
work-items or stories will give you a very high degree of throughput
predictability.
So… Rethinking Estimates

What are you really trying to achieve with the use of estimates?
What's the intrinsic value of estimates?
Can you really use estimates to accurately predict what is going to
happen, when is the project going to be ready? How long each work-item
is going to take? How much will the project cost? And how many people
and what resources will be needed?
In this chapter you read about the concerns regarding the accuracy or
value of estimates. Even if you estimate your project with great
investment of time, those estimates will not help you manage the
surprises that inevitably come up during a project, and in fact can make
your work much harder if certain hard-dependencies cannot be resolved
because of an error in estimation. Invariably plans fail, or need to
change, and estimates must change with them.
A better way to manage your projects is to acknowledge uncertainty,
embrace change and fix the hardest constraints (time and people plus
resources) while letting uncertainty be managed through a variable
scope. Focus on delivering the most important part of your product early
in the project and delay the less important and 'nice to have features'.
This approach allows you to work on features identified after the
project has started, when you find that these features are more valuable.
This approach also allows you to drop features that might be considered
less valuable, dedicate more time to the most valuable features and
reduce scope of others.
This approach has also been in use by many in the Agile community,
and some call it "value driven" software development, as opposed to
"scope driven" software development.
The Predictability Paradox

“The best way to achieve predictable software development outcomes is
to start early, learn constantly, commit late, and deliver fast. This may
seem to cut against the grain of conventional project management
practice, which is supposed to give more managed, predictable results.
But predictability is a funny thing; you cannot build with confidence on a
shifting foundation. The problem with conventional approaches is that
they assume the foundation is firm; they have little tolerance for change.”
Mary Poppendieck - The Predictability Paradox
Predictability is the impossible quest of management. Predictability is

important because we can base good decisions on what we know to be
predictable. Predictability is what we seek, but how can we achieve it?
And what does predictability really mean for a software project,
especially one in crisis like Carmen’s?

CHAPTER 4
HOW NOESTIMATES CAN HELP YOU

MANAGE A PROJECT IN CRISIS
The project will be done in three months, give or take a week or two.”
I remember saying these very same words in a top management
meeting. The number – three months – was not arbitrary. It was the result
of in depth analysis, task breakdown (yes, even I did waterfall in my
day), and a lot of internal meetings to get people assigned to the project
“at the right time”.
The managers in that meeting were happy. Very happy. This was also the
number they wanted to hear. They were so happy they did not hear how I
completed that phrase:
“But only if everything goes according to plan. We have no buffer
with this schedule.”
This is not a unique situation. All of us that have managed projects
have been in a similar situation. We’ve all been influenced by overt and
100
How NoEstimates can help you manage a project in crisis 101
covert expectations from our superiors. In some cases, we’ve also been
in Carmen’s shoes, managing a project on which the company’s future
depended on. A lot of sleepless nights follow.
How can we answer this question? How to know when the project
will be done without estimating all the work? That is the key question.
(“When will the project be done?” can be replaced with “how much will
it cost?” the process we go through is the same).
Past approaches to estimation have not worked well, in chapter 1 I
shared the data. At one of the companies where I worked, projects were,
on average, 62% late. An average 100 day project would last 162 days!
And even worse, several projects took longer (or much longer) than 162
days!35
Would you bet your company’s future on that kind of track record? I
wouldn’t. And neither will Carmen.
We need a better way to predict the end date (or final cost) for our
projects that is not dependent on moody managers coming down and
putting pressure on project managers to “improve” the estimates.
Two months later…

“Carmen, we have a review of the project with the Client next week.
How are things going, what kind of progress can we show them?” Asked
her boss.
“Good Morning sir. Yes, we do have the requirements delivery and
the Earned Value Management reports that I showed you just
yesterday.”
“That is great Carmen, but I was asking if we can show them working
software. You know, to make a good impression.”
Carmen felt the ground disappearing from under her feet. The
requirements for this project had been written in a way that the software
could only be demonstrated after most of those requirements were
implemented. They were only two months into a 12 month development
phase, there was nothing to show! The testers hadn’t even been hired yet.
What could she do now?

35 Thank you to Troy Maggennis for helping me correct the conclusion in this paragraph.
102 The Predictability Paradox
“Sir,” she started, “you knew from the start that this was going to be
a project with a long development cycle. It is quite impossible to show
any working software until we have requirements implemented in all
architectural layers. We only just started to develop the first layers like
database, services, etc. We have nothing to show…”
“I’m sure you can think of something for next week, you always do!”

How can Carmen show the real progress of the project? When
requirements are written in a layered fashion, progress can only be
assessed at a component level.

More importantly, overall progress at the project level can only be
assessed when all layers of the software have implemented a larger part
of the overall functionality. How can Carmen show progress? She could
count the number of requirements implemented; the costs incurred, and
compare that to the baseline that she created when estimating the project
(how many, and which requirements should have been implemented by
now? And how much money should we have spent by now?) But the
truth is that these are very misleading measures of progress.
Let’s look at an example.
Here’s the graph from a project that followed the same
implementation strategy that Carmen is following. Take a look at the
number of open bugs found. If you were the project manager for this
project, when do you think the project would be ready for release?

104 The Predictability Paradox

Figure 6 - Data from a project using Rational Unified Process (RUP), a linear
process model. This represents the project bug, or defect-curves (cumulative
open, Submitted, and Closed) at the end of development phase, and beginning of
validation phase (phases are used in RUP).
That’s right, no one can say when that project will be done. In fact,
we can see from the graph that all requirements were implemented long
ago (the development phase already ended), but the number of open
issues just keeps growing and no one in their right mind would release
that software. If we batch (accumulate and delay) the fixing of bugs to
the end of the project – which we have to do if we take the layered
approach – we will not know the real progress until we start fixing those
bugs, and very likely later than that.
A simpler way to see this is: if you have a 800 man/hour project, and
someone says that you have actually invested 400 man/hours, can you
say with confidence that you are 50% done?

Is there an alternative that Carmen can use? Yes! You have the
#NoEstimates alternative that creates true visibility to progress in a
software project.
Visible Progress
The main goal of my approach to #NoEstimates is to help evaluate
progress in a concrete – and easy to implement – way.
There are many ways to specify a project. For example, we can start
by doing a business analysis and create a requirements document. The
requirements document can be useful in generating consensus on what
the project should deliver, and what are the concrete problems you will
tackle with the project. However, requirements – in their classical form –
are not practical when trying to assess progress (aka progress follow-up).
Remember the vertical vs. horizontal division of work graph above?
If you have started (but not completed) 50% of the requirements in
your project how far away are you from completion? Many people in the
world today still think that work that is started (but not completed) is
progress in a software project. That is wrong. Code (implemented
requirements) is only a liability. It turns into an asset only when a user
can create value with it!
106 Visible Progress
“Working software is the primary measure of progress”
- From the Agile Manifesto
Following this principle from the Agile Manifesto requires us to write

requirements in a way that allows you to do two very important things:
• Requirements need to be written in a way that allows you to

measure progress early and often during the project.
• Requirements need to be written in a way that provides you with
the necessary flexibility to make decisions on what part of each
requirement will be implemented later, when you better
understand the system, and the business needs.
Let’s look at what happened in the example we started studying

above:

Figure 7 - Data from a project using Rational Unified Process, a linear process
model. This represents the project bug-curve at the time of release.
In the chart above you can see that development stopped about 1/3 of
the way through the project. If you had asked the developers they would
have said that at that point the project was almost done. After all, they
already had implemented all the requirements they were asked to
implement. In reality they were not even close to 50% completion.
Here’s why: when you implement all of the requirements you have only
completed a small portion of the work that needs to be completed for the
functionality (or capabilities) of the system to be useful to the end user.
When a developer says “I’m done” what they mean is: “I’ve coded in
what I think is the meaning of the requirement you gave me.” After this
work is done, you need to verify two things:
• First, you need to verify that the developer has the same
understanding as someone else – typically a tester – who looks at
the software from the customer point of view.
• Second, we need to ask the end customer if what is implemented
really solves the problem that it was intended to solve.
Even in the best-managed projects the first of these verifications is

often done too late, but rarely anyone cares about the second type of
verification until it is truly too late to recover without major impact on
project schedule, project cost or both.
The consequences of the failure to execute these two verification
steps are:
• You don’t have actionable information that allows you to

effectively measure progress. Remember this: you are not done,
when you think you are done, but only when the customer says
you are done.
• When you finally find out that the project is late, you don’t know
what can be dropped from the scope of the project (you may
even have all requirements implemented like the example
above). And even if you know what needs to be removed, you
can’t remove it because all requirements are implemented and
they depend on each other. The required functionality is
implemented; it just does not solve the problems they were
supposed to solve.
108 Visible Progress

With my #NoEstimates approach, I try to avoid these problems by
using the following progress criteria which is based on work by many
people in the Agile software development community:
• Always implementing independent Stories (more on that below).

Stories are requirements (written in a specific format) that
explain what is the problem the user of the software needs to
solve.
• Following progress every day, not by milestone completion. In
Figure 6 we see a project that is “feature complete” – one of the
key milestones in most software projects still today – but has
nothing that can be delivered. Here’s the key take away: progress
in software is measured by running (it can be demonstrated live),
tested (high quality and user-accepted) software, i.e. Running-
Tested-Stories. RTS, Running-Tested-Stories is the only metric
that reliably describes the progress in a software project36.
You can implement progress follow-up by delivering completely each

piece of functionality (I call them Stories) in a way that fulfills the two
criteria listed above. Here’s what the original chart above would have
looked like if the project had been measured by the number of Running-
Tested-Stories delivered every day:

Figure 8 – RTS (Running-Tested-Stories) burn down for the project in Figure 2
Even if the Stories take longer to implement than one day, they
should follow some #NoEstimates slicing principles:

36 Others in the agile community have used a similar metric. I have found the first
reference to Running Tested Features (similar to RTS) from Ron Jeffries’ blog in 2004:
http://ronjeffries.com/xprog/articles/jatrtsmetric/ And the first reference to Running
Tested Stories from a presentation by Simon Baker in May 2006: (PDF)
http://computertrainingcenters.com/wp-
content/uploads/2012/09/IntroductionToScrum.pdf

110 Actionable Information
• There should be no ‘huge’ Stories (e.g. in Scrum: bigger than

half a sprint counts as ‘too big’ and should be split.)
• Several independent Stories should fit into a Sprint or a period of
2 weeks if not using 2-week Sprints or Scrum. Six to twelve
Stories delivered in a 2-week period is a good rule of thumb.
• The statistical distribution of small-medium-big Stories should
remain constant through an extended period of time - i.e., not
having all the big items at the beginning of the project (like one
story about “setting up infrastructure”) and then all the small
ones at the end.
However, even if we follow progress the right way, we still need to

prepare for surprises. Of course certain things will take more than we
expected (remember Hofstadter’s Law?). So, following progress with
#NoEstimates is not enough. We also need to have actionable
information.
Actionable Information
Actionable information is information that allows you to make
decisions that positively affect the success of the project. It is
information that is typically expressed in a way that offers a conclusion.
For example: Because we only have 3 Stories implemented (Running-
Tested-Stories or RTS’s), but we should have 6 Stories implemented at
this point, we must reduce the scope of this release if we want to deliver
on time.
RTS (Running Tested Stories) is the metric in #NoEstimates that
allows you to act on the progress and manage the project to meet a
particular release date. It is the equivalent to ‘Working Software’ in the
Agile Manifesto, and hence it is the main measure of progress, the only
one that really counts.

In the case above we see a typical project delivery rate (in a burn-
down chart). By looking at the chart above one can easily see that the
project presents some risks of missing the deadline, but is not in a critical
situation. If your project follows a similar burn down trend, you know
that you need to reduce the scope. Reducing scope can only be done if
the work left in the backlog is independent from each other and from the
functionality already delivered. The opposite of independent Stories in
software is the concept of layered requirements. Layered requirements
are requirements that build on each other (different layers of the
architecture, for example) in order to deliver the necessary functionality.
What are Independent Stories?

In the Agile World, User Stories were widely adopted very early on.
But few understand the immense power of that tool. Stories should have
a set of properties commonly called as INVEST37:
• I: independent Stories are Stories that can be implemented

37 The INVEST mnemonic is credited to Bill Wake and his article
INVEST in Good Stories, and SMART Tasks
112 What are Independent Stories?
separately without depending on other Stories. You create

independent Stories by slicing the project into vertical
requirements (Stories) that can be verified individually.
• N: negotiable Stories are Stories that define a very clear
capability for the system, but do not dictate an implementation
strategy, or very specific functional requirements. This property
allows the development team to select an implementation
strategy that best suits the project when the time comes to
implement that Story, and allows the customer to be engaged in
defining the detailed functionality later on based on the running
demo of the software.
• V: valuable Stories are Stories that have a concrete value to the
customer or user of the product being created. The opposite
would be a story that helps the developer but not the customer.
• E: Essential, meaning that every story is absolutely required for
the product to be viable. To be Essential, a story must not only
be valuable, but it’s removal must make the product unusable or
unsellable. Earlier INVEST definitions included ‘Estimatable’ in
the sense that there would be some understanding and specific
definition of the story that allowed us to cast an estimate if we
wanted to. #NoEstimates focuses on value instead. The goal is to
do only what is essential to the project’s success.
• S: small Stories are Stories that are well understood by the team
and can be implemented in a short time frame. With the
#NoEstimates approach I advocate that Stories should be
between 0,5 and 1 man-days of effort. Establish that as your
target, and slowly move towards that size. Your visibility to
progress and quality will slowly increase as the size of the
Stories decreases. To determine if a story is small enough I ask:
“Tom, can you get this story done by tomorrow?” There’s a
world of difference in this question, when compared to “Tom,
when could you have this story done?” The first question is
intuitive (some call in Flashtimate), and not a result of a detailed
analysis of each of the component tasks for that Story. Another
difference is that we don’t ask this from all Stories in the
backlog, but only the Stories that we will start working on
immediately.
• T: testable Stories are verifiable. They include, for example, a set
of criteria that define when the story is done. These criteria are
called Acceptance Criteria and expressed from the point of view
of the end-user or customer.
INVEST Stories give the project team information and the tools
necessary to actively manage the scope of the project because:
• Each Story can be dropped from the project without affecting the
overall project delivery.
• Each Story is small enough and all Stories are typically pretty
homogeneous in size, which means that you can focus on their
value, instead of their cost when making a decision. Value is an
important input for decisions (actions), and can be easily
assessed by discussing the use/benefit of a particular Story
directly with the customers/users.
• By making Stories small you also get faster feedback on the
progress of the project. The long term rate of delivered RTS’s
should converge to 1 RTS per team member per day. When the
number of delivered RTS’s is zero for one team more than 1 or 2
days you know you have to act.
How does this help Carmen? Let’s take a look.
“I need to find a way to measure the real progress of this project. All
these requirements that are in progress really give me no information
about what is actually ready to go, or what is just started. Where could I
find ideas on how to measure progress?”
It is dark outside, all her colleagues have left for the day, but Carmen
is stuck. She’s been scratching her head to come up with a verifiable
progress metrics for her project. There are only a few days left to the
progress report meeting with the customer. A lot is at stake.
“Hi Carmen! What are you doing here so late?”
It was Herman. “But why is Herman here at this time?” Carmen
asked herself. “Err… Herman, why are you here? Did you come back to
do some work?”
“No way! I value my private time!” He smiled, “I came back to pick
up that #NoEstimates book that Jerome asked about last week. I have
another friend who wants to read the book and we were just downstairs
having a few beers, so I decided to pick up the book immediately. When
somebody asks, I want to give them the book right away, so they don’t
have time to lose interest!” He winked.
“Wait, #NoEstimates? What is that all about?” Carmen asked.
“You don’t know? Oh my god! You are working on Big Fish, you
absolutely must read the book. Do you have a kindle?”
“Yes…”
“Right, go to Amazon and buy the book immediately. Check chapter 4
today, before you go home. It is an easy read – the author created a very
good story that helps follow the concepts in a fast-paced manner. Read
chapter 4 and let’s talk more tomorrow. Have to run now.” Herman left
to meet his friend. Carmen was interested and checked the book, bought
it and started reading Chapter 4.
“Running Tested Stories…” She repeated while reading the book,
“can I apply this to my project? It seems like a good way to follow
progress, and I can see the similarities to the Earned Value Management
ideas I’ve used in the past. But where should I start?”
Many projects have only a list of requirements as the definition of

scope. If you want to use RTS’s as a way to measure progress you must
define the capabilities of the system in the form of INVEST Stories.
Remember that each Story must follow the INVEST properties!
Once you have a list of RTS’s for your project, you can then plot the
progress of the project by completing each INVEST Stories in order of
priority.
How did Carmen do it? Let’s watch.
“I have to count the RTS’s we’ve delivered so far… How can I do it?
I know! I’ll list the requirements that are expressed as functionality into
a list of INVEST Stories. Then I’ll group each of the other requirements
under the relevant Story. If some are left, I can create more Stories for
each of them. Let’s get to work.”
Many, many hours later…
“Great! I have my first list of INVEST Stories!
“The project feels so much clear now.” Carmen felt she had just
climbed Mount Everest on a clear day. And what she saw was an
amazing landscape. She could see her project clearly for the very first
time!
“Now to plot the progress,” she thought.
Carmen started to analyze each Story to classify them into “done”
and “not done”. After some more hours of detailed analysis and
searches through her inbox she came up with this:

“Flat line…” She could not believe her eyes.
“So much work has been done in this project, so much has been
invested and no RTS progress… We’ve written many, many pages of
requirements documents, test specifications, design document. We’ve
spent countless hours in meetings making decisions that will affect the
project. But the RTS count tells us that we have no progress. Nothing to
show for all that effort!” Carmen did not say what was in her mind out
loud, but her body language said it all: the shoulders dropped, her eyes
looked gloomy and she sighed. She was the image of frustration.
“What can I do now? Why haven’t we delivered any RTS?” It was too
late to answer those questions. She only had time to dash home, take a
quick shower and come back to the office in time for the weekly progress
review with the project team.
Later that day…
Carmen goes through the progress using the Work-Breakdown-
Structure and the Earned Value Management38 presentation she had

38 More on Earned Value Managment:
https://en.wikipedia.org/wiki/Earned_value_management
prepared. The audience was mute. Very few questions were asked. After
all the information was “neutral”, there were no big visible disasters in
the project. A few questions were open, but nothing that the project team
was not familiar with. But then…
“However,” Carmen continued, “after reviewing and redoing the
project plan for many hours during most of last night, I found that the
progress reports we are using are completely inadequate to show us the
real progress of the project from our customer’s point of view.” She
waited to see the reaction of the audience. Nothing. Just silence and
puzzled looks.
“What do you mean?” Finally asked her boss.
“Well,” started Carmen, “the fact is that our requirements are indeed
being implemented. We do see progress from an EVM point of view,
but…”
“But what?” Insisted her boss.
“But, the truth is…” Carmen hesitated. “The truth is that we have
nothing actually running that we could show the customer in the
progress meeting next week. We have many requirements implemented,
but if we look at the project from the point of view of the end-user we
have nothing, really nothing, we can show!”
“How is that possible?” The whole team asked in unison.
Carmen continued. “Remember when we reviewed the requirements
document back when we were creating the bid? Herman asked us, how
we knew we were done with each requirement. And we answered that we
would know when we would put them all together for the first system
testing rounds, right?”
“Yes, but I’m not getting your point,” commented a team member,
“that is how we’ve always done it. And it worked!”
“Correct, it worked before.” Continued Carmen. “But for this project
we are being asked to report progress with running software every
month. That is new. We’ve never had to do that before because most of
our projects were small and we went from start to end without having to
demonstrate progress.”
Carmen stopped for a moment, and then decided to show them the
RTS progress graph she created. The flat line was about to come out of
the closet. She was nervous…
“Here’s how our progress from a user perspective looks like.”
Carmen showed them the same graph she had prepared during the early
hours of the morning.
Albert couldn’t be silent anymore: “How is that possible? I’ve
implemented at least 10 of the requirements, and I’m only one of the 20
developers in the team!”
“You are right Albert,” Carmen reassured him, “but the

requirements you’ve implemented are all in the database and service
layers. In fact most of the requirements we’ve implemented are in those
areas. The fact is that we don’t have one single end-to-end capability
implemented.”
“If we look at the capabilities we need to deliver,” Carmen listed the
INVEST Stories on the screen, “we can see that we have started working
on five of the 64 capabilities we need to implement, but we have not
finished any of them. Albert, tell me, how many of your requirements
have been tested by Janet and her testing team?”
“None, they are still writing the test specification,” replied Albert.
“Exactly! We have done a lot of work, and we’ve started many things.
But the truth is that we have finished nothing from our end-users point of
view.”
By plotting the progress of the project in RTS’s Carmen is giving her
team:
• Clear and verifiable progress information.

• Actionable information.
“Carmen,” started her boss, “what do you suggest we do now?”

“That’s what I want to discuss with you and the team. I have an idea,
but you all must be on board or it will not work.”
Carmen explains her ideas to the team, and at the end they all
committed to working as she proposed.
“You have the go ahead, Carmen. But I want to see some progress by
next week already or we will have nothing to show the customer!”
Finished her boss.
How do you recover from a situation like this? How can the use of
#NoEstimates help get a project on track? That’s the topic for the next
chapter.

CHAPTER 5
THE FAST TRACK TO NOESTIMATES
“You’ve reached Herman, how may I help you?”

“Herman, hi! It’s Carmen.”
“Hi Carmen. What’s up? Are you at the office?”
“Yes, I meant to ask you if we could … Er… have a chat…”
“Sure, when?”
“Right now?”
“Wow. Must be something important.”
“Yes, it is…” Carmen said, sounding unusually serious.
“OK, I’ll come right over.”
Carmen had just left the meeting with her boss. The stakes were very
high. She had committed to show progress in the project during the
meeting next week. How can she define progress in a way that is
actionable? How can she ensure progress in a project that was almost two
months in, and had a flat line of Running-Tested-Stories (RTS)?
120
The Fast Track to NoEstimates 121
“Herman, I have a serious problem that I need your help with.”

Herman stepped back and asked: “Erm, OK. What problem?”
“I presented the RTS line for the Big Fish project to my boss. The line
was flat. We have already spent almost two months on this project and
have nothing to show for it”
“You… you did what?” Herman looked shocked.
“Yes, I finally read up on that #NoEstimates ideas that you have been
talking about. I must confess I thought that was just airy-fairy stuff, but I
did it. I applied it to my project. I broke down the requirements into
INVEST Stories. I plotted the progress by Running Tested Stories (RTS)
and the line is flat! What should I do now?” Carmen looked accusingly.
“Well, why didn’t you ask me before doing that? I could have told you
from the start of the project that your RTS line would be flat at least for
the first few months. That’s how waterfall projects normally behave. A
lot of work on developing separate horizontal layers of the software that,
hopefully, at the end come together in actual running software.” Herman
tried to explain.
“I know, I know. You told me that same story many times. But now it
is a real project…” Carmen stopped. “I’m sorry Herman, I did not mean
to say that. I’m just stressed out. My boss allowed me to use your
#NoEstimates approach, but now I need to show progress in 1 week!”
“OK, let’s start from the beginning, Carmen. Describe the situation
to me.”
Carmen explained the project situation, just like she had done
minutes before to her team. Herman looked concentrated, asked a few
questions and then stated:
“Looks like you need to start cutting scope out, or at least delay work
to the second delivery later this year.” Herman looked convinced.
“How can you say that? I mean, we just worked on this project for a
few months, the whole project may take a lot longer. It’s just…” Carmen
hesitated.
“Just what?” Asked Herman. “You need to be honest with me! I can’t
help you if you don’t tell me what is at stake.”
Carmen needed Herman’s help. Herman had been managing projects
for at least as long as she had. And he had applied #NoEstimates in all of
his projects. Sure, all his projects were relatively small because no one
would trust him to manage a large project on account of the unorthodox
#NoEstimates approach he used. But the stakes were high and Carmen’s
mentor, her boss, was not a viable alternative to ask for help right now.
Not after she made the strong statement about progress earlier that day.
Carmen decided to tell him everything. Once she had told Herman
everything…
“Wow, that’s heavy stuff!” Said Herman and sighed. “Anyway, I

know you need my help, so let’s get to work.”
“But, you have your project ongoing, don’t you need to check your
calendar?” Asked Carmen, not believing her luck.
“My projects are easy, the teams have a clear way to check progress
and they can make scope decisions without me. I’ve built a system for
them that they can easily use. The truth is that most of my projects run
very well on auto-pilot.” Said Herman with a wink. “This project
however… Let’s just say that it will be a challenge to get it on track, but
I believe we can do it.”
Herman picked up a piece of paper and started asking questions.
Herman wants to help Carmen, but before he can do that, he needs to

understand what is at stake. Both in terms of project delivery as well as
short-term customer relationships. Here are the questions he will ask
Carmen:
• What are your intermediary deliveries going to be used for?

• When does the project need to go live with the first release?
• What does the customer expect to accomplish with that first
release?
• How many, and which, Running Tested Stories (RTS) do you
need to deliver until that first release?
• How many RTSs have you successfully delivered during the last
2 months (the length of the project until then)?
With these questions Herman is trying to establish the following:
• What is the most important value to be delivered by the project

from the customer’s perspective? This may include a significant
cost-saving functionality; a new Feature that will make the
product win awards, or something that is otherwise significant
for the customer.
• What is the amount of work that needs to be completed in
number of Stories to be delivered? Note that without the
INVEST properties for each Story we could not use the number
of Stories to assess the delivery rate or assess future progress. If
each Story is only complete when an arbitrary number of other
Stories are delivered, then all those Stories need to be delivered
before we see progress.

• When should the next delivery of the project happen? Delivery
means something that will go into use by the customer. You may
have many project deliveries during the whole length of the
project, but those will be internal or testing deliveries.
With the answers to questions 2 and 3 we can build a progress

“yardstick”. For example, if you have 10 weeks to the next delivery and
you have 20 Stories that should go into that delivery, you know you need
to deliver an average of 2 Stories per week to make that delivery. If you
deliver less, you should then evaluate the scope and make the necessary
reduction. If you deliver more, you are on target and may be able to
deliver more functionality at the end of the 10 weeks.
However, the first question about the purpose of each release is the
most important. By understanding the goal of your customer you will be
able to “steer” the delivery by evaluating, prioritizing and ultimately
removing Stories from that delivery.
Without an answer to the first question, the most important tool for
the #NoEstimates practitioner (scope management) will not be available.

“Wow, we have way too many things to deliver for the first delivery!
No way I can show this graph to the customer when we have the progress
review next week. He’ll think we haven’t done anything!” Carmen had
just realized the extent of the project delay. There were too many Stories
to deliver, even for the first release! Especially when she considered that
she had zero RTSs delivered so far because of the layering of
requirements and implementation.
“But the first action that you need to take seems clear Carmen,” said
Herman, and waited for her reaction.
“Is it? I can’t see what to do, I feel overwhelmed,” replied Carmen.
“That’s OK. It’s normal to feel overwhelmed. After all, you just
discovered that your project is in jeopardy. But now you know that you
don’t have visibility to the rate of RTS delivery,” tried to lead Herman.
“Precisely! I don’t know what our progress rate is because we
haven’t yet delivered a single RTS, we’ve worked in many requirements,
we’ve worked for months and have nothing to show for it.” Carmen was
frustrated.
“Don’t despair Carmen. This is not good news, but it is actionable

information.”
“Actionable in what sense? I don’t get your point.” Carmen sounded
angry.
“You know that your first action should be to find what is your
project’s rate of progress,” – Herman said, “until then you are flying
blind, so to speak.”
“Right, but how do I do that?”
“We need to get your Stories to be small enough, the current Stories
are too large to give you any insight into progress. We have to make
those Stories smaller. What Stories are already in progress?”
“These here at the top of the list, I’ve highlighted them,” said
Carmen, while pointing to the list of Stories she had created the previous
night.
“Right, let’s make sure those are small enough. We’ll worry about the
rest later”
“And how do I do that?”
“Simple. Take this first one: As an enrollment nurse, I want to add the
health record of my patient to the database, so that the doctor can later
read the answers to the questions we ask when the patient arrives to the
hospital.”
“How would you break that down?” Asked Carmen curiously. “I
mean it can’t be smaller than that, right? That’s a pretty simple Story,
and it will probably take multiples weeks to get it implemented because
we have the UI team involved, then we have to run some tests with the
nurses, and the doctors. Then we have to run a live test, whereby a
business analyst will actually be at the hospital to play the role of the
enrollment nurse and test that the system actually works, etc.”
“Wow, calm down, you’ve covered many things already that we can
use to split this Story. Let’s take them one by one. Do you really need the
UI team involved before you start designing a UI for this functionality?”
Asked Herman.
Slicing User Stories to Assess Progress and Manage Scope

During the conversation that follows Herman will help Carmen slice
the User Story she just read into smaller, runnable, testable Stories. The
most important attribute of those Stories is that they be small. How
small? That depends on your need to assess progress. If you need to
assess progress every day in a project that lasts a few weeks, for
example, then your Stories should be completed at the rate of several per
week. As an example, you could aim to have about 1-day time boxed
126 Slicing User Stories to Assess Progress and Manage Scope
Stories, so that every day you can see that some Stories are delivered (or
not!), and everyday you can assess progress.
If your project is several months long, then assessing progress every
week may be enough and your Stories may be time boxed to a few days
(say 2-3 days).
Here’s a story of how my friend Ángel Medinilla used some of these
concepts to save a failing project:
I have a personal experience with an 18-month project. There

were 30 people in that project in three different teams. When we
looked at the data we saw that there were between 1 and 3
Stories delivered by every team in each 2-week period.
Even though there was some variation from week to week, a

consistent average of 5 to 6 Stories were finished every two
weeks by the three teams.
As we compared that to our backlog (which contained about 300

Stories) we realized that there was an obvious risk of not
delivering 90 to 125 Stories over the next 35 sprints (2 week
periods). So we decided to focus on the most important 200 or so
Stories as soon as possible. After prioritizing the 200 most
important Stories we just ourselves: “does this Story feel like it
could fit into a 2-week sprint?” If the answer was yes, we took it
in, if not, then we broken it down further. This was what some
will call “blink estimation”, and it worked for us in that project.
Not much time was wasted in those conversations; the goal was
to get started doing the work to assess if we were indeed able to
deliver that Story in 2 weeks.
Nine months into the project, a working version with roughly

120 Stories was available. The company decided to go live and
the project was stopped while the company re-planned and
focused on a more important project with Features that made
more sense than the ones that were identified and committed a
year ago. There are a lot of lessons to be learned from this story!
Ángel is right, this short story has many lessons to be learned. One
such lesson is that it is only when we start working on a Story that we
actually know how long it will take to deliver.
Another lesson is that breaking down Stories helps us assess progress
at the project level faster, and make the necessary (and inevitable) scope
decisions. Not all Stories are critical for any project. Discovering which
are, and delivering on those is where the value really is.
Finally, having a consistent rate of progress is more important than
estimating a project. This consistent rate of progress will help us steer the
project in a very concrete way: reduce work or re-prioritize work based
on actual progress data, instead of a guess at a plan that will invariably
change. This consistent rate of progress will be a key tool for Carmen as
well.
In her project, Carmen had to deliver visible progress information in 1
week therefore she did not have the luxury of waiting several days to
complete one Story. Her goal was to deliver several Stories that week so
that she could show progress as well as assess the time it takes to deliver
multiple Stories, which would in turn help her forecast future progress.
Slicing Stories to be small enough is a critical skill upon which
successful software projects build. There are many techniques that you
can use to achieve a decomposition into INVEST Stories that are small
enough for your needs. In this example we will take the Story at the top
of Carmen’s backlog to explain some of the techniques.

1. Slice along functional dependencies
In the Story above Carmen mentions a dependency on user interface
design. This is a classical example of functional dependency where one
team (the developers/testers) is dependent on the work of another team
(User Interface specialists) before they can complete the work. We can
slice the Story so that we create a clear division between those two types
of work or functional expertise. If we were to use this technique the
resulting Stories would be
• First, the original Story now without a dependency on the UI: As

an enrollment nurse, I want to add the health record of my
patient (using the draft user interface), so that the doctor can later
read the answers to the questions we ask when the patient arrives
to the hospital
• Then, the second Story with the dependency on the UI: As an
enrollment nurse, I want to have the User Interface optimized for
information input when I add the health record for my patient, so
that I can concentrate on asking questions and documenting the
answers.
Note how the first Story can be completed without involving the User
Interface specialists, and therefore be quickly completed; while the
second Story focuses on the role of the User Interface design for that
particular user (optimize for information input)39. The second Story

could focus on reducing the “movement” needed to introduce
information by, for example, designing an interface that guides the nurse
through the enrollment process in a way that does not require the use of a
mouse.
2. Slice to separate quick from time-intensive functionality
Another possible division of the original Story is to separate the quick
implementation aspects from the time-intensive ones, in order to be able
to complete part of the work by separating what can be done quickly
from what requires a longer implementation cycle. In this case we could
assume that the database – which is used by the existing legacy
application – will require much more work to be completed, so we may
decide to separate the input (data entered by the enrollment nurse) from
the database persistence strategy (entering that data to an existing
database that interacts with other applications beyond our control). The
new Stories could look like this:
• As an enrollment nurse, I want to create the health record of my

patient (using a temporary data storage), so that the doctor can
later read the answers to the questions we ask when the patient
arrives to the hospital.
• As a doctor I want the data that is entered by nurses when
receiving a patient at the hospital to be available in the same
application that I use for prescriptions, so that I can easily review
patient information during the consultation.
In this division of the Story we see that the data entered by nurses is
kept in a different storage solution (maybe a temporary database), and
then we add another Story that changes the storage strategy so that the
data is finally stored in the final database. This strategy for slicing may
be useful if the operational implementation of database changes is a
common bottleneck for the organization.

39 Editor’s note: It is worth noting that the ability to separate these stories hinges on
skills like: Design Patterns; Automated Unit Testing; Software design; and others. These
skills are usually not part of the skill set HR personnel look for when recruiting
programmers. They are never part of the skill sets specified when consultancies and
clients make business deals. The ability to slice stories hinge on a lot of other skills. This
may cause problems if no one is aware of the need for those skills.
This approach may add work to the project, however, it is also an

effective risk mitigation strategy. When you follow this strategy, you
may decide at some point to go live with the temporary solution (the
temporary storage in this example), and later change the implementation,
or pursue other high value Features instead. Not being able, or willing to
use this strategy may lead your project into a death march: where you are
committed to implement the permanent solution, but can’t deliver
anything until such solution is ready. Add some dependencies to other
functions (like the “storage team” in the organization and you have in
place the ingredients for a death march.
3. Slice along user/role separation
Not all acceptance criteria need to be included in one Story. A
strategy for slicing may be to explicitly exclude some of the user-specific
acceptance criteria into a Story to be implemented later so that we can
quickly show progress and receive feedback. The remaining Stories can
be added to the backlog and prioritized accordingly. One example is the
live test that Carmen referred to in her explanation, as well as the
changes we expect to come from that live test. Implementing this slicing
heuristics could give us the following Stories
• As a nurse lead user (a user that tests the product for the nurses),
I want to add the health record of my patient, so that the doctor
can later read the answers to the questions we ask when the
patient arrives to the hospital.
• As a enrollment nurse (the actual nurse at the hospital), I want to
have an intuitive and quick input method for the information I
collect from the patients, so that it is comfortable to enter
information even in time-critical patient situations.
In the example above we’ve introduced a few concepts (nurse lead

users and time-critical patient situations) in order to separate out the
aspects that affect the applicability of acceptance criteria. By separating
out the performance and user interface optimization into a different
Story, we are able to deliver some work without performing the live test,
one of the original acceptance criteria.
Another possible approach would be to separate the mandatory form
(without which data could not be entered) from the final form design
implementation. You can start by tackling the basic database operations,
and later on invest more time (if you have time) in improving the user
interaction design for the form. While the final design may significantly
improve the functional value of the application, you may still go to

market with the initial implementation, and later add the necessary
changes. This approach has the advantage that you will have feedback
from the users and will therefore understand better what needs to be
improved with the new design.
On the other hand, if you run out of time, you can still go live with the
original implementation, significantly reducing the risk of not being able
to deliver the product to the market.
Other Slicing Heuristics

There are many possible slicing heuristics that you can use to take a
large User Story and slice it into manageable, and most importantly,
progress uncovering parts.
As an example, you can slice following your user journey steps
(login, search, select, modify, accept, etcetera); you could use different
scenarios, roles, or personas; you could slice according to input/output
data; you could divide according to complexity, interfaces, current level
of knowledge, test case. And the list goes on.
Even when a Story looks like it can not be divided further, there is
always a way to bring it down to smaller, independent pieces that can be
developed and tested separately, giving you a better idea of progress than
the amount of hours you’ve put into a Story versus the “estimated” effort
to complete it. If you estimated 40 hours and you’ve put in 4 hours, can
you really say that you are 10% done? On the other hand, if you divide
the Feature in ten separate slices and you complete two of them, that’s a
far more tangible progress indicator.
132 Other Slicing Heuristics
“Working software is the primary measure of progress.”
Agile Manifesto
The most important aspects of slicing are:
• Each slice is independent (the I in INVEST). In other words,

each Story can be delivered independently from other Stories,
and accepted on its own.
• Even if each Story may not be “sellable”, it must be testable and
final, i.e. the team can make sure that a particular User Story has
been successfully completed according to a Definition of Done.
This Definition of Done is a litmus test that will allow you to
classify tiny parts of the whole project as completed, before the
whole project is done.
The focus on completing thin slices of functionality every day (or as

often as makes sense for your project) is what allows you to collect the
progress information you need to assess progress in your project, and
therefore show progress towards the final goal.
Early in each project, your top priority is not to ship something
meaningful to your customer, but to obtain information on capacity,
throughput, and backlog size. If you are able to slice your Stories so that
you can deliver 1 or 2 Stories per day, that will dramatically increase
your ability to both track, and steer your project! But even if you are not
able to reach this state, being able to deliver multiple Stories per team for
every iteration (in many cases iterations are about 2 weeks long) is also a
good start to reduce your estimation needs and have more tangible
progress information.

For more heuristics on how to slice Stories and some examples, look
at the resources at the end of the book and the links to blogs and sites that
explain how other people are able to slice large pieces of work into thin
slices of functionality.
Now, let’s get back to our story.
“But Herman, now that I have these 10 small Stories instead of the
one we started with I still have a problem: I don’t know how much time
all the rest of the work will take! This was only one Story!” Carmen was
not convinced.
“Absolutely correct! In fact you will not know how long the whole
project will take until you have either the whole backlog of INVEST
Stories sliced up (a bad idea) or until you have enough historical
information that you can infer the cycle time for every backlog item,
independently of size,” Herman explained.
“Oh, do you mean that this slicing of one Story is just a way to have
visible progress for this one Story, but not for the whole project?”
“Yes!” Herman answered.
“But I need to know the progress at the project level, not just for this
Story.” Carmen was still not convinced.
“I understand Carmen. But before you can assess progress for the
whole project you need to first understand what is the throughput of your
134 Other Slicing Heuristics
project. In other words you need to know how many of those INVEST
Stories you created last night actually get delivered in a week.”

“OK, let me see if I got this. I will work with the teams to implement
these thin slices of my INVEST Story; by the end of the week we’ll have
an idea of how many slices of an INVEST Story we can deliver.”
“Correct!” Confirmed Herman.
“And then I’ll just guess how many thin slices each of the other
INVEST Stories has? Isn’t that estimating?” Carmen asked.
“Not really, but that is something we need to cover next,” continued
Herman. “Right now the most important step for us is to get your project
to show some progress. The data we get when we show progress will
help us to predict or forecast future progress, but we will need more of
those INVEST Stories to be delivered before we can be sure we know the
actual progress rate.”
“But doesn’t that mean that – even if we deliver a few of the slices we
just created – we will not know when we will deliver the Features we
need for the first release?” Carmen was puzzled.
“The idea with #NoEstimates is that you should focus on value, and
use the available data to forecast future progress. But the first step is to
focus on value to be delivered. Once you are clear on the value you need
to deliver you should then worry about forecasting future progress. The
first question is: what is the most important piece of work we need to
deliver now? You just answered that. Let’s focus on that first and talk
again tomorrow,” Herman stated. “I have to run, meet me for breakfast
tomorrow morning, we’ll look at the rest then.”
Carmen was not happy, but she trusted Herman and was happy to
have been able to slice the INVEST Story – which seemed huge – into
smaller items that she was confident the team could deliver in a shorter
time. Her next step was to get the teams to start on the thin slices of
functionality she and Herman had just defined.
Determining Progress from Historical Data

Carmen asked some very important questions: how to assess progress
when we actually break down an INVEST Story into smaller, thinner
slices? After all they are not the same size as the original INVEST
Stories and those slices may not even be “sellable”, i.e. ready to go into
production.
The lack of historical progress information is a very common obstacle
when applying the ideas behind #NoEstimates. We don’t always have
enough historical information that we could use to model the future
progress of a particular project. The reasons are varied: we may not be
working with the same technology; we may not be working with the
same team; we may not have a stable team; we may never have used
small increments; we may have only used waterfall in the past, etc.
This is why it is important to start collecting historical information
now. Don’t wait for tomorrow, start collecting information about your
project’s progress and use that to forecast progress as soon as possible?
How soon?
As the proverb goes, “the best possible moment to plant a tree was
twenty years ago; the second best moment is now”
In my research I’ve normally used the progress data from 3 to 5
iterations (or weeks if you are using Kanban/flow based software
development) in order to define the initial progress rate. Many expect
that you need many more data points before you can make a useful
prediction, but that is not the case. Three to 5 iterations are typically
enough.40

40 Thank you to Troy Maggennis for highlighting how important it is to recognize that a
small number of data points or samples is enough for us to be able to make useful
predictions regarding future progress. For more on the problem of inferring a discrete
uniform distribution through sampling see the German Tank Problem entry in Wikipedia,
which explains that the use of sampling and statistics can improve on human estimates:
https://en.wikipedia.org/wiki/German_tank_problem
136 Determining Progress from Historical Data
In one project I took the information from the first 3 weeks (how
many RTSs were delivered to a production-like environment, also known
as the project velocity or throughput) and merely extrapolated that to the
rest of the project. The average velocity multiplied by the number of
sprints we had available in that project gave us an indication of the total
amount of RTSs that we could deliver during the full length of the
project.
Below you can see a graph detailing the number of Stories delivered
in every one of the 21 iterations for that project.

Figure 9 - Run chart of Stories delivered by one team in a long (21 iterations)
project. Notice how useless it would have been to set a target of 10 User Stories
for this team...
In this project the average velocity during the first three weeks was
enough to predict very accurately how many RTSs the team would
deliver over 21 weeks. In your project that may not be the case, so you
should constantly update your forecast based on the latest information
you have.
The graph below shows a shorter project where the first three
iterations (not weeks in this case) could not be used to reliably predict
the number of RTSs that project would deliver. However, as the project
progresses we see that the velocity stabilizes. By updating our forecast
based on the latest data available, we progressively become more
accurate in our forecasting.
Multiple Levels of Granularity

In Carmen’s project we have multiple levels of granularity. Carmen
was able to divide the project requirements into somewhat large INVEST
Stories; which we call Features because they cannot be delivered in a 2-
week or Sprint timebox. Together with Herman, Carmen was able to
further divide each Feature into smaller INVEST Stories; which we will
call Stories or User Stories. User Stories are constrained to be delivered
in a period of 2-weeks or a Sprint in Scrum.
In my practice I advise that Features be given a mandatory, maximum
calendar duration of around two months depending on project size and
calendar duration. The smaller Stories should also be given a mandatory
maximum calendar duration: I like half-day to one-day because it helps
teams find and solve execution bottlenecks on a daily basis. But your
mileage may vary. In any case, a User Story should not be allowed to
grow bigger than about half the length on your iterations (a common
iteration size is two weeks).
138 How Do I Mandate the Size of a Feature or a User Story?
By establishing these different levels of abstraction for requirements

you will be able to gather progress information at different levels. You
will be able to ask and answer the questions:
• How many User Stories can a team deliver on an average week?

(The User Story velocity).
• How many Features can our project deliver on an average week?
(The Feature velocity).
Both these metrics will help you forecast the progress for your
project. While the User Story velocity metric will help you assess when a
certain Feature might be ready; the Feature velocity will help you assess
when the project might be ready.
How Do I Mandate the Size of a Feature or a User Story?

“Work always expands to fit the available time”, states Parkison’s
Law.
Parkinson’s Law is not the only example, we have many other quotes
and phenomena that basically describe the same thing: when it comes to
knowledge work, it will always take at least as much time as you’ve
allocated it to take.
In statistical terms, if you plotted the duration of all tasks in a project
it would create a histogram similar to the one below.

What this means is that, even if you estimate, you are very likely to
get it wrong and chances are you will get it wrong by under-estimating
the work that needs to be done.41 Because we are more likely to
underestimate the duration of a task, the delays in the project continue to
accumulate even if some tasks are finished quicker than estimated.
How to avoid this phenomenon? Wrong question. We should instead
focus on defining work based on how much time we think it should take.
For example, if a project were likely to generate a maximum income of
$100,000 it would be a bad idea to spend more than that to implement it,
independently of what your estimates say.
When it comes to following progress for a project this concept is
applied by hard-limiting (time boxing) the duration of certain parts of the
work. If all Features take one month to deliver (by definition or time
box) you know that in a year you will deliver around twelve Features
(assuming you work in one Feature at a time). The project may deliver a
few less Features, or a few more Features, but close to twelve.
However, if instead you try to estimate the Features to take 1 month
you will be a victim of Parkison’s law, which dictates that each Feature
will most likely take at least 1 month to deliver.
Let’s take an example. When delivering an IT ticketing system (to
handle requests coming in from the users of the services IT provides) we
may decide to list a number of Features and then estimate their size.
Alternatively, we may decide to list Features and not worry about their
size. As long as all Features are increments of value for your customers,
what matters is that you start immediately delivering that value.
As the teams develop the Features, the Features are sliced into smaller
Stories, with each Story being in itself an increment of value.
When we get closer to the end of the mandated one-month Feature
calendar duration, our focus will turn to making the Feature under
development “sellable” (i.e. ready to be used by end-users), even if not
all the functionality could be delivered. The functionality that did not fit
the one-month mandated calendar duration for the Feature is said not to
“make the cut”.
This functionality may still be valuable or not. If the remaining
functionality is considered to be valuable it is then grouped into one or
more new Features (also with the same mandated calendar time
duration), and added back to the list of Features to be developed. If, on

41 One significant reason for this large spread for task estimation is that we tend to
estimate the actual work it takes to complete the task, but are unable to predict the time
that task spends waiting to be picked up. In Chapter 1 we cite Troy Maggennis email
where this phenomenon is further explained.
140 Why Should I Mandate the Size of a User Story or Feature?
the other hand, the remaining functionality is not considered critical, then
it should be dropped from the list of work to be completed, or at least
placed with low priority on that list.
As we add the remaining functionality back to the backlog we will see
the remaining work grow. This phenomenon is very normal and to be
expected in software projects. In fact the work to be done in a software
project will increase unless the project team makes a decision to actively
remove work from the backlog. This constant addition of work to the
backlog of a project is one of the causes for schedule overruns and even
has a pet name in the software industry: “scope creep”. Of course, that
name does not reflect the reality of software development. Adding work
to the backlog is not “scope creep”, it is just a natural outcome of our
constantly changing and improving understanding of the problems we
need to solve with the software we are creating. Instead of “scope creep”,
we should really use the term “value discovered”.
Mandating the maximum calendar duration for an item is also used
for User Stories. In my practice I advise teams to have 1-day User
Stories. The reason is simple. If you were wrong about the time it takes
to develop your User Story you will know it already tomorrow! And can
therefore act to either remove the obstacles or reduce the scope of that
User Story. Following this maximum allowed calendar duration for
Features and User Stories requires practice in slicing larger pieces of
work into small increments of value. Don’t be discouraged if at first you
don’t succeed. Rather than increase the mandated size of a Story,
practice slicing your User Stories more often, ask for help from a more
experienced colleague or ask Google. Someone out there has already
cracked that nut and can help you do it. See the resources at the end of
the book for ideas on how to improve your skills in Story slicing.
Why Should I Mandate the Size of a User Story or Feature?

There are several reasons for mandating small enough calendar
duration for User Stories and Features. The most important one in our
#NoEstimates context is that it will give you the progress information
you need to be able to forecast future progress and deliveries. See below
the Feature velocity graphs of two different teams, one that mandated the
size of Features to 1-month and the other that estimated the size of
Features instead as they were defined. You can see that the first graph
provides regular progress information and a reliable metric for you to use
in forecasting. While the second graph shows how Parkinson’s law
impacts the relative unpredictability of progress.

Figure 10 - Plotting the velocity over time for two teams. Above: throughput for
a team that explicitly limits the calendar duration of their Stories. Below: the
velocity for a team that does not limit the calendar duration of their Stories.
There is no magic here. The reason limiting work to a fixed time

works is simple: it forces you to increase the frequency at which you
collect feedback, and evaluate progress.
The moment you realize that a Feature or a User Story cannot be fully
delivered within the allotted time is the moment you get to decide
whether to accept that additional work or to discard it. That is a powerful
moment in your effort to contain the project scope and focus on the most
valuable work. Why wouldn’t you use it?
Extrapolating from User Story to Overall Project Progress

“Herman, we are close to the end of the week and I wanted to review
the progress with you before presenting it to my boss. Can you come
142 Extrapolating from User Story to Overall Project Progress
over”, Carmen asked Herman.

“Sure, let’s review what you have.”
Carmen and Herman were looking at a spreadsheet. The sheet
showed the number of User Stories that were completed per day as well
as the number of User Stories left to complete for the Feature under
active development.

Figure 11 - Accounting for the Stories delivered within one Feature during an
iteration. Notice that the Feature increases in number of Stories as time goes by,
this is a very common scenario. Work is discovered as previous work is
completed.
“Great! This is very valuable information!” Said Herman excited.

“Great? Are you serious? We were not able to finish the Feature we
started with this week. There are still 4 User Stories left even though we
completed 9 User Stories out of a Feature that was thought to have 10
User Stories!” Carmen said expressing frustration.
“Calm down Carmen. You are right, but you are not seeing what the
data is telling you.” Continued Herman trying to change the tone of the
conversation. “Look, the team was able to complete 9 User Stories this
week, that’s a rate of about 2 User Stories per day. That gives you an
indication of what is the capacity of the team at the moment. All other
things being equal you can trust that the team will continue to deliver
around 2 User Stories per day. Some days it may be zero, and other days
it may be three or four, but this is valuable information.”
“But I don’t know how much work is left. How many User Stories
does each of the Features to be developed have? I don’t know.” Carmen
was not impressed.
“That is correct, but let’s review our goals for this week. We wanted
to show progress. Here you have it! You have software you can
demonstrate to the customer and you have a pretty good understanding
of how much software you can deliver on a regular week. We have to
expect that this User Story velocity will change. If the team, the
technology or any other key factor in your project changes your velocity
will change. That’s normal. But you have a ball-park figure that helps
you forecast progress.” Herman continued, convinced of the value of the
data collected.
“But Herman, I need to show progress at the project level. All I have
now is progress at the Feature level.” Carmen pointed out.
“Correct. You can only show how long this one Feature took and is
likely to take. However that information is valuable for the project as
well. As of today you can assume that every Feature in the backlog will
take between one and two weeks to deliver.”
“No I can’t!” Carmen interrupted. “We’ve worked only on one
Feature, which is not even completed.”
“Sure, but you can speculate based on that observation. Right? I
mean when you look at the backlog, do you think this was the lowest
effort Feature you have in the backlog?” Herman asked.
“No, this is by far not the smallest Feature.”
“Is it the highest effort Feature you have in the backlog?” Continued
Herman.
“No, this is quite large, but not the largest.”
“There you go! Now you can speculate that this Feature is
somewhere in the middle, which gives you a good range for all the other
Features. Let’s assume, for the sake of argument, that this Feature is
about average in effort. Now you define an interval for the other
Features. Let’s say Features will take anywhere between one week and
three weeks to deliver. Take those numbers and multiply them by the
number of Features you have in the backlog, what do you get?” Herman
waited for Carmen’s answer.
144 Extrapolating from User Story to Overall Project Progress
“Well, making those assumptions I could say that the Features we

have left will take anywhere between one year to deliver to four years –
which is unacceptable!”
“Wait!” Herman interrupted, “you are going too fast. Even in the
case of one year being too much you have not yet applied the most
important tool you have as a Project Manager.”
“What’s that?” Carmen was puzzled.
“Scope Management!” Herman waited for her reaction

“Are you joking? How can Scope Management help me when even
the lowest end of the interval is too much?” Carmen was not impressed.
“Good point. But you are talking about Feature progress
information. Don’t forget that each Feature itself can have its scope
managed, so that even if you can’t remove some of the Features in the
backlog you can manage what each Feature will include in order to meet
your target schedule,” Herman continued.
“Oh, I see! What you are saying is that I should forecast progress
based on the data at different levels of granularity. At User Story level so
that I can manage the scope for a Feature and at the Feature level for
the project…” – Carmen explained.
“Yes! Now you are getting the hang of it.” Herman continued, “the
idea is that you have to collect the information you need to make
significant project decisions, and as you know, scope management in a

project is one of the few things the project team really has power over;
especially if the team can forecast progress during the early days of the
project. After all, the customers are never happy to drop Features or
even Story-level functionality at the end of the project, but I’m sure they
will consider your suggestions if you bring them early enough in the
project.”
“Yes, of course. Now I understand what you mean by ‘showing
progress’. You actually meant that we have to show enough to help us
forecast future progress against today’s backlog so that we can see if we
are over the schedule at all times!” Carmen looked happy.
Herman continued, “yes! And now you can bring actionable
information to your boss when you review the progress of this week! The
first question you should ask yourself now is how many Features you
would need to cut out of the backlog to be reasonably sure, according to
your forecast, that you can deliver the first release on time.”
“Great! Thank you Herman, now I need to go prepare the
presentation.” Carmen left the room with decisive speed.
Here some of the key takeaways from Carmen’s story so far:
• Use multiple levels of granularity to establish flexible

requirements.
• Use historical data to assess progress and forecast future
delivery.
• Cost is a multiplier of time (mostly); the only real variable the
project team can control actively is value (in the form of scope).
1-2-3: Step by Step Towards #NoEstimates

As with any important change in the way you work, bear in mind that
moving directly from a traditional estimation-based-plan environment to
full #NoEstimates approach will be risky most of the time, and perhaps
not advisable. This is the second reason we considered the idea of giving
you a step-by-step guide. So please, keep in mind that the list below
includes some specific steps you can follow in order to explore how
many estimates you really need in order to plan and manage your
projects.
1. Move to Story Points. Even if this is just another way of
estimating, getting rid of ‘hours’ and ‘days’ has too many benefits to
ignore them. We already discussed previously in this book the
problems of using time-based metrics, which are an indication of
146 1-2-3: Step by Step Towards #NoEstimates
cost, to measure project progress. Even if it’s just another proxy

metric for productivity, Story Point-based estimation gives a better
understanding of how things like risk, complexity, expected
dependencies for each Story, etc. Given that a large amount of time
it takes to deliver one Story is spent waiting, Story Point estimation
is more likely to help you assess the true impact of one Story in your
project.
2. Stop estimating tasks. One of the saddest thing we witness in
planning meetings is a team casting an estimate for a Story, dividing
this Story into tasks and then casting estimates for each task, adding
them all and seeing if the number matches the original estimate for
the whole Story. Instead of that, just don’t create sub-Story tasks or,
if these are valuable for team synchronization – knowing who needs
to be doing what – just stop estimating them. For progress reporting,
just ask the team about the Story progress – did we progress well
yesterday? Can we complete the Story today?
3. Limit the calendar duration of Features and Stories. For Stories,
specifically you should aim for one, maybe two days of calendar
duration to finish each Story. Even if this is not easy when you try
for the first time, this approach will give you concrete benefits. For
example: any Story started at the beginning of an iteration that was
not finished by the end of the iteration is showing an organizational
impediment that you should investigate further.
4. If you are already using Story Points, remove some ‘planning
poker’ card options. Start by asking team members to rate
everything either as a 1, a 3 or an 8. This means that anything bigger
than a 1 is a 3 – this avoids the “is it a 2 or a 3 point Story?”
discussions – and anything bigger than a 3 is an 8. Anything bigger
than an 8 should be sliced. Slowly decrease the options. For
example, use only 1 and 3, and soon you will be able to ask a simple
question: “can we get this Story done by tomorrow if we start
working on it today?”
5. Build histograms. Keep track of your average duration for Stories
and Features. Simply record the day the team starts to work on each
Story or Feature and the day that Feature or Story is complete. This
information can later be used for progress forecasting.
6. Use the average cycle times for Stories of different size to start
producing Story-based forecasts. Count how many Stories go into
every sprint and make a histogram-based forecast of how long will
it take. Use it also to forecast small projects (one to three months)
that can be sliced into small-medium-big Stories. If you can prove
these numbers to be at least as reliable as the estimations you gave,
you’ll have the case for #NoEstimates right in front of you!

7. Finally, work with Stories as if they all had the same duration.
Simply count Stories and project progress based on how many
Stories the project was able to deliver in the past: average Stories
delivered per iteration or per week.
Try each of these steps in your own project. Some steps will be easier,
but when you find a step that is hard to implement ask “why?” In some
cases the requirements will be the impediment – maybe they are still
horizontal requirements? In other cases the hard part is to learn to slice
the Stories. In fact, slicing Stories is probably the most effective tool to
manage scope, and very few projects are using this approach effectively
today. I call this the “lost art of Agile Software Development”.
But the next question is: even if you can slice the Features and Stories
into smaller work items, that you can deliver regularly into a production-
like environment, how can you use that information in a project
negotiation? Carmen’s next challenge is just that: how to use the
actionable information she collected to negotiate the project delivery
with the customer. Let’s see how she does that in the next chapter.

CHAPTER 6
THE FIRST STEP TO DELIVER A PROJECT

ON TIME IS TO RECOGNIZE THAT WE ARE
LATE
Carmen, I’m impressed with what you were able to do during this week.
Your presentation of the project’s progress was very clear, and is just
what we need to make good decisions.” Carmen’s boss smiled.
“Thank you! I think I’m starting to get the hang of these
#NoEstimates ideas, that Herman has been talking about, and I really
think it will help…”
“What?!?!” Interrupted her boss. “That’s not acceptable! You can’t
be talking about that to the client! They will think we are not following
the process and may sue us!” Her boss was not amused.
“But, that’s the truth. It is thanks to Herman’s ideas that I was able to
finally get a grip on the real progress of the project. Without his help and
his support we would still be in the same situation as we were last week.
Why can’t we say this to the customer?” Carmen was not happy with the
need to hide #NoEstimates from the customer.
“Carmen, I’m sure you mean well. And I’m sure that whatever ideas
Herman has told you they have only helped you realize that you needed
to work harder. This #NoEstimates is simply not credible! Why do you
think I transferred Herman out of my team? We can’t run the risk of him
talking to a customer about his ideas, we’d lose all credibility we have in
the market!”
150
The first step to deliver a project on time is to recognize that we are late
151

“I see…” Carmen’s mind was racing, she was at the same time
disappointed and angry with her boss for not listening and dismissing the
ideas that she had been learning about. Maybe this disappointment was
due to her own incredulity before she went through the process of losing
faith, and then regaining it again by looking at the actual data that she
had been able to collect in the last week.
“Look, you’ve done a great job this last week.” Her boss continued,
“don’t spoil it by scaring the customer with immature and irresponsible
ideas. I’ve been in this industry for many years and have seen many
successful projects. I know estimation is a key practice in any project. All
the indicators of project failure point to bad management, not the
estimation process as the root cause for failure. Keep your game
together and work hard, I have faith in you.”
At that moment, Carmen would realize later, a bit of her died. She
stopped respecting the knowledge she knew her boss had. She had found
a different way to look at project management, and specifically at
assessing progress over time. And she was not about to throw that away
just to please her boss. She knew now that Herman was right, and she
was about to prove her boss wrong. But before that she would need to
improve her diplomatic skills to counter her boss’ unwillingness to
deviate from the old process.
Client meeting day had arrived. It was show time!
152 1-2-3: Step by Step Towards #NoEstimates
The meeting started with Carmen giving her overview of progress as

she had prepared the day before. She did not mention #NoEstimates even
once, but gave a clear indication that the project would very likely be
late.
Carmen showed a graph illustrating progress with a burn down chart
that only mentioned “Work to be done” and “Months”, as had been
agreed with her boss the graph did not mention Features or User Stories.

Figure 12 - Carmen's projection for Big Fish project. The optimistic and
pessimistic projections.
“The most optimistic expectation right now is that the project would,
with the current scope, be finished in 16 months or around 12 months
from now.” Carmen explained, “as you can see in this forecasted line of
progress.”
“Carmen,” the client interrupted, “what is that other line that ends 4
years from now? What is that referring to?”
“Great question, and well spotted. That other line is the worst-case
scenario. Given what we know now about the progress in the project, it
could take up to 4 years to deliver the functionality that we have in the
plans today,” Carmen added.
“Joseph,” said the client, turning Carmen’s boss, “I believe we had
an agreement on the live date for the project, didn’t we?”
“Yes, we did Mr. McNeal. And I assure you we still have that
153
agreement. What Carmen is showing is important information. As we are

at this early stage in the project it is important to have a discussion
about what is possible, and that is what we are trying to do here.”
Carmen’s boss tried to help Carmen save face.
“Indeed, Sir.” Carmen concurred, “there are certain measures we
can take to try to increase the probability of delivering within the
original date, but we will have to do some work to analyze and decide
which requirements we will either remove or delay”
“I don’t like the idea of removing requirements as this is pretty much
the minimum set of requirements that we need in order to have a
successful launch. Especially since the elections are shortly after this
system is scheduled to go live. I’ll have Travis contact you about the
work he has done. But for now I want to have a closer look at progress.
Please send us updates every week,” finished Mr. McNeal.
“But, Mr. McNeal. There is so much work to do, preparing reports
for your review every week will hinder our ability to manage the project
at the best of our ability,” Carmen’s boss added.
“OK, let’s make it every two weeks then. By the way, I liked the
software demo you did today, let’s have one of those every month.”
“Certainly, Mr. McNeal!” Carmen’s boss added with a forced smile.
How to Recover from a Late Project?

154 How to Recover from a Late Project?
Carmen was happy the client had taken the bad news without much
anger, but she now had a challenge. How to recover from the delay in the
project? In the best case the project would be done 12 months from that
meeting, which is 2 months late. However, the most likely scenario is
somewhere between 12 months and 4 years.
This situation is by no means uncommon42. Many projects face this
situation late in the planned schedule. What Carmen was able to do with
the help of #NoEstimates was to create the conditions to have the scope
discussion with the customer quite early in the project. One of the key
ideas with #NoEstimates is to focus the conversation on the value of the
work to be done. By forecasting and showing progress (or the lack
thereof) very early on, Carmen is bringing the scope discussion to the
first few days of the project. This is the time when customers are willing
to compromise, and when the technology is still flexible enough to be
able to manage the scope effectively (very few dependencies are created,
unlike at the end of a project where removing some functionality may be
harder than adding it in the first place).
The key for Carmen now is to find out how to implement an effective
scope management strategy.
Carmen knew she had to start reducing the scope of the project if she
was going to deliver that project on time. Now was time for action. She
felt confident that she would be able to reduce the scope of the project
after talking to Travis the Business Analyst, so she rang him up and set a
meeting for the next day.
The next day, the meeting started with the bad news.
“Travis, I need to reduce the project scope massively. We have a very
low chance of getting this project done with the current backlog size.”
Carmen stated.
“OK, I can see that.” Travis concurred while looking at the progress
burndown that Carmen had shown him just a moment ago.
If I understand this graph correctly we need to remove at least the
equivalent of 2 months of work given the best estimate, right?”
“Actually Travis, this is not an estimate. It is a forecast,” Carmen
corrected.
“What’s the difference? If it gives me a delivery date it is an
estimate.”

42 Research into the ”on time” delivery of software projects shows that a large % of
projects are delivered after the agreed delivery date. For more data see Chapter 1 of this
book.
155
“There is a big difference which we can’t go into right now,” Carmen

stopped short of mentioning #NoEstimates. “But for now I can say that
this is a forecast based on actual data, not estimations made by the
team.”
“Oh, you mean this is like that Earned Value Management graph but
upside down?” Asked Travis referring to the fact that the progress lines
were pointing downwards.
“No, this is not the Earned Value curve. It is concrete, validated
progress data, but never mind. The important thing is that the data we
have tells us that we will need to remove between 50% to 80% of the
existing set of functionality.”
Travis looked at Carmen and said: “Are you trying to get me fired?”
“Look, Travis. I know this is a lot, but if you really want to have this
project live 10 months from now we need to scale down the
expectations.”
“Carmen, I may be able to negotiate the scope down a bit. But never
50% let alone 80%.”
“You do realize that we are fighting a losing war trying to get all of
this scope delivered, right?” Carmen interrupted.
“Sure, but that is your problem. You’ve committed to this bid, now
you need to figure out how to pull it off. From the list you have there I
may be able to remove 5-10 Features, if that is what you call those, but
not more!” Travis continued.
“OK, please work with your management team to remove as many as
possible and get back to me later this week. I’ll see what I can do on my
side.”
“OK, will do. Talk soon,” – said Travis as he exited the room.
Carmen lost the optimism she had found in the meeting with Mr.
McNeal the day before. The full implications of the project being late
were just now hitting her. She felt as if she could do nothing to improve
the situation. It was time to get back to Herman. Maybe he had some
ideas.
As she walked to Herman’s office, Carmen remembered the
conversation with her boss about #NoEstimates and decided to meet
Herman outside the office. The last thing she wanted now was for her
boss to think that she was still using #NoEstimates methods and tools.
Carmen picked up her phone and dialed Herman’s cellphone.
“Herman, hi! Carmen here. Can we meet outside the office today for
a discussion on #NoEstimates?”
“Sure Carmen! I’m going to a #NoEstimates meetup later today.
Would you like to join?”
156 How to Recover from a Late Project?
“Sounds like a plan,” Carmen replied, “when and where?”

“Downtown, at the Ritz at 7:30pm. Let’s meet just before the meetup,
there’s one person I want you to meet.”
“Oh, great. See you then Herman.”
Later that day, at the Ritz…
“Carmen, over here!” Herman shouted.
“Hi! I was looking for you.” Carmen was happy to be out of the
office, and to be able to again talk freely about what was worrying her.
“Carmen, I want you to meet Julia Matthews.” Herman introduced
the speaker for the event. “Julia has a long experience in project
management and is one of the very few experienced #NoEstimates
practitioners. I briefed her on your project and she be may be able to
help you.”
After the introductions, the conversation started with a quick
overview of the project and the conversation that Carmen had earlier
that day with Travis, the Business Analyst.
“So, I understand that I need to reduce the scope of the project to be
able to meet the committed release dated. But I don’t see how I can do it
when the business analyst himself tells me that he may be able to reduce
only 5 to 10 Features from the backlog.” Carmen reported.
“Carmen,” Julia started. “First of all, let me tell you that you have
come a long way. By having transformed the requirements into RTS’s
you have created visibility into your progress that is uncommon in most
software projects today. Congratulations for your work, you have the key
tools you need to manage your project successfully. That list of Features
and User Stories gives you a concrete list of valuable items that your
customer wants, and you have a concrete way to measure progress
against that list. Many projects are still measuring progress against a
plan. You’ve started measuring progress against concrete, expected
value.”
“Thank you, Mrs. Matthews.”
“You can call me Julia, Carmen.”
“Thank you Julia. But I need to be able to reduce the scope of the
project, and now I’m puzzled. Travis can’t see how to achieve the
necessary reduction in scope.”
“That is very normal, even predictable,” Julia interrupted. “People
are used to think about project scope as a list of dependent items,
requirements. Usually even a layered architecture is used, and the
requirements scattered in those layers. It is very hard to imagine a
project where all the requirements would be independent from each
other when you are used to this layered approach, where requirements
build on each other, and are therefore dependent on each other. It is
157
therefore hard to understand that when you have a list of Independent

items, like User Stories and Features as you defined already, reducing
scope is not only possible, but can be achieved in several ways. For
example: you have the possibility of reducing Features as you asked
Travis to help you with. But you also have the possibility of reducing the
scope for each Feature separately. I call that Flexible Requirements
Management43. I use the prefix “Flexible” because it is not about
managing one list of functionality, but rather a matrix. Let me draw this
for you to try and make it clear.”
Flexible Requirements Management for Maximum Scope

Visibility
We often think of the scope for a project as an inflexible – or at best
slightly negotiable – list of requirements or functionality. However,
projects have a tendency to grow in scope precisely because that list is
very flexible. The scope creep phenomenon is only one example of that
flexibility. Requirements are added to the list because, when looking at
the details, we find:
• Cases we didn’t think about.

• New possible situations in which the existing requirement could
be used.
• Performance aspects we had not considered.
• Requirements that have a direct impact on how other
requirements can be implemented, and therefore expand the
scope for those other requirements.
The list goes on. As we know more about the project, the users, the
technology, etc., we will find information that we could not have
considered when the project started. That information will need to be
reflected in the work to be done, the requirements list, in the form of
additions to that list.

43 Flexible Requirements Management is inspired by a technique that Jeff Patton
popularized, called Story Mapping. Story Mapping is used at the start of a project to
envision the product as a whole and decide what should be released in each of the product
releases. Flexible Requirements Management is the application of the story map concept
to the day-to-day scope management of a project. For more on Story Mapping:
http://jpattonassociates.com/the-new-backlog/
158 Flexible Requirements Management for Maximum Scope Visibility
What I propose is a similar approach to the management of Features

and User Stories, but with the opposite goal. I propose that, as we know
more about the project, a Feature or a User Story, we question the need
for that work, and if possible remove that work.
When we understand more about the project or the problem we are
trying to solve we can question if certain Features are needed. For
example, when implementing an IT ticketing system we may have a
Feature that calls for the users to log-in and manage their list of open
tickets so that they can review what IT has done for them. Alternatively
we can have the list of the last 10 tickets in each email that we send to
the users of the system, therefore removing the need to have the user-
facing web-site. By removing the web-site page for the “open tickets”
Feature we will no longer have to implement other Features, such as user
creation, user authentication, password renewal, etc.
Here’s a way to visualize the project in its different dimensions:

Carmen needs to start considering all the possible dimensions of
scope before she is able to realize that, even fixed scope projects, can
have a lot of flexibility in the list of requirements, if that list is expressed
as a two dimensional matrix of Features and User Stories.
“As you describe the scope of your project in the form of a matrix,
instead of a list you are able to see possible options for reducing scope
much more clearly than if you only consider the list of Features.” Julia
continued.
159
“Oh, I see. You mean that instead of reducing scope by removing

Features, I can also reduce scope by reducing the User Stories
associated with each Feature.”
“Correct.” Julia responded.
“OK, but I don’t have that list of User Stories, so I can’t do that at
the moment. And it would take a great deal of work to go and list all the
User Stories for each Feature,” Carmen was still not convinced.
“Don’t worry about the User Stories for now. Your first step should
be to look at the list of Features and find Features that you can remove
from the project. Once you’ve done that you review the list again to
check if, by having removed those Features, there are some Features that
are no longer needed. For example, if you remove a Feature that uses a
particular database, you may not need to support that database anymore,
which would probably remove related work in other Features or even
some Features related to administrating that database.”
“Oh, I see. You mean that I should first try to list and remove the
Features that require a large amount of work or possibly impact
indirectly other Features if they are implemented.”
“Correct,” responded Julia.
“OK, I get that. But, even if I do remove several Features the fact is
that I would need to reduce 50% to 80% of the Features. The client is
certainly not going to agree to that,” Carmen worried.
“When we start discussing scope reduction we never have an easy
conversation ahead of us. However, because you started very early, the
client will be able to make decisions that may have a significant impact
on the list of Features. You have to continue that discussion and find the
right Features to remove. It will not be easy, but the alternative is certain
failure. And no one, not even the client, wants that.” Julia assured
Carmen. “You’ve taken the hardest step in any project. You’ve started
the conversation with your customer. Now it is time to continue that
conversation.”
“OK, I’ll have to give it a try. But even if I remove some Features
from the list, I will not have enough to complete the project on time,”
Carmen expressed her concern.
“That is a possibility, but before you get to that point give the
Features a good scrubbing. You may be surprised with what you find.
And when you find that Features alone will not be able to impact enough
your project then it is time to take the scope scrubbing to the detailed
User Story level,” Julia commented.
“Apologies. I need to interrupt you. Julia, the session is about to
start,” said Herman as he signaled Julia to enter the room.
“Julia, can I contact you later?”

“Sure, it would be a pleasure to help you Carmen. Good luck and talk
soon.” Julia headed towards the room where the evening’s presentation
was about to start.
Carmen was still not comfortable with the situation, but at least she
knew what to do next. She would have a discussion with Travis the next
day and use what she had just learned to remove, not only the Features
Travis had been able to remove, but also Features that may have been
there to support the Features that could be removed. Carmen was sure
that it would not be enough, but she had to give it a try. She might be
surprised, as Julia pointed out.
The next day at the office Herman tried to meet Carmen several times
but was unable to find her. She was not in her room, did not go to lunch
to the usual place. It was as if she had disappeared.
“Carmen, what’s up? I’ve been the whole day trying to find you to
discuss what you heard from Julia yesterday. Are you busy?” Herman
asked, surprised to find her in the corridor.
“I am busy, but I’d also like to review with you what I learned
yesterday, but we can’t do it here in the office. Let’s meet later. I’ll
explain why we can’t discuss here.” Carmen added while looking to see
that her boss was not around.
“I’ll meet Travis from the Big Fish client today. How about meeting
near their office at 5pm?”
“OK, meet you there. But tell me, why is this secrecy about us
meeting necessary?”
Carmen felt ashamed as she confessed “Well, my boss told me about
his history with you, and how he thinks that the #NoEstimates ideas are
crazy and that I should not mention #NoEstimates to the customer.”
“Ah! Ah! Well, he is right about one thing: you should not mention it
to your customer. It is our responsibility as professional and competent
Project Managers to deliver the projects on time and under budget.
#NoEstimates is our secret weapon to achieve that goal. They will be
happy when you provide transparency they’ve never seen, and the
project on time and under-budget. Don’t worry about the label. Just be
transparent and accountable to your client. I have a feeling your boss
won’t mind you surpassing your client’s expectations!” Herman winked,
and turned away.
“He is right!” Carmen realized. “I will focus on delivering this
project on time and providing more transparency and accountability to
the client, and I even know how to do that now!”
Carmen drove up to Travis’ office to discuss the project.
“Travis, hi! Thank you for meeting me on such short notice. As you
161
know we have our next progress review with Mr. McNeal in 2 weeks. I
need to show an updated progress report based on what we discuss
today,” Carmen started.
“Sure. I know that. I did some work since we spoke yesterday. Here’s
a list of the 5 Features we can remove from the scope of the project. I
tried, and tried to get a commitment to more Features, but that was not
possible. This is the best I could do since yesterday. We may be able to
remove 1 or 2 more over the next weeks, but for now this is the best we
can do.” Travis announced while passing a paper to Carmen with the
list.
“Thank you Travis. I can work with this. I’ll have to review the
implications of removing these Features on the remaining list of
Features. Can I come back to you later with questions about these?”
“Sure, let me know if I can help you in any way. But as I said, these
are the Features we can remove now.”
“Thank you. Talk later,” said Carmen as she exited the room. She felt
a bit more confidence in the process since she had that conversation with
Julia, but she was not yet fully comfortable with the situation. She knew
those Features would not be enough to bring the project end-date back to
the original 12-month time frame. And now she was responsible for the
delivery, as her boss had clearly reminded her. The stakes were high.
She needed to act.
The meeting with Herman later that day started with a charged
atmosphere.
“I just can’t see how I will be able to pull it off, Herman.”
“Don’t worry about the project release for now. Let’s work with what
we have right now. We have a concrete scope reduction of 5 Features.
Where does that leave us in terms of release date?” Herman tried to
cheer Carmen and focus her on the information she already had at her
disposal. “Let’s review your release forecast, do you have that?”
“Yes, here it is,” Carmen pulled out the graph. “The previous
forecast as well as the one I created earlier today, that already accounts
for the Features we’ve just removed.”

Figure 13 - Current forecast (overlaid on the original forecast), already taking
into account the Features removed by Travis
“Great. Do you see any Features in the backlog that would be

unnecessary now that you’ve removed those other five Features?” Asked
Herman.
“Hmmm, hard to say at this point. I supposed I could bring this back
to our team and collect a few more ideas on what Features we could
remove.” Carmen was unsure that this was the right course of action, but
she wanted to sound more positive.
“Then do that. You may find some Features that can be removed now
that were not possible to remove before. Then there’s the next level, we
have to analyze the next level.” Herman added cryptically.
“What do you mean by next level?”
“What I mean is: at first you can manage the scope by removing
Features. Once you are done with removing Features there’s still a lot of
scope that can be removed when you look at the stories under those
Features. There are many ways in which a Feature can be delivered. The
stories under a Feature represent one way to do it, but you can find other
163
ways by thinking about the functionality from your ideal customer44

perspective,” Herman explained.
“What do you mean by ideal customer? Is that a new concept?”
Carmen asked, puzzled.
“No, it is not a new concept, but it links back to the vision of your
product. A product exists to serve several types of customers, but it
always has a specific customer type without which the product would not
even exist. That is your ideal customer. When you think about the
product from your ideal customer’s perspective, you will have a clearer
focus and will be able to decide what is indeed needed, and what could
be removed because the ideal customer can use the product without that
particular functionality.” Herman looked at Carmen waiting for
confirmation that she had understood.
“OK, let me see if I understood this right. What you are saying is that
in a particular Feature there are stories that include functionality that
the ideal customer needs, and other functionality that the ideal customer
either does not need or can live without, right?”
“Right,” Herman smiled, “this is what we call flexible requirements
management. We have different levels of abstraction at which we can
manage the scope of the project. Typically projects tend to balloon in
scope, because we discover functionality at lower levels of abstraction
that we consider ‘important’, and just add to the backlog. However, we
can use the same approach to remove items from the backlog. Think of it
like negative scope creep.”
“I see… That’s a good insight. But won’t that require a lot of work?”
“Yes, and constantly. But when your other option is to miss the
delivery date, I’m sure you can see why it is worth it,” Herman
commented.
Carmen sighed and looked at Herman.
“That means one more long night for me…” Carmen said.
They parted and Carmen went to work on the backlog to find the
stories that could be removed from the ideal customer’s point of view.

44 In this context ideal customer is a term used to designate the target customer of the
product or service being developed. This should be as specific as possible, and not
generic terms like consumer or business owner. Examples: a consumer that has purchased
from our shop before; a small family restaurant owner.
164 Creating Options by Slicing Features
Creating Options by Slicing Features

Each Feature (or story) in a product backlog contains many
undiscovered options. By taking Features as they are without slicing
them into thin slices of functionality we implicitly commit to an
implementation strategy.
However, when we slice Features we create options that allow us to
pro-actively manage the scope of a project.
Let’s return to the IT Support Ticketing System project we discussed
before. A Feature like the one below will not allow us to manage the
scope actively.
• As an employee, I want to be able to submit issues to IT, so that I

can fix a particular problem that prevents me from working.
The Feature above is what I would call a “binary” Feature. Either the
employee is able to submit an issue to IT or not. This simple Feature can
have large implications in terms of the amount of work required to
implement it. Specifically the chosen “input” solution (how the issue
tickets are submitted) can make the difference between a simple and very
complex and long-winded implementation.
Taking the Feature above and breaking it down into several smaller
Features or stories will allow us to make decisions regarding the
implementation order, or delaying certain parts of the implementation.
Let’s look at an example:
• As an employee I want to be able to submit an IT issue to the IT

department so that I can have a fix for a problem that prevents
me from working
• As an IT helpdesk employee, I want to have a queue of issues to
handle, so that I know what items I should be working on at any
given time.
By slicing the original Feature in this particular way we unpacked the

functionality under the term “submit issues” in the original Feature into
two different Features: send submission (replaces simple submit above)
and Queue of issues (replaces the receiving end of the submission
process).
We’ve potentially reduced the scope of the initial Feature (for
example no need to have a system to enter IT tickets, just use email as
the submission tool), and we’ve given ourselves the option to implement
a solution based on standard tools. The two Features we created allow for
165
a solution based on email and a spreadsheet program with shared editing.

For example, we could use Google Docs to manage this queue and get
started today!
These two stories could still be implemented with a full-fledged IT
issue tracking system, but that is an option and not a mandatory outcome
of the initial Feature.
Slicing Features into separate functional parts helps us actively
manage the scope by creating different implementation options 45that are
often implicit and non-negotiable when we have larger Features in the
backlog.
How to Communicate Progress?

Carmen had worked hard all night, but the picture had not changed.
Carmen was able to remove one more Feature, and split another 12
Features in search of ways to reduce the scope.
Carmen began: “Herman, thanks for taking my call this early. I was
up all night. I was able to find one more Feature to remove, and split
another 12 Features, but now my list of Features - even with the five I
removed this week - is up to 93. It is as if this exercise created even more
work instead of reducing it.”
“This is part of the process,” said Herman trying to reassure
Carmen. “When you split the Features it is natural that the number of
Features grows. But that does not mean that you increased the amount of
work. It only means that you’ve found work in the list of Features that
was already there, but you were not aware of before. This exercise has
helped you better understand the backlog. That’s why it feels
overwhelming.”
“Sure, I understand that, but I need to start removing Features and I
don’t see where to start. There’s just too many Features for me to review
and classify.” Carmen doubted the process.
“You’ve only completed the first part of the work. The next step is to
review the new Features with your team. They’ll have ideas on how to
further slice those Features and suggestions as to how many of those you
could avoid with different implementation strategies,” Herman
continued.

45 For more on options thinking, and the work that inspired this
approach I recommend the work by Chris Matts and Olav Maassen and
their book: Commitment http://commitment-thebook.com/
166 How to Communicate Progress?
“I know this is asking a lot, Herman. But can you help me out with
hosting a meeting to do just that? I’m tired and don’t feel confident
enough to help the team see through these Features.”
“Sure Carmen, let’s meet at the office.”
“Hmmm, it is better if we meet in the meeting room floor to avoid
indiscrete looks. I’ll take the team there. Talk soon!” – Carmen hung up
and felt a bit better after having obtained Herman’s cooperation. She
was not yet completely sure that his ideas would work. But now she was
committed to trying his ideas in practice. She felt the alternative of going
back to her old approach to project management was no longer an
option.
It is only when we start to actively manage the options we have

(slicing the work into INVEST stories) that we truly gain control of the
work we must complete. Finding the next most important story to
develop is the core of my #NoEstimates approach. Slicing the stories and
prioritizing them regularly is the process. But there is more to that. How
do we communicate the progress to the customer, especially in critical
projects? How can we help customers make decisions regarding which
work to keep and which work to delay or drop? That’s the next step for
Carmen. The pressure is increasing and the stakes are high.

167

CHAPTER 7
GAIN THE CUSTOMERS TRUST WITH

ROLLING WAVE FORECASTING
Carmen was re-arranging her papers repeatedly as she waited for the
team to come to the meeting room. She had prepared the room for the
workshop with flipcharts on the wall, the list of Features on one side and
the slices of those Features underneath. She wanted to know if her effort
to slice the Features was understood and accepted by the team. When
everybody was in, she started the meeting.
“Thank you all for coming at such short notice. As you know we have
a very challenging project ahead of us. I’ve been focusing on how we
could keep this project on track both from the scope and time
perspective, but also so that we don’t have to work over-time for the next
9 and a half months. No one would like that, least of all me.” She felt her
team’s attention and a huge responsibility at the same time. “I reviewed
the backlog in the last few days, and as you know, concluded that we
can’t possibly make the release date in 9 and a half months with the
current amount of work. We have two options, increase our throughput
of Features per iteration, or we can remove content from the backlog.”
“Increase the throughput? Are you serious Carmen? I’ve been
working over-time for a week to get some progress visible to the
customer in our next progress report. I can’t possibly work any harder,”
Albert was not amused.
“I understand Albert, and I thank you for your efforts. Without your
and everybody else’s extra contribution we probably would be in big
trouble right now. I understand that. That’s why I wanted to focus this
meeting on creating options for us. I would like to review the backlog
with you and list possible Features we could drop based on what was
dropped already, and slice the remaining Features to see if we can find
functionality that we don’t need to deliver for the first release. I’m not
asking for miracles here. I know what can be done. Now I’d like to focus
on what we can avoid doing, in order to meet our deadline.”
After the introduction, several groups were formed. One of the groups
reviewed the Feature slices that Carmen had created the night before,
and the other groups focused on trying to unpack the remaining Features
into slices that could be prioritized for later or dropped altogether. It
Gain the customers trust with rolling wave forecasting 169
was an intense workshop. The atmosphere was charged. People asked

themselves if there was a practical, and realistic solution to the
conundrum they were in.
“Thank you all for your help with this process,” said Carmen as she
prepared to close the workshop. “We have learned a lot about the
project in this workshop and, not surprisingly, we were able to remove
some work that was ‘hiding’ inside the big monolithic Features that we
had in the backlog. Although we are no better than we were a week ago
(we now have 73 Features in the backlog, compared to 64 a week ago)
the fact is that we have a good idea of what we can remove further from
the backlog and may have impacted our throughput by reducing the
scope of the current Feature set. This last comment needs to be validated
in the following weeks, but now I have a good idea of what I can suggest
to the client can be removed further. Thank you all.”
Carmen was happy with the outcome of the workshop, but she knew
there was a long and hard road ahead to convince the client about what
could still be removed and to show concrete, and constant progress. The
first progress review was only one week away. Now it was time to let the
team focus on the work they had at hand and prepare the meeting with
the client.
The Never-Ending Pool of Ideas

What Carmen and her team just went through is very common in
software projects. Once we start looking into the details of a set of
requirements (Features or user stories) we always find details we had not
thought about. This is normal, and expected in every software project,
especially in those where planning starts at the top and only slowly
trickles down to the team level.
In software and hardware (aka embedded software) projects it is also
natural that we discover certain quirks in how the hardware works only
when the software system has grown enough to uncover those
unexpected behaviors. That phenomenon leads to more work needing to
be done on the software side for the simple reason that hardware is much
harder to change.
Scope creep is the natural state of software projects, it feels like the
pool of ideas grows with every day that passes, and the work to be done
grows with it. That is why when we apply #NoEstimates we focus on
managing the scope from day zero. In order to successfully manage
scope from day one, we need to have a tool that shows progress visually
every day, or at least every week. We can’t wait for a specific milestone
later in the project to find out how much work we need to either remove
or delay. In software projects, the work to be done grows every day, and
170 Reporting Progress with NoEstimates
our ability to see that growth also needs to be ensured every day.
A common approach to creating that visibility is to use the technique
Carmen used: slice your Features and user stories so that you can review
progress on a daily or at least weekly basis. In practice this means that
every week several stories should be completed to allow you to assess
progress. And every few weeks (every month or so) several Features
should be completed.
You should involve the whole development team in the slicing of
Features because they will have insights into the components of the work
that can be made independent, and how to validate each slice separately.
Validating each slice from the value and quality perspective is essential
for us to assess progress. Work waiting to be validated from value and
quality perspective is for software development what inventory is for
manufacturing: a liability. You will have to pay dearly for that work later
on, unless you validate that work immediately.
How do you visualize progress when you don’t even know all the
possible dependencies that will emerge later on? That’s a question that is
addressed by the progress reporting solution described here.
Reporting Progress with NoEstimates

The meeting with the client, Mr. McNeal, was about to start.
Expectations were high. The day before Carmen and her boss had a
heated debate about how to present the progress of the team so far.
Carmen’s boss was of the opinion that they should report progress based
on the initial count of Features, before the “scope creep” that Carmen
had uncovered. Carmen was adamant; she wanted to show the situation
as she saw it. The tension was high.
Carmen was prepared. She started: “Mr. McNeal, unfortunately, and
although we had good progress since our last meeting two weeks ago, we
can’t say that we are closer to the original estimate now than we were
then.”
“Can you explain what you mean Carmen?” Mr. McNeal did not
sound as angry as Carmen had expected after her conversation with her
boss.
“Sure. In the last progress review we reported that we had started,
but not finalized the highest priority Feature.”
“Remind me again Carmen, what is a Feature. Is that what you call
requirements these days?” Mr. McNeal interrupted.
“No sir. A Feature is something you can show to the users of the
system and they understand it from the point of view of their use of the
system. Unlike a requirement, a Feature is a self-contained, testable
piece of functionality that can be delivered independently from the other
Features in our list,” Carmen explained.

“Oh, I see. That means I could actually deliver some Features to
production before we have all the Features completed?”
“Yes, sir. That is the idea. To be able to deliver each Feature
independently to production and validate that it fulfills the needs for use.
Once the Feature is tested and the users give feedback, we consider the
Feature validated,” Carmen continued.
“But wait, you could deliver this feature to production within 3
months, couldn't you?” – asked Mr. McNeal with a sudden interest.
Carmen was surprised by that comment and thought: “Does this
mean that Mr. McNeal is interested in delivering early? He never
expressed so much interest in the content of the project during our
previous meetings”.
“Correct!” Confirmed Carmen, trying hard not to give a hint of her
surprise.
“You are saying that you could – if I asked you – deliver to
production before the final release date, right?”
“Correct. However, I must also say that it requires some readiness on
your side to be able to do that. We can test that the functionality works as
expected, but your team will need to confirm that it is the necessary
functionality or deliver back to us the list of changes for that Feature.”
Carmen was unsure if she was speaking too fast. She was excited about
the idea of incremental deliveries. Would Mr. McNeal buy that idea?
“Sure, sure. Of course they can do that. Show me the list of Features
please. I want to check something.”
“Here you go, sir.” Carmen said as she handed over the list of
Features that had been created after her workshop with the team.
Mr. McNeal started to look attentively through the list. He seemed to
be reading each Feature. Once in a while he stopped and asked a few
questions about one Feature and said “OK, that’s not the one”.
Everybody was puzzled. First it was a surprise that Mr. McNeal, who
usually did not interact much with the development team was paying so
much attention to a simple list of Features. Second, nobody expected that
he would read the whole list of Features in a progress meeting.
Everybody expected him to be tough and demanding, and requiring over-
time to be paid by the vendor to meet a deadline that had been agreed in
the bidding stages of the project.
The next ten minutes felt like an eternity. But finally Mr. McNeal
raised his eyes from the list, looked at Carmen and asked: “When is this
Feature going to be delivered?”
Carmen looked at the Feature that Mr. McNeal was pointing to and
said: “I can’t be sure Mr. McNeal. With the current rate of progress it is
unlikely that we will have that Feature ready in the next two weeks, but I
can get back to you with an estimation later today or tomorrow if you
like.”
“I would really like to know when this Feature will be ready, so
please hurry up your estimation meetings and let me know by the end of
today when you will be able to deliver that Feature.” Mr. McNeal was
back to his demanding self.
“We will try.” Carmen’s boss interjected with a smile.
“Try as you may, I want to have an answer today. Now, if you will
excuse me I have to run. Carmen, great work on the use of Features, this
is the first time I see any project using this approach, and I must say I
like it. Now please let me know when that Feature will be delivered.” Mr.
McNeal thanked all in the room and left.
It was as if a huge pressure cooker had just been opened. The room
suddenly felt serene and calm again. The fear was gone, and Carmen
knew what to do next.
A few hours later in a restaurant nearby, Herman and Carmen were
debating heatedly about how to solve the problem of answering Mr.
McNeal’s question: when will this particular Feature be delivered?
“But Herman, we really need to estimate every Feature in the
backlog. Mr. McNeal wants to know when this Feature will be delivered,
but next week he will ask about another Feature. If I don’t have a Gantt46
chart with the Features and assignments I will not know when the
Feature is ready,” Carmen insisted.
“Carmen, let’s look at the data you have. You have been able to
deliver 2 Features to your validation environment in 3 weeks. This
Feature that Mr. McNeal wants is currently the tenth Feature from the
top, this isn’t that hard. If you complete between 0,6 and 1 Feature per
week on average, it will take 10 to 16 weeks to deliver that Feature. It is
that simple. Trust the data.” Herman tried to convince Carmen.
“Sure, but that is a rate. Not a specific work sequence. I can’t be sure
that this Feature is number 10 in the list if the earlier Features can grow
or shrink between now and when we start that Feature.”
“Correct, but you will have a good indication of the delivery window.
You will also know when the window for delivery changes, and you can
react to that! Be it with reprioritization or removing content from
Features that are earlier in the list,” Herman continued.
“But what if we make a commitment to Mr. McNeal and we are late?

46 http://en.wikipedia.org/wiki/Gantt_chart A commonly used graphical representation of
work and dependencies between different work packages in a project.
He seems to be very interested in that functionality. Maybe we should

move it up on the list?” Carmen was unsure
“Whether you need to move it up the list or not you will know as soon
as you report the rolling wave forecast with the window for that
Feature.” Herman commented.
“Rolling what? What did you say?” Carmen asked.
“I said that Mr. McNeal will let you know if you need to reprioritize
your list of Features once you tell him when the Feature is forecasted to
be ready.”
“No, what did you say about rolling wave forecast?” Carmen
insisted.
“I said that when you present the rolling wave forecast to Mr.
McNeal he will let you know if he is happy with the delivery window for
that Feature.”
“What do you mean by delivery window?”
“OK, I’ll backtrack bit. First, you should have a rolling wave forecast
for your project. Say you have windows of two weeks (because that is
your iteration length) and total project duration of 12 months. You
should show your project as a sliding window over the 12-month
timeline. Like if you were projecting two weeks in detail and have a
rough indication of the rest of the work that is possible in 12 months.”
“But the project is not 12 months now. It was only at the start, we
only have 9,5 months now.” Carmen was confused.
“Sure, you can also have a total timeline of 9,5 months, but if you do,
you will not show clearly what does not fit anymore in the project. Let
me draw you an example.” - Herman picked up a piece of paper and
started drawing.

“See this window here?” Herman asked pointing to the grey
rectangle in the drawing he was creating. “This is the work that is likely
to be delivered in the next two weeks, the rest is shown in priority order.
And the work that goes beyond the planned release date for the project is
then highlighted in red, to show that it is likely it will not be completed
within that time frame.”
“OK, I got it. So I show a window of two weeks to list the Features
that are likely to be delivered in the next two weeks. But the Feature Mr.
McNeal was interested in will not be ready in two weeks. How do I show
that to him? Should I have multiple two week windows on the graph?”
Carmen asked.
“You could, but you could also have bigger windows. For example,
you could have a two week window in green to show that it has a higher
certainty, then a 1 month window in yellow, to show less certainty and
finally a grey 3 month window. That way you give Mr. McNeal an
indication of what Features will be delivered in different timeframes.”
Herman paused, and then continued. “Of course, this is just me
speculating. Maybe Mr. McNeal is interested in different time windows
of 3 and 6 months. You should ask.”
“OK, I got it. I have to go now and send that email to Mr. McNeal.
Thank you again Herman for your help. I was about to call an overnight
meeting with the team to build a Gantt chart with tasks, dependencies
and resource balancing. But what you say makes sense and is completely
in line with the way we are reporting progress right now. I have to try
that. I will let you know how Mr. McNeal reacts. Wish me luck!” Carmen
said as she was leaving.
“Let me know what he says!” – Herman said while waving goodbye.
The rolling wave forecast that Carmen will prepare will give her
client:
• Clear and verifiable progress information.

• Actionable information.
The same information that helps a project team make decisions, will
also help the customer prioritize and decide on the scope of the project.
The rolling wave forecast further helps you see what is possible to
deliver in multiple time frames. Given that each Feature will have a
different cost-of-delay47, this information is critical to decide which
Features to keep in the backlog and which to delay or remove.
Rolling Wave Forecasting Allows You to Adapt Your Plans,

Constantly
Carmen needed to present a possible date of delivery to Mr. McNeal,
and she was planning to obtain that date, the same way she had always
done it. Through a detailed plan (Gantt chart) where she could review
assumptions, planning details such as dependencies, risks, etc. But was
that what Mr. McNeal wanted?
By creating a detailed plan, Carmen was about to commit the work of
the team for the next few weeks. Once that commitment was made (and
the implicit promise to Mr. McNeal), the team would no longer have the
option to adapt to new information. All the assumptions, sequence of
work, dependency handling, risks and errors would be locked in. She
would have removed all flexibility from her project.

47 http://en.wikipedia.org/wiki/Cost_of_delay Note that cost of delay is a rough measure
of how much value is lost by delaying the delivery of some functionality. Each type of
work will have a different cost of delay curve. For example a software program needed
for the Football World Cup will have a very steep cost of delay curve around the day that
software needs to go into use because the Football World Cup will start at the right time,
even if the software is not ready. Other type of software will have a different cost of
delay curve.
176 Rolling Wave Forecasting Allows You to Adapt Your Plans, Constantly
In the past, Carmen would have added buffers; created contingency

plans and worked hard at managing expectations. But all that is
unnecessary when we, instead of giving a commitment, give a forecast.
At the heart of the rolling wave forecast is the acceptance of uncertainty.
This, in turn, allows us to keep our options open. To be flexible and able
to respond to change – just like the Agile Manifesto says.
In a rolling wave forecast we create scenarios about the future. We
speculate about how the events will unfold and reflect those analyses on
a forecast that shows a range of possible outcomes. In this particular
case, Carmen will assume that the throughput of the project will be
within a range and therefore will give not one number, but an interval in
time in which the Feature that Mr. McNeal wants is likely to be
delivered. From this information Mr. McNeal can then:
• Accept the forecast and follow-up the delivery by getting an

updated forecast.
• Refuse the forecast and ask for changes in prioritization of work
so that the Feature he wants can be delivered earlier.
Independently of what decision Mr. McNeal will make, the cost to

produce the forecast is very low, and the information it provides will be
enough for him to make a decision. Following the decision, Carmen will
be able to adapt the plan by re-arranging the order of implementation of
the Features (they are independent) to meet the need or expectation from
the client.
If Mr. McNeal decides that a certain Feature should be delivered
earlier than the forecast suggests, adapting the plan to that decision is a
simple process of moving the Feature up in the priority order. The team
is then notified and work continues. Contrast this with a Gantt chart. A
detailed, and linear planning tool like a Gantt chart requires you to
update the order of work for a detailed plan, and that typically involves
sequencing, detailing, designing the work and then assigning it.
Your goal should be to make changes to the plans easier. Why? The
simpler the planning process, the faster and more easily your projects
will be able to accommodate the inevitable changes.
A key Feature of choosing a low overhead, yet accurate, forecasting
mechanism for your project is that you can update the plan at all times.
In the case of the Big Fish project, and thanks to the measure of
throughput that Carmen uses to forecast the project, she can update the
project progress information (rolling wave forecast) every week, because
every week she has new information that she can add to the report. In
turn, this provides actionable information for the project leadership to

make concrete decisions about what Features or stories to move higher or
lower in the priority order.
This forecasting mechanism allows the project team to know when
they are likely to deliver a certain Feature and therefore also coordinate
work with external project contributors. This is necessary when the
project team depends on external teams. For example: the project team
may need to coordinate their work with a marketing team that
implements the marketing campaign, or a field testing team that works
with final users to collect feedback for a large rollout, etc.
Finally, the rolling wave forecast also provides us with a varying
scale of precision whereby the forecast is relatively more precise in the
short term, and loses precision as we look into the future. Giving a
measure of certainty that is different for different time scales. This is
achieved by picturing the forecast for different values of the progress
metric. Carmen uses her throughput range to give a widening range of
outcomes over time as seen below.

178 Presenting The Rolling Wave Forecast to a Client
Presenting The Rolling Wave Forecast to a Client

Carmen was nervous to read Mr. McNeal’s answer to her email. She
had delivered the forecast she had created with Herman based on the
throughput of the team. She remembered the trembling fingers with
which she wrote “10 to 16 weeks from now”.
The day started with a short conversation with her boss. Carmen was
surprised by how silent and absent he had seemed, but now her mind was
on her e-mail client. She opened the program, typed her password and
waited anxiously until the emails were downloaded. Usually this
happened in a few seconds, but today she felt the process took ages. She
tried to guess Mr. McNeal's answer. Will he be furious? Angry? Get her
fired?
Carmen opened the email message of Mr. McNeal. It read:
“Subject: RE: forecast for project

Big Fish
Dear Carmen,
Thank you for the information you

sent me yesterday. It was most
useful. Thanks to your detailed
forecast and report on the
possible outcomes for the next few
weeks in the project I have been
able to reprioritize the Feature
we discussed yesterday.
Please call my secretary and

arrange a meeting for today. I’d
like to discuss the project’s next
steps with you.
Regards.”
Carmen was at first happy. After all there was no anger in the email.
However, the last phrase made her very anxious. Why was Mr. McNeal
asking for a meeting now? What was going on?
She called Mr. McNeal’s secretary and scheduled a meeting for later
that day.
As she entered Mr. McNeal’s office she felt her legs shake. She had a
gut feeling that this was an important meeting. She sat down in the
meeting room and waited for Mr. McNeal as she was instructed.
She waited for a few minutes, which felt like an eternity. She tried
drinking a glass of water, but her hand would not accept the order the
brain had sent. Carmen decided that she was too nervous to drink water
and sat on her hands to keep them from shaking.
A few minutes later, Mr. McNeal entered the room. But he was not
alone.
“Hi Carmen, thank you for coming here on such short notice.” Mr.
McNeal said.
“Hello, sir. I understand. What is the matter…” Carmen stopped as
she saw the person entering the room behind Mr. McNeal was her boss.
He seemed serious. “Hello sir, I did not expect to see you here,” Carmen
said while looking at her boss.
“I wanted to have both of you here for this meeting,“ Mr. McNeal
explained. “The reason is simple. I’ve made the decision that from now
on the Big Fish project will be handled internally in my department.”
Fear struck Carmen. Her fear of being fired was coming true. She
thought: “My god! They are kicking us out of the project. Will my boss
fire me now? Oh no...”
“I want to keep a close watch on this project,” Mr. McNeal
continued, “it is a very important project for me and for the Prime
Minister. We can’t accept anything less than an on-time, high quality
release. As you know this system is scheduled to go live just before the
election. Any failure to deliver this project can cost us the election and
we would not want that.”
“I guess our company is out of the project, then.” Carmen was sure
that this was the golden handshake moment.
“I want to guarantee that this project is a success and that is why I’ve
asked your company and Joseph here to move you and your team to our
premises here, in our building. Effective Monday you will work here and
report directly to me.” Mr. McNeal announced. “I’m very impressed
with the clarity and transparency in this project, and I’m aware that you,
Carmen, created that. You have been able to deliver more visibility and
clarity regarding this project in 2 months than any of our other projects
ever delivered. I’m impressed and I want you to help me bring that same
kind of transparency to other projects here. Joseph has graciously
agreed to let you and your team work directly with us here at our offices
until further notice.”
After a pause, Carmen said: “I don’t know what to say sir. I’m glad
that you are happy with the progress the team has shown, but the
180 Presenting The Rolling Wave Forecast to a Client
visibility was created thanks to a colleague of ours that has been helping
me and without whom I would not have been able to create this level of
transparency.”
“Bring him with you as well! We start on Monday! This is the most
important project you will ever work on. I want the best people in
charge.”
“But Mr. McNeal,” Carmen’s boss tried to interrupt.
“No buts Joseph, bring that fellow with Carmen and the team.” Mr.
McNeal was not taking no for an answer.
“Very well,” Carmen’s boss acquiesced. “We will bring Herman in
as well.”
Carmen was smiling inside. Her hands did not shake anymore and
she felt confident.
“And Carmen,” Mr. McNeal continued. “Next week we have a
presentation about this project to the council of ministers. Let’s get ready
for that. You are in the big leagues now.”
THE END

We hope you enjoyed the #NoEstimates book. Join the conversation on

twitter under the #NoEstimates hashtag.
This book is part of a larger project that includes video interviews with
some of the early adopters of the ideas described in this book.
Sign-up at www.NoEstimatesBook.com/print_gift to get an exclusive
essay on Capacity Planning with #NoEstimates.
Visit
to find the following extra material:
Two mini e-books on contracts and planning

ü The Ultimate Guide to Capacity Planning with NoEstimates by
Tomas Rybing
ü How Much Does it Cost?: A Guide to Agile Contracts by Evan
Leybourn
The #NoEstimates Pioneers on Video:

ü Woody Zuill, the creator of the #NoEstimates hash tag on twitter
ü Neil Killick, the creator of the Slicing Heuristic, a great way to
reach #NoEstimates quickly
ü Henri Karhatsu, greatly experienced #NoEstimates practitioner
with many stories to share
Four video interviews with #NoEstimates practitioners

ü Chris Chapman, inventor of the #NoEstimates game
ü Clinton Keith, game developer using #NoEstimates in his
projects
ü Marcus Hammarberg, author of Kanban in Action
ü Allan Kelly, author and #NoProjects movement founder
Two interviews with CEO’s applying #NoEstimates

ü Sven Ditz, CEO of Sitegeist.de in Germany
ü Diego Cenzano, CEO of biko2 in Spain
Visit
to know more
183

ACKNOWLEDGEMENTS
A project like this is never easy, and could not succeed without help and
support from many people. So here is my heart-felt thank you to all,
including those I have unintentionally left out in this acknowledgement.
You made this project possible!
To my family, who was so patient with me through the process

of writing this book.
A special thanks to my partners at Oikosofy who’ve helped and

supported me through the difficult process that is writing a book,
especially a controversial one as this.
Luis Gonçalves, aka the web-master, who helped me create the web-site
and product pages for this book and all the additional material that is
available with the book.
Sven Schnee, who helped the #NoEstimates movement progress with his
blog post on the topic.
Veronika Gonçalves, who helped me get the first book page up and
running and was patient with me when I could not answer her questions
because I was immersed in the writing of this book.
Fernando our investor who made Oikosofy possible!
Woody Zuill, a dear friend whom I met in Skype first, and then later in
several conferences. We organized workshops together and brought
attention on twitter to a very important topic in our industry.
Ángel Medinilla, the amazing illustrator for this book and the person
who helped me get started with the book.
Neil Killick, Henri Karhatsu, Chris Chapman, Sven Ditz, Diego
Cenzano, Clinton Keith, Markus Hammarberg, a big, big thank you
for being available and willing to contribute to this project with
incredibly insightful video interviews that bring the whole idea of
#NoEstimates to life from so many points of views.
Tomas Rybing and Evan Leybourn, a very special thank you for the
insightful essays that are now part of this project and will help countless
people take these ideas into practices.
All Beta Readers that invested their time and attention in making this
Acknowledgements 185
project much better with their questions, insights and comments. This
book would be much worse without your contribution.
To the twitter friends I made during these years where #NoEstimates
went from a crazy idea, to a wide-spread cry of dissatisfaction with the
status quo in the software industry. You make me believe we can
improve our industry!
185

ABOUT THE AUTHOR
Vasco wants to transform product development organizations into product

business organizations. He does that by focusing the work of the product
development teams on the end-to-end life-cycle of their products. From
Concept to Cash and Back!
Currently a Managing Partner at Oikosofy, Product Manager, Scrum
Master, Project Manager, Director, Agile Coach are only some of the roles
that I've taken in software development organizations. Having worked in
the software industry since 1997, and Agile practitioner since 2004. I
Vasco was one of the leaders and catalysts of Agile methods and Agile
culture adoption at Avira, Nokia and F-Secure and other companies where
he consults teams and management.
Vasco is also the host of one of the most popular Scrum podcasts at:
http://scrum-master-toolbox.com/ Follow that podcast for interviews with
Scrum Masters from all over the world.
You can read more at: http://softwaredevelopmenttoday.com/
You can join Vasco on twitter: @duarte_vasco

NoEstimates - Quick Access PDF Version - Check Membership Site For All Files and An Extra Video Keynote

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NoEstimates - Quick Access PDF Version - Check Membership Site For All Files and An Extra Video Keynote

Uploaded by

Copyright:

Available Formats

DO YOU WANT TO DELIVER ALL YOUR

With the #NoEstimates practices we focus on understanding

Schedule your call at the following link:

Two mini e-books on contracts and planning

The #NoEstimates Pioneers on Video:

Four video interviews with #NoEstimates practitioners

Two interviews with CEO’s applying #NoEstimates

"Anyone interested in deliver their projects on time should read this

THE PROBLEM WITH ESTIMATES ....................................................... 27

WHAT ARE ESTIMATES? ..................................................................... 48

RETHINKING ESTIMATES .................................................................... 75

GAIN THE CUSTOMERS TRUST WITH ROLLING WAVE FORECASTING 168

ACKNOWLEDGEMENTS .................................................................... 184

"Transformation comes more from pursuing profound questions than

I’m pretty good at getting comfortable in my ways. Perhaps we all are.

THE #NOESTIMATES PREMISE

THE PROBLEM WITH ESTIMATES

“Actually, it is a public sector project, so I guess you could say that

This picture looks grim. If Carmen works for an “average” company

Figure 3 Percentage delay to estimates at approval, and estimates at

Why Don’t Estimates Work?

Douglas Hofstadter observed that, no matter how much work went

Parkinson observed that bureaucracies seemed to expand and

• Essential complication or g(e): How hard a problem is on its

• Accidental complication or h(a): The complication that creeps

cost of feature = f(g(e), h(a))

In software, estimates of cost are often done by analogy. If features A

As Troy Magennis 7shared with me in an email conversation:

When we ask someone to estimate how long it will take to

Systems thinkers like Goldratt, Reinertsen, and Deming

The delays involved in a complex system are unknowable in

The only way to estimate and forecasting a system is by

What Troy refers to is a critical insight: work flows through a system.

More Than Meets the Eye: Why Estimates Are Actively

9 For details on the Enron scandal, visit http://en.wikipedia.org/wiki/Enron_scandal

Entangled: How Complexity Destroys Predictability

11 For more details on the Apple Goto Fail details, visit:

destroyed all the hard work to keep their product safe.

• Thank you Andres Lundsgård for the following quotes.

Change Requests, Change Everything

All or Nothing: Death March Projects

Is There Hope for Software Projects?

WHAT ARE ESTIMATES?

It might seem like an obvious question. Everyone involved in some

producing or asking for estimates.

Another important fact to understand about estimates is that, once you

you will tend to be more conservative. On the other hand, if winning a

20 Cone of Uncertainty by Barry Boehm, as described by Laurent Bossavit in

possible, as much inventory as possible. You want the bare minimum,

Estimating vs. Forecasting

• The properties of an electrical system, which are determined by

our productivity and many factors affect us.

The Iron Triangle

A discussion on the topic of estimation is incomplete without some

uncertainty on the project, and expand as necessary.

160 minutes, or 23 200 pages lost every day!

The Start of a Project Is the Worst Time to Estimate Its

• Can one developer estimate a project that other developers will

resources and time. How do I do that? – In estimating we have

Uncertainty and Buffers

Every project has some uncertainty in it. In some domains, this

• Time Buffers: once we estimate a deadline, we add some more

Equally important to buffer definition is to decide how to manage that