Making  Agile  Es-ma-on  Work

Stephen  Forte @worksonmypc

I’m  Steve

Es-ma-on  Defined  (sort  of)

•  Problem  is  that  es.mates  become  a  unbreakable  schedule,    where  any  devia.on  is  considered  bad  

“Es$ma$on  is  the  calculated  approxima$on  of  a  result  which  is  usable  even  if  input  data  may  be  incomplete  or  uncertain.”  

— Wikipedia

The  Es-ma-on  Problem • When  you  come  up  with  a  project  idea,  your  first    es.mate  is  off  by  +/4x  •  Not  enough  details  are  known  

•  Tradi.onally  too  much  .me  is  spent  on  building    a  specifica.on  which  is  not  complete    •  Again,  not  enough  details  are  known  

• As  .me  progresses,  more  details  emerge  about    the  system  and  its  details  •  The  cone  of  uncertainty    

The  Cone  of  Uncertainty 4x  

2x  

1.5x  

1.25x  

1.0x  

.8x  

.67x  

.5x  

25x    

Agile  Es-ma-on •  Es.ma.on  is  uncertain  by  defini.on!  •  Problem  is  that  es.mates  become  an  unbreakable  schedule,  where  any  devia.on  is  considered  bad  

• Agile  Es.ma.on  throws  this  logic  away  and  always    re-­‐es.mates  a  project  aIer  each  itera.on  •  Different  value  system,  devia.ons  are  not  devia.ons,  they    are  more  accurate  es.ma.ons  •  Uses  the  cone  of  uncertainty  to  your  advantage  

How  to  Es-mate

User  Stories

Story  Points

Planning  Poker

Product  Backlog

Velocity

Re-­‐es-ma-on

Beyond  Es-ma-on:  Metrics

Reading  List

Books  we  have  read  and  recommend:  •  User  Stories  Applied  by  Mike  Cohn  •  Agile  Es0ma0ng  and  Planning  by  Mike  Cohn  •  Agile  Retrospec0ves  by  Esther  Derby  and  Diana  Larsen  

Ques-ons?