NoEstimates: How To Measure Project Progress Without Estimating [1 ed.]

Citation preview

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.    Troy  Magennis  writes  about  software  projects  in  his  blog:  http://focusedobjective.com/news/  

7

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  [email protected]   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.”

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

21

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.  

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

22

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.  

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

23

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

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

35

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:  

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

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

45

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