1  

2  

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

“Trying to be more predictable by working with estimates is a seductively simple idea. After decades of
widespread use of this idea, actual results are now very clear. Estimation has instead caused reduced
predictability, lowered quality and unhappy customers. Read this book to start exploring some more
successful strategies!” – Henrik Berglund, Agile Organizational Coach, Cedur AB

"A must read for all of us that has discovered that it's in the doing of the work that we discover the work
that we must do." – Anders Lundsgård, Senior Engineer and Solution Architect, Sweden
   
 3  

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

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?"  
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.    
 5  

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.  
Along  the  way  it  became  apparent  to  me  that  some  of  the  decisions  we  depend  on  for  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.    
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/  
 
 
   
 6  

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  de  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  golden  question  from  themselves.  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  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  
 7  

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  other  are  nowadays  with  the  #NoEstimates  question.  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,  not  few  voices  rose  against  such  concepts  stigmatizing  them  as  
‘delusional’  and  ‘misleading’.  Even  the  ideas  behind  the  manifesto,  which  are  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  very  frequent  nowadays  to  
hear  from  teams  that  moved  from  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.  The  audience  was  
crowded  by  several  well-­known  European  Agilists,  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  
 8  

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  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.  Rainserger  concept  of  
#MehEstimates,  like  in  “Oh,  estimates…  Meh!...  Yeah,  I  guess  we’re  doing  some,  we  are  just  
not  very  concerned  nor  serious  about  them.”    
So,  here’s  to  life,  the  #NoEstimates  book.  Enjoy.    
Ángel  Medinilla  
Agile  Coach,  #NoEstimates  practitioner,  Book  illustrator  
http://www.proyectalis.com/  
 9  

 
CHAPTER  1  

THE  PROBLEM  WITH  ESTIMATES  

C
armen 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, and he closed the door before he even said good morning to her.
Carmen appreciates her boss, because she has learned a lot from him. But right now she is 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…”
 10  

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 to the project.

“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. But this time it’s with a very more important client.”

“How much bigger project 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?”
 11  

Still no comment. “Ten times bigger?”

“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 that project.

“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,  which  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:  

                                                                                                     
1
 Steve  McConnell,  Software  Estimation:  Demystifying  the  Black  Art  
 12  

 
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  

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  have  such  tasks.    

…Bad  news…  

                                                                                                     
2
 CHAOS  report  for  2011-­2012  shows  42%  successful  agile  projects.  
 13  

 
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.  

Look  at  the  project  on  the  top-­left  of  this  chart.  This  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,  but  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.    

                                                                                                     
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/  
 14  

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.  

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  I  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  
 15  

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.    

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  
                                                                                                     
4
 Gödel,  Escher,  Bach:  An  Eternal  Golden  Braid.  20th  anniversary  ed.,  1999,  p.  152.  ISBN  0-­465-­02656-­
7.  
5
 O'Sullivan,  John  (June  2008).  "Margaret  Thatcher:  A  Legacy  of  Freedom".  Imprimis  (Hillsdale  College)  
37  (6):  6.  
 16  

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

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

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;;  
                                                                                                     
6
 Watch  the  full  video  here  (duration  ~8  min):  http://vimeo.com/79106557.  
7
 Troy  Magennis  writes  about  software  projects  in  his  blog:  http://focusedobjective.com/news/  
 17  

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”  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  and  Your  Company  
“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 setup me up?” Carmen’s thoughts quickly spiraled
in her mind, but she decided to keep them quiet for now, and answered: “of course!”
 18  

 
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?  

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  

                                                                                                     
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  
 19  

“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  advises  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  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  

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

cause  a  catastrophic  failure.  Take  Apple’s  famous  “goto  fail”  debacle11,  where  one  simple  line  of  
code  completely  destroyed  all  the  hard  work  to  keep  their  product  safe.    

No  matter  how  strong  the  foundations  of  Apple’s  products  are,  this  single  line  addition  to  the  
code  was  enough  to  completely  destroy  their  foundations  and  security  credentials.  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  

Langdon’s  Lemma:    

Software  evolves  more  rapidly  as  it  approaches  chaotic  regions.  

Medinilla’s  Law  for  Software  Contracts:    

                                                                                                     
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  
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  
 21  

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  

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.  

 
 22  

 
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  the  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  same  question.  The  bottom  line  is  that  estimation  is  a  very  poor  method  to  
predict  the  future,  and  change  requests  only  amplify  that  problem.  
 23  

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  either  you  
find  more  water;;  you  reach  your  destination;;  or  you  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/  
 24  

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.  

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

                                                                                                     
16
 The  myth  of  Sisyphus:  http://en.wikipedia.org/wiki/Sisyphus  
 25  

CHAPTER  2  

WHAT  ARE  ESTIMATES?  

“T
he 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,  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.
 26  

 
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.  

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

 
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  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  
 28  

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,   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!  

                                                                                                     
18
 Editor’s  note:  Please  notice  the  difference  used  here  between  forecast  and  estimate.  This  
difference  is  further  discussed  later  in  the  book.
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.  
 29  

#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  possible,  as  much  inventory  
 30  

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

•   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.  
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).  
 32  

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:  

•   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.  
 33  

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

 
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  
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  
 35  

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

                                                                                                     
21
 Mean  Time  Between  Failure,  Wikipedia:  
http://en.wikipedia.org/wiki/Mean_time_between_failures  
 36  

“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,  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  
 37  

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

                                                                                                     
22
 See  Critical  Chain  by  Goldratt,  more  information  at:  
http://www.goldratt.co.uk/resources/critical_chain/  
 38  

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
 39  

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

                                                                                                     
23
 A  Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK  Guide)  Third  Edition  
 40  

 
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.”
 41  

“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, 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.  
 42  

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

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

                                                                                                     
24
 Pivot  is  a  structured  course  correction  designed  to  test  a  new  fundamental  hypothesis  about  the  
product,  business  model,  and  engine  of  growth.    
 44  

CHAPTER  3  

RETHINKING  ESTIMATES  

The  (Alleged)  Need  for  Estimates:  Deadlines,  Costs  

and  Scope  

C
armen 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.
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.  
 45  

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

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

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  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...”
 47  

“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.”
“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…
 48  

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  
 49  

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

 
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  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  
 51  

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

                                                                                                     
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  
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  
 52  

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  old30,  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?  

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.  

                                                                                                     
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  
 53  

 
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  
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  
                                                                                                     
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  
 54  

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  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  
 55  

why  methods  such  as  Scrum  advocate  the  cross-­functional  team  as  the  unit  of  productive  work  
in  software  development  organizations.  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.

•   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).

                                                                                                     
32
 A  special  thank  you  to  Maikel  Vandorpe  for  the  explanation  regarding  dependency  on  the  
team  composition.    
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.  
 56  

•   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  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.  
 57  

   
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.  
But  that  is  not  the  only  way  of  doing  things,  nor  the  most  advisable  in  many  situations.  
 58  

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  Gedankenexperiment.  Ángel  Medinilla,  this  
book’s  fantastic  illustrator,  calls  this  the  ‘Perfect  Product  Owner’  Gedanken.  
 59  

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.  

 
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  
 60  

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

CHAPTER  4  

HOW  NOESTIMATES  CAN  HELP  YOU  

MANAGE  A  PROJECT  IN  CRISIS  

“T  
he  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.”  
 62  

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  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?
“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!”

                                                                                                     
35
 Thank  you  to  Troy  Maggennis  for  helping  me  correct  the  conclusion  in  this  paragraph.  
 63  

 
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.    

 
 64  

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?  
 

 
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  
 65  

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!  
“Working  software  is  the  primary  measure  of  progress”  
-­  From  the  Agile  Manifesto  
 66  

Following  this  principle  from  the  Agile  Manifesto  requires  us  to  write  requirements  in  a  way  that  
allows  you  to  do  two  very  important  things:  
1.   Requirements  need  to  be  written  in  a  way  that  allows  you  to  measure  progress  early  and  
often  during  the  project.  
2.   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:  
1.   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.    
 67  

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

 
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  
 68  

(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  

                                                                                                     
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  
 
 69  

Even  if  the  Stories  take  longer  to  implement  than  one  day,  they  should  follow  some  
#NoEstimates  slicing  principles:  

•   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.  
 70  

 
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  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  
                                                                                                     
37
 The  INVEST  mnemonic  is  credited  to  Bill  Wake  and  his  article  INVEST  in  Good  Stories,  and  
SMART  Tasks  
 71  

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

“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:
 73  

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

                                                                                                     
38
 More  on  Earned  Value  Managment:  https://en.wikipedia.org/wiki/Earned_value_management  
 74  

“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.
 75  

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

CHAPTER  5  

THE  FAST  TRACK  TO  NOESTIMATES  

“Y
ou’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)?  
 77  

 
“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:
 78  

“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:  
1.   What  are  your  intermediary  deliveries  going  to  be  used  for?    
2.   When  does  the  project  need  to  go  live  with  the  first  release?    
3.   What  does  the  customer  expect  to  accomplish  with  that  first  release?  
4.   How   many,   and   which,   Running   Tested   Stories   (RTS)   do   you   need   to   deliver   until   that   first  
release?  
5.   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:  
1.   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.    
2.   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.    
3.   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  
 79  

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

“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  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:  
 81  

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

 
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  
a.   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  
b.   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  
                                                                                                     
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.  
 83  

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:  
a.   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.  
b.   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.  
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  
a.   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.  
b.   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  
 84  

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.    
“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.  
 85  

 
 
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 project. In other words you need to know how many of those
INVEST Stories you created last night actually get delivered in a week.”
 86  

“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.
 87  

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

                                                                                                     
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  
 88  

 
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.    

 
 89  

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).    
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.    
 90  

 
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.  

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

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

 
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 over”, Carmen asked Herman.
 93  

“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.”
 94  

“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.
“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
 95  

 
“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
 96  

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:  
1.   Use  multiple  levels  of  granularity  to  establish  flexible  requirements.  
2.   Use  historical  data  to  assess  progress  and  forecast  future  delivery.  
3.   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  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?”  
 97  

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

CHAPTER  6  

THE  FIRST  STEP  TO  DELIVER  A  

PROJECT  ON  TIME  IS  TO  RECOGNIZE  
THAT  WE  ARE  LATE  

“C
armen, 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!”
 99  

“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!
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.
 100  

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

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

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  

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

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.”
“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.
 103  

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?”
“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 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
 104  

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

                                                                                                     
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/  
 105  

 
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.
“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.
 106  

“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.
 107  

“Travis, hi! Thank you for meeting me on such short notice. As you 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.”
 108  

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

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.

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

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

                                                                                                     
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/  
 111  

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

CHAPTER  7  

GAIN  THE  CUSTOMERS  TRUST  WITH  

ROLLING  WAVE  FORECASTING  

C
armen 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 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.”
 113  

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

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?”
 115  

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? 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
                                                                                                     
46
 http://en.wikipedia.org/wiki/Gantt_chart  A  commonly  used  graphical  representation  of  work  
and  dependencies  between  different  work  packages  in  a  project.  
 116  

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

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

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

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.”
 120  

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

“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  
   
 122  

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  Leibourn,  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  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!  
 123  

   
 124  

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  
 125  

More of What Others are Saying about NoEstimates, The Book

"This is a must read book to software managers. It is call to responsability to managers to not estimate
but give actual data to clients. Following the #noestimates principle will make the life of people around
software industry happier." – Enric Jaen

"The debate surrounding the need, or not, to provide detailed estimates to clients is one that courts
contention, argument and confusion. Undoubtedly these emotions will continue to prevail, but Vasco
Duarte clearly and concisely reveals the virtues of an alternative approach to estimation." – Andy
Deighton. Scrum Master

“You may not be able to implement all aspects of the #NoEstimates approach but you will be able to take
away insights that improve your current estimation approach, reduce waste and provide more valuable
information to your stakeholders.” – Paul Seaman, Principal QA, SS&C Technologies

“Many businesses perform estimations as a matter of routine. But this can be a time consuming activity,
and doesn't always have a good return on investment. So it is wise to also consider the alternatives. This is
the book to present that for you.” – Kevin O'Shaughnessy, senior web developer, and blogger at
zombiecodekill.com

“#NoEstimates is not just about estimates. It is an important step in the paradigm shift from a plan-driven
to an empirical approach to software development.” – Georg Raeder, Lean Facilitator, EVRY, Norway.

“#NoEstimates has been an interesting, if not divisive topic on Twitter. The “NoEstimates” movement
aims to explore questions around the usefulness and applicability of estimation in software, in particular
in an Agile context. #NoEstimates tries to challenge unexamined assumptions around a widely used
practice in the software development business.” – Oluf Nissen, Scrum Master, HP

“This book makes you wonder why you are still believing that an estimate is a fact instead of what really
is: an opinion.” – Ernesto Cárdenas Cangahuala, DevOps & Cloud Consultan
“Vasco's NoEstimates book makes a clear, thoughtful case for planning and delivery based on a sane and
realistic view of software development instead of the traditional wishful thinking based methods.” –
Derek Graham, Principal Developer

“To question something that most people in our industry see as a necessity takes courage. The ideas
presented in this book will hopefully give you the inspiration and courage to change our industry for the
better. Nothing less.” – Jess Bring-Larsen, Senior Systems Engineer, Systematic

“Stop wasting time in long discussions about how many days it’s going to take and start generating value
for stakeholders using #NoEstimates, have your team love the method and your customers enjoying the
delivery. Read this book full of great illustrations.” – Christian Delez, Agile project leader & cloud
architect.

“#NoEstimates explores some major deficiencies of estimates and a simple but effective alternative approach for
managing expectations and building trust is introduced, taking into account the complex nature of software
development. If you're struggling to accurately estimate your projects and keep your promises to customer, this book
is for you!” – Yavor Nikolov, Software Developer & Agillist from Sofia, Bulgaria
 126  

“I wanted to rethink how we estimated projects at work, and #NoEstimates provided a well thought out
alternative to death-by-hours that we did. You owe it to yourself to check it out.” – Carl Anderson,
Application Developer, USA

“I had the pleasure to be one of the beta readers for Vasco's new book on NoEstimates. I had decided I
would read it with an open mind and anxiously awaited to read the first chapter. I have to confess I was
hooked. This stuff was real, I could relate to the story about Carmen and the book hit so many
dysfunctions I have experienced in the past. My understanding and my stand on #NoEstimates has
changed; I am starting to get it. This book will be on top of my recommenced reading list going forward.”
– Mikko Sorvari, Sr. Agile Consultant, USA

“Excellent read, well articulated and clear. For the first time I can see how we might move closer to
achieving #noestimates at a digital agency. This book places value and quality at the heart of everything.”
– Matt Thornhill, Senior Digital PM

“#NoEstimates book is precious reading for all those professionals interested in delivering real value to
their customers rather than trying to predict the inevitable 'unknown unknows' in every software project.
Put in other words, #NoEstimates is all about getting things done.” – Alessandro Ronchi, Owner at
Webgriffe

“#NoEstimates is a must have book for anyone interested in improving their delivery of value to
customers using Agile practices. With a focus on priority, predictability and collaboration it fits any agile
approach.” – Jon Eversett, Scrum Master / Agile Coach at Landmark Information Group

“#NoEstimates began as a simple hashtag on twitter. It has generated hundreds of passionate discussions.
The #NoEstimates book is a major contribution to the debate: the Pros and Cons will get a very clear
overview of #NoEstimates in action.” – Nicolas Umiastowski, Agile Coach and Consultant, France