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

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

 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.  

what did you say about rolling wave forecast

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.  

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.

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  to

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.

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

“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

Early  in  each  project,  your  top  priority  is  not  to  ship  something  meaningful  to  your  customer,  but  to  obtain  information  on  capacity,  throughput,  and  bac

Even  if  each  Story  may  not  be  “sellable”,  it  must  be  testable  and  final,  i.e.  the  team  can  make  sure  that  aparticular  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.

Each  Story  can  be  dropped  from  the  project  without  affecting  the  overall  project  delivery.

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.

Gedanken  or  Gedankenexperiment.  Ángel  Medinilla,  this  book’s  fantastic  illustrator,  

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!

 Project  Management  Body  of  Knowledge  (PMBO

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.  

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.

Some  researchers  have  alreadyproposedwhat  a  “good”estimate  should  be.  In  19861,  they  proposed  thata  good  estimation  approach  would  provide  estimates  “within  25%  of  the  actual  result,  75%  of  the  time”.