1. Requirements
Engineering
Werkcollege
Spring
2012
Session
5:
EsBmaBng
&
Planning
Christoph Johann Stettina (stettina@liacs.nl)
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.

3.
Part
1
–
EsBmaBon
Planning
Poker
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.

14.
Part
2
–
Planning
Backlogs
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%*-&#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:$)'<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-&#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&(8'7&#*9#(&92'79*@-&#4'(#,--#)%&#+'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-&#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 # +
,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;#)'#)%&#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#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#)'#@&#7&+&99,(*-8#+(&,)&3"
!""#$%&'%()*+,-+./0+12&#3+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.