Requirements Engineering - Werkcollege 2012: 05-Estimating+Planning
1 like797 views
This document discusses estimating and planning in requirements engineering. It introduces estimating, which involves planning the resources, time, and size required to develop user stories or requirements. Planning involves formulating a project plan and schedule based on the estimates. The document covers estimating techniques like planning poker, where teams assign story points to user stories to estimate their size. It emphasizes that estimating is an important interface between requirements and software development planning.
![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.](https://image.slidesharecdn.com/re-werkcollege12-05-estimatingplanning-120501034714-phpapp01/85/Requirements-Engineering-Werkcollege-2012-05-Estimating-Planning-4-320.jpg)
Requirements Engineering - Werkcollege 2012: 05-Estimating+Planning
- 1. Requirements Engineering Werkcollege Spring 2012 Session 5: EsBmaBng & Planning Christoph Johann Stettina ([email protected]) Leiden University. The university to discover.
- 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.
- 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. 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. Deriving a plan (Cohn, 2005) Desired Features Divide by Story Velocity Story Story Create Estimate Derive Iteration Size Duration Plan Story Story Story Prioritize Leiden University. The university to discover.
- 7. Deriving a plan (Cohn, 2005) 5 Story Points / Desired Iteration Features Divide by ≈ May 10 Story 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. 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. 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. 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. 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. 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. 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.
- 15. ,$373'$6)',+)7;'4$)*8',$234$6)2+:7+',$6)*<7473=$:&'$;2,7+$,':06"$%&*,'$2)'$:&'$4'>73'4$)*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%*-'*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:$)'<7'B?$2,$B'88$2,$:&'$)'E07)'4$;2,7+$2):7>2+:,$ 2%,9&9#'4#,#2('D&+):#('-&9#,73#(&92'79*@*-*)*&9#,++'/2,7*&3#@8#2(,+)*+&9#96+%#,9#2,*(#2('; Planning: Agile Development Cycle E)0'#2&'2-�(*)*7;#+'3&#'7#)%	,/&#+'/26)&(#(&A*&0*7;#&,+%#')%&(F:#+'--&+)*A&#+'3&#' '$()*40+:$F2+G8*=?$:&'$/6)73:$F2+G8*=$234$:&'$F0)34*B3$+&2):$HI37;')=?$!JJKL" E&A&(8'7&#*9#(&92'79*@-'(#,--#)%&#+'3&:#&A&(8'7&#*9#,--'0&3#)'#+%,7;&#*)F:#)&9)G3(*A&7#3&A E9%'()#*)&(,)*'79#,73#2(&G0(*))&7#)&9)#+,9&9F:#'7G9*)&#+69)'/&(:#+'7)*76'69#*7)&;(,)*'7:#(&4,+) 9*/2-&9*;7#EH&+1:#!CCIF" !""#$%&'%()*+,-+./+"(01232"1+456)&1+'*7+8'&71*9+:;;<= J?)(&/(';(,//*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 # + ,3'2)&3#(&56*(&/&7)9"#P(*)*+9#%'0&A&(:#,(;6&#)%,)#@8#%,A*7;#)%&#'7G9*)&#+69)'/&(#+,7#-&,3 (&0'(1#,73#2('D&+)#9+'2&#+(&&2#@&8'73#,--#,;(&&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;#)'#)%	*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#2'9)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#)'#@&+&99,(*-8#+(&,)&3" !""#$%&'%()*+,-+./0+12+4&)20$$ Leiden University. The university to discover. *+),(-,./.)0(1"23)$$(4*+),-15
- 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. 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. Product Backlog Adjusted Estimate Sprints Initial Estimate 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 Complexity factor 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 Story 6 2 0.2 2.4 2.4 2.4 0 0 0 Leiden University. The university to discover.
- 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. 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. 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. 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.