Requirements Engineering - Werkcollege 2012: 05-Estimating+Planning

965 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
965
On SlideShare
0
From Embeds
0
Number of Embeds
221
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Requirements Engineering - Werkcollege 2012: 05-Estimating+Planning

  1. 1. Requirements  Engineering    Werkcollege  Spring  2012    Session  5:  EsBmaBng  &  Planning   Christoph Johann Stettina (stettina@liacs.nl)                            Leiden  University.  The  university  to  discover.  
  2. 2. Session  5:  EsBmaBng  &  Planning  Today:    •  Es$ma$ng:  Planning  Poker  •  Planning:  Backlogs  Why  is  it  important?  •  Projects  o5en  overrun  cost  es$mates  •  Effort  es$ma$on  difficult  in  prac$ce  due  to   complexity  of  tasks  and  differences  in   implementa$on  speed  of  teams                            Leiden  University.  The  university  to  discover.  
  3. 3.    Part  1  –  EsBmaBon   Planning  Poker                          Leiden  University.  The  university  to  discover.  
  4. 4. Session  5:  EsBmaBon  &  Planning  Interface  between  crea$ng  requirements  and  laying  out  the  so5ware  development  process      EsBmaBng  –  Es$ma$ng  the  [resources,  $me,  size]  required  to  develop  a  [user  story,  feature,  or  requirement]      Planning  –  PuIng  the  es$mates  together  to  formulate  a  project  plan  and  schedule                                                                                                                          -­‐-­‐  Cohn  (2005)                            Leiden  University.  The  university  to  discover.  
  5. 5. Concepts  of  EsBmaBng  Size  (Cohn,  2005)  Story  Points  •  Unit  of  measure  for  the  overall  size  of  a  user  story    •  Not  related  to  the  amount  of  $me  or  people  Ideal  Bme  •  The  amount  of  $me  excluding  peripheral  ac$vi$es  •  Example:  American  football  game  =  60  minutes  Elapsed  Bme  •  Time  that  passes  on  the  clock  to  complete  it  •  Example:  American  football  game  =  3  hours  Velocity  •  Measure  of  a  team’s  rate  of  progress                            Leiden  University.  The  university  to  discover.  
  6. 6. Deriving  a  plan  (Cohn,  2005)   Desired Features Divide byStory Velocity Story Story Create Estimate Derive Iteration Size Duration Plan Story Story Story Prioritize                          Leiden  University.  The  university  to  discover.  
  7. 7. Deriving  a  plan  (Cohn,  2005)   5 Story Points / Desired Iteration Features Divide by ≈ May 10Story Velocity Story Story Create Estimate Derive Iteration Size Duration Plan 30 Story Points ≈ 6 Iterations Story Story Story Prioritize                          Leiden  University.  The  university  to  discover.  
  8. 8. How  to  esBmate?  Accuracy Pragma$c  view:     Beyond  a  certain  point   addi$onal  effort  spent   on  es$ma$on  yields   liZle  addi$onal  value     -­‐-­‐  Cohn  (2005)   Effort                          Leiden  University.  The  university  to  discover.  
  9. 9. EsBmaBng  Story  Points  (Cohn,  2005)  Take  a  medium-­‐size  story  and  assign  it  a  “5”  EsBmate  the  other  stories  accordingly  •  Twice  as  big  •  Half  as  big  •  Almost  but  not  quite  as  big  •  A  liZle  bit  bigger  Use  the  following  sizes  for  the  stories:    •  0,  1,  2,  3,  5,  8,    13,  20,  40,  100    Close to one iteration Few iterations large “story” “epic”                          Leiden  University.  The  university  to  discover.  
  10. 10. Planning  Poker  (Fægri,  2010)  Planning  Poker  Cards  •  0,  1,  2,  3,  5,  8,  13,  20,  40,  100  •  Fibonacci  sequence:  Reflect  on  uncertainty  in   es$ma$ng  larger  items  Special  Cards  •  Zero:  “Just  a  few  minutes  of  work”  •  Ques$on  mark:  “No  Idea  at  all”  •  Coffee:  “I’m  too  7red  to  think.  Let’s  take  a  break.”                            Leiden  University.  The  university  to  discover.  
  11. 11. Planning  Poker:  Rules  •  Each  task  to  be  es$mated  is  presented  by  the  Product   Owner.    •  The  group  members  ask  for  clarifica$ons  in  order  to   es$mate  the  task  effort.  (Timeboxed  discussion)  •  Upon  no$fica$on  from  the  Scrum  Master  each   member  presents  the  card  showing  the  es$mate   believed  to  best  approximate  the  task  effort.  •  If  the  es$mates  are  roughly  similar  the  Scrum  Master   uses  the  most  frequent  es$mate  as  the  task  es$mate.  •  If  there  is  wide  disagreement  in  the  es$mates  the  task   is  discussed  again  and  the  group  members  present   updated  es$mates.                                                                                  (Fægri,  2010)                          Leiden  University.  The  university  to  discover.  
  12. 12. EsBmaBon:  In-­‐class  assignment  Planning  Poker  Exercise  •  Create  groups  of  4-­‐9  •  Discuss  the  received  case  study  •  Es$mate  the  size  of  user  stories  •  Goal:  Create  a  list  according  to  size                              Leiden  University.  The  university  to  discover.  
  13. 13. Planning  Poker    Advantages  •  Mul$ple  expert  opinions  •  Discussion  leads  to  more  accurate  es$ma$ons  •  More  fun!  Disadvantages  •  Mee$ngs  with  en$re  team  more  expensive  •  Moderator  needs  to  $mebox  discussions  •  Dominant  personali$es  and  poli$cs  can   interfere                            Leiden  University.  The  university  to  discover.  
  14. 14.    Part  2  –  Planning   Backlogs                          Leiden  University.  The  university  to  discover.  
  15. 15. ,$373$6),+)7;4$)*8,$234$6)2+:7+,$6)*<7473=$:&$;2,7+$,:06"$%&*,$2)$:&$4>734$)*8,$ ,#(,2*3#4(&56&7+8#9#)%,)#,7,-89*9:#3&9*;7:#+3*7;#,73#)&9)*7;#%,22&79#,-/9)#9*/6-),7&69 )%*9#*9#*/2-&/&7)&3#)%(6;%#9/,--#*)&(,)*7#-&7;)%9#4#/,?*/,-#7&#/7)%#0%*-&#3*7;21?$:&$/+)01@2,:)$234$()*40+:$AB3)?$:&$:&)$+3:)28$1:73=$:C6,$2,$:&$/6)73:$ &A&(8)%*7;#0*)%*7#&,+%#*)&(,)*7"#=>#3&9*;7&3#4(#)&,/9#4(/#!#)#BC#/&/@&(9#3&4*7&9#3 1:73=?$:&$D278C$/+)01$234$:&$/6)73:$)<7B?$2,$B88$2,$:&$)E07)4$;2,7+$2):7>2+:,$ 2%,9&9#4#,#2(D&+):#(-&9#,73#(&9279*@*-*)*&9#,++/2,7*&3#@8#2(,+)*+&9#96+%#,9#2,*(#2(; Planning:  Agile  Development  Cycle   E)0#2&2-&#0(*)*7;#+3&#7#)%&#9,/&#+/26)&(#(&A*&0*7;#&,+%#)%&(F:#+--&+)*A&#+3&# $()*40+:$F2+G8*=?$:&$/6)73:$F2+G8*=$234$:&$F0)34*B3$+&2):$HI37;)=?$!JJKL" E&A&(87&#*9#(&9279*@-&#4(#,--#)%&#+3&:#&A&(87&#*9#,--0&3#)#+%,7;&#*)F:#)&9)G3(*A&7#3&A E9%()#*)&(,)*79#,73#2(&G0(*))&7#)&9)#+,9&9F:#7G9*)&#+69)/&(:#+7)*7669#*7)&;(,)*7:#(&4,+) 9*/2-&#3&9*;7#EH&+1:#!CCIF" !""#$%&%()*+,-+./+"(01232"1+456)&1+*7+8&71*9+:;;<= J?)(&/&#2(;(,//*7;#*9#EK8@L#,73#K*7;9M8(:#!CCNF#)%&#/9)#0*3&-8#9)63*&3#,;*-&#/&)% (&9&,(+%"#O7&#4#=>#2(&/*9&9#*9#)%&#&-*/*7,)*7#4#(&56*(&/&7)9:#%&,A80&*;%)#3&9*;7#,7 2%,9&9 # ,73 # 4(/,- # 3+6/&7),)*7 # )%(6;% # 9&,/-&99 # *7)&;(,)*7 # 0*)% # *74(/,- # ,73 # + ,32)&3#(&56*(&/&7)9"#P(*)*+9#%0&A&(:#,(;6&#)%,)#@8#%,A*7;#)%&#7G9*)&#+69)/&(#+,7#-&,3 (&0(1#,73#2(D&+)#9+2&#+(&&2#@&873#,--#,;(&&3#/&,79" !"#$%&(!)&" P(89),- # P-&,( # *9 # 7& # /&/@&( # 4 # ,# (,7;& # 4 # /&)%3-;*&9 # +79*9)*7; # 4 # P(89),- # P-&, Q&--0:#P(89),-#O(,7;&#,73#P(89),-#R&3"#S&-&+)&3#,++(3*7;#)#)%&#9*T&#,73#+(*)*+,-*)8#4#)% )%&# P(89),-#4,/*-8# (,7;&9#4(/#P(89),-#P-&,(# ,9#/9)#96*),@-&# 4(#9/,--# ,73#9*/2-&# 2 P(89),- # R&3 # ),(;&)*7; # @*; # ,73 # +(*)*+,- # 2(D&+)9" # O7-8 # P(89),- # P-&,( # ,73 # P(89),- # O(, 92&+*4*&3#*7#3&),*-#EP+1@6(7:#!CCBF" P(89),-#P-&,(#%,9#@&&7#3&A&-2&3#4(#9/,--#2(D&+)9#4#62#)#9*?#3&A&-2&(9#,73#3&9+(* 0(1 # 2(36+)9 # ,73 # 2-*+*&9: # @6) # ,A*39 # 2(+&99&9 # ( # ,()*4,+)9" # $%& # /&)%3-;8 # (&5 4--0*7; #2(2&()*&9U#4(&56&7)#3&-*A&(8#4#69,@-&#+3&#)#69&(9#0*)%#*7+(&/&7)9#@&)0&& /7)%9#EI#/,?*/6/F:#(&4-&+)*A&#*/2(A&/&7)#E2(&G#,73#29)G*7+(&/&7)#0(19%29F#,73#& 9/)*+#+//67*+,)*7#0*)%#+-+,)*7#2(&4&((&3"#P(89),-#P-&,(:#%0&A&(:#3&9#7)#(& 3+6/&7),)*7#)#@&#7&+&99,(*-8#+(&,)&3" !""#$%&%()*+,-+./0+12&#3+4&)20$$                          Leiden  University.  The  university  to  discover.   *+),(-,./.)0(1"23)$$(4*+),-15
  16. 16. Planning:  Backlogs  Product  Backlog  •  All  func$onality  required  in  the  product  •  User  stories  and  requirements  created  by  team  •  Priori$zed  according  to  Return  on  Investment    Sprint  /  IteraBon  Backlog  •  Contents  of  a  Product  Backlog  selected  for  a   “poten$ally  shippable  product  increment”                            Leiden  University.  The  university  to  discover.  
  17. 17. Product  Backlog  (Schwaber,  2004)   •  Repriori$zed  every  itera$on   •  Evolves  with  the  product   •  Owned  by  the  sponsor,  Product  Owner  Story  Name   Init   Adj.   Adj.               Est.   Factor   Est.   1   2   3   4   5  Story  1   3   0.2   3.6   3.6   0   0   0   0  Story  2   2   0.2   2.4   2.4   0   0   0   0  Story  3   3   0.2   3.6   3.6   0   0   0   0  Story  4   3   0.2   3.4   3.4   0   0   0   0  -­‐-­‐  SPRINT  1   11   0.2   13   13   0   0   0   0  Story  5   3   0.2   3.6   3.6   3.6   0   0   0                            Leiden  University.  The  university  to  discover.  
  18. 18. Product  Backlog   Adjusted Estimate Sprints Initial EstimateStory  Name   Init   Adj.   Adj.               Est.   Factor   Est.   1   2   3   4   5  Story  1   3   0.2   3.6   3.6   0   0   0   0   Complexity factorStory  2   2   0.2   2.4   2.4   0   0   0   0  Story  3   3   0.2   3.6   3.6   0   0   0   0  Story  4   3   0.2   3.4   3.4   0   0   0   0  -­‐-­‐  SPRINT  1   11   0.2   13   13   0   0   0   0  Story  5   3   0.2   3.6   3.6   3.6   0   0   0  Story  6   2   0.2   2.4   2.4   2.4   0   0   0                            Leiden  University.  The  university  to  discover.  
  19. 19. IteraBon  Backlog   •  Each  itera$on  the  team  picks  the  top  priority   items  from  the  Product  Backlog   •  Contents  of  a  Sprint  Backlog  should  be  a  part     presentable  at  the  end  of  a  sprint  Task  Name   Originator   Responsible   Status               Mo   Tu   We   Th   Fr  Task  1   Danielle   Danielle   Completed   20   0   0   0   0  Task  2   Jim   Allen   NotStarted   8   8   8   8   8  Task  3   Tom   Completed   12   0   0   0   0  Task  4   George   In  Progress   24   24   24   24   12  Task  5   Tim   Completed   12   12   12   12   12                            Leiden  University.  The  university  to  discover.  
  20. 20. IteraBon  Backlog  (Schwaber,  2004) Days  Task  Name   Originator   Responsible   Status               Mo   Tu   We   Th   Fr  Task  1   Danielle   Danielle   Completed   20   0   0   0   0  Task  2   Jim   Allen   NotStarted   8   8   8   8   8  Task  3   Tom   Completed   12   0   0   0   0  Task  4   George   In  Progress   24   24   24   24   12  Task  5   Tim   Completed   12   12   12   12   12  Task  6   Josh   In  Progress   12   10   10  Task  7   Danielle   In  Progress   24   24   24   24   12                            Leiden  University.  The  university  to  discover.  
  21. 21. Planning:  In-­‐class  assignment  Product  and  IteraBon  Backlogs  1.  Priori$ze  stories  according  to  business  needs  2.  Create  a  Product  Backlog    3.  Select  top  priority  Product  Backlog  items  4.  Think  of  actual  tasks  evolving  from  the  stories  5.  Create  a  Itera$on  Backlog                            Leiden  University.  The  university  to  discover.  
  22. 22. Bibliography  •  Cohn,  M.  (2005).  Agile  Es$ma$ng  and  Planning.  Pren$ce  Hall  PTR.  •  Fægri,  T.  E.  (2010)  “Adop$on  of  team  es$ma$on  in  a  specialist  organiza$onal  environment,”  in  In  proceedings   of  XP2010,  11th  Interna$onal  Conference,  Trondheim,  Norway,  ser.  LNBIP,  vol.  48  •  Fowler,  M.  (2004),  UML  dis$lled:  a  brief  guide  to  the  standard  object  modeling  language  (3  ed.),  Addison-­‐ Wesley,  p.  131,  ISBN  9780321193681  •  Hammer,  M.  &  Champy,  J.  (1994).  Reengineering  the  corpora$on:  A  manifesto  for  business  revolu$on.  New   York:  Harper.    •  IEEE,  So5ware  Engineering  CommiZee  (1998)  IEEE  Recommended  Prac$ce  for  So5ware  Design  Descrip$ons.   ANSI/IEEE  Std  830,  October  1998  •  Keil,  M.,  Carmel,  E.  Customer-­‐Developer  Links  in  So5ware  Development.  Communica$ons  of  the  ACM,  38  (5):   33–44,  1995.  •  van  Lamsweerde,  A.  (2009)  Requirements  Engineering:  From  System  Goals  to  UML  Models  to  So5ware   Specifica$ons.  Wiley,  March  2009.  •  Schwaber,  K.,  Agile  Project  Management  with  Scrum,  Microso5  Press,  2004                            Leiden  University.  The  university  to  discover.  

×