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.
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.