Planning Poker Manual ? ? ? ? ? 100 100 100 100 100 40 40 40 40 40 20 20 20 20 20 13 13 13 13 13 8 8 8 8 8 5 5 5 5 5 3 3 3 3 3 2 2 2 2 2 1 1 1 1 1 0.5 0.5 0.5 0.5 0.5 0 0 0 0 0 Leading Change. Sharing Knowledge.
Planning Poker
Manual
?
?
?
?
?10
0
100
100
100
10040
40
40
40
4020
20
20
20
2013
13
13
13
138
8
8
8
85
5
5
5
53
3
3
3
32
2
2
2
21
1
11
10.5
0.5
0.5
0.5
0.50
0
0
0
0
L e a d i n g C h a n g e . S h a r i n g K n o w l e d g e .
What is Planning Poker?
Planning poker is a variation of the Wide-
band Delphi method. It is simple, quick and fun
to use, and results in reliable estimates.
Planning poker can be used to estimate just
about anything. It is often used to estimate the
effort or the relative size of tasks in software
development.
Instead of having a list of items estimated
iteratively by experts individually, the members
of the project team gather together and estimate
each item in a few rounds using the planning
poker cards until the team reaches consensus
on the size of each item.
How to play Planning Poker
The deck of cards
The deck of cards consists of the numbers 0,
0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, a question mark
and a coffee break card. This numbering takes
into account that the higher an estimate is, the
more uncertainty it contains.
The defined set of numbers
Speeds up the estimation process by limiting
the number of choices,
Avoids a false sense of accuracy for high
estimates,
Encourages the team to split large items into
smaller ones.
The question mark is used when an estima-
tor does not have enough information to make
an estimate. The coffee break card is used when
an estimator needs a break. “0” means that item
is already done.
Relative estimates instead of absolute values
Instead of estimating absolute values (e.g.
number of days needed to develop an item) it is
good practice to estimate the item’s size relative
to other similar items. If a list of tasks is to be esti-
mated, then the team estimates how big each item
is relative to the others in the list. For example, an
item with 2 points is twice as big as an item with
1 point.
Relative estimates often make it easier to have
a fact-based, objective discussion and to reach
a reasoned consensus than direct discussions
regarding effort estimates.
In addition, while the conversion rate of
points to the actual units (e.g. person days) might
change, these relative estimates remain valid.
Note: If you use this approach, the team must
avoid expressing their estimates in the actual units
during the estimation session.
Why Planning poker works
Planning poker brings together multiple expert
opinions to do the estimating.
The people who do the work are better suited
to the estimation task than anyone else.
The group discussions that arise during
planning poker improve the accuracy of the
estimates. Being asked to explain estimates
results in the emergence of important infor-
mation, leading to more accurate estimates.
The need to reach a consensus leads to aver-
aging the individual estimates through group
discussions. This leads to reliable estimates.
Finally, planning poker works because it is fun!
You can use planning poker to estimate just
about anything
Days or hours needed to complete items of a
work breakdown structure
Relative size of features (e.g. story points of
user stories)
(Relative) time for topics of a workshop
(Relative) costs of items to be bought
Impact of risks
The amount of money your colleagues have in
their pockets
… and many more measurable factors
What is Scrum?
Scrum is a process framework for managing
projects. It includes a set of practices, pre-
defined roles and artifacts.
Key characteristics of Scrum are
Teams organize themselves
A product evolves incrementally in a series of
month-long time-boxes called “sprints”
Requirements are captured as items in a list
called “product backlog” as they emerge
Intensive collaboration with the customer
All meetings are strictly time-boxed
A short introduction to Scrum
No specific engineering practices are pre-
scribed
Generic rules are used to create an agile envi-
ronment for delivering customer value
Practices and process evolve with the product
Value oriented work cycles called sprints
Work is divided into cycles called sprints. During
each sprint, the team pulls a bundle of work
from a prioritized list of features called backlog.
At the end of each sprint, a potentially shippable
product increment is delivered.
Rev
isio
n H
isto
ry
Ow
ner:
M
oritz
Pro
fitlic
hTa
rget
sta
te:
revi
ewed
revi
sion
# st
atus
da
te
resp
onsi
ble
com
men
t0.
1 un
finis
hed
24.0
7.20
08
Mor
itz P
rofit
lich
initi
al v
ersi
on0.
2 un
finis
hed
21.0
8.20
08
Mor
itz P
rofit
lich
furt
her
deve
lopm
ent,
revi
sion
his
tory
0.3
unfin
ishe
d 21
.08.
2008
To
rste
n K
olb
illus
trat
ions
rev
ised
, eye
add
ed, o
utlin
e da
rken
ed0.
4 un
finis
hed
22.0
8.20
08
Tors
ten
Kol
b 3D
-pic
togr
am fo
r sp
rint
ret
rosp
ectiv
e de
sign
ed, s
ymbo
ls p
rovi
ded
with
3D
eff
ect,
bord
er c
olor
def
ined
0.5
unfin
ishe
d 28
.08.
2008
To
rste
n K
olb
grap
hic
basi
s co
mpl
etel
y re
desi
gned
, spr
int r
etro
spec
tive
pico
tgra
m tu
rned
0.6
unfin
ishe
d 28
.08.
2008
To
rste
n K
olb
all p
icto
gram
s sc
aled
up
0.7
unfin
ishe
d 28
.08.
2008
To
rste
n K
olb
drop
sha
dow
s ad
ded
0.8
unfin
ishe
d 28
.08.
2008
To
rste
n K
olb
arro
w in
pic
togr
am s
prin
t pla
nnin
g m
eetin
g se
t to
fron
t0.
9 un
finis
hed
28.0
8.20
08
Tors
ten
Kol
b ba
ckgr
ound
mir
rore
d0.
10
unfin
ishe
d 29
.08.
2008
To
rste
n K
olb
Scru
m c
ircl
e m
odifi
ed to
squ
are
form
, pic
togr
ams
and
typo
enl
arge
d0.
11
unfin
ishe
d 29
.08.
2008
To
rste
n K
olb
shad
ows
alig
ned,
3D
eff
ect o
f arr
ow m
odifi
ed, b
ackg
roun
d sc
aled
dow
n, ty
po e
nlar
ged
0.12
un
finis
hed
04.0
9.20
08
Mor
itz P
rofit
lich
min
or im
prov
emen
ts b
y Pa
tric
k Sc
heue
rer,
read
y fo
r fe
edba
ack
sess
ion
of a
ll co
nsul
tant
s0.
13
unfin
ishe
d 04
.09.
2008
M
oritz
Pro
fitlic
h ke
rnin
g be
twee
n sl
ash
and
“upd
ate”
dec
reas
ed1.
0 re
view
ed
11.0
9.20
08
Mor
itz P
rofit
lich
sent
ence
“le
arni
ng a
nd c
ontin
ous
impr
ovem
ent”
add
ed, m
ultip
le r
evie
ws
by c
onsu
ltant
s2.
0 re
view
ed
11.0
9.20
08
Mor
itz P
rofit
lich
shad
ow m
an m
ade
dark
er, b
oxes
alig
ned
vert
ical
ly
tem
plat
e ve
rsio
n 1.
0
crea
te/u
pdat
e pr
oduc
t bac
klog
spri
nt
plan
ning
mee
ting
prod
uct
incr
emen
tsp
rint
re
view
mee
ting
spri
nt
retr
ospe
ctiv
esp
rint
lear
ning
and
con
tinuo
us im
prov
emen
t
24h
daily
Scr
um
Scrum defines 3 roles: the Product Owner, the
Scrum Master, and the team.
Product Owner
Defines and adjusts the features of the product
Prioritizes features according to customer/
market value
Accepts or rejects work results
Decides on release date and content
Scrum Master
Ensures that the team is fully functional and
productive and removes impediments
Shields the team from external interferences
Ensures that the process is followed
Team (cross-functional, 5-9 people)
Agrees on the sprint goal with the product
owner and specifies in detail the work needed
to accomplish this goal
Demonstrates the work results to the Product
Owner
Organizes itself and its work
Scrum defines 4 ceremonies: the Sprint Plan-
ning, the Daily Scrum, the Sprint Review and the
Sprint Retrospective.
Sprint Planning
The Product Owner informs the team of the
features in the product backlog that he wants
completed.
The Team determines to how much of this they
can commit to complete during the next sprint,
breaks down the selected bundle of product
backlog items into detailed tasks and estimates
each task.
Daily Scrum
Fifteen-minute meeting designed to clarify the
progress status of the sprint and team.
Each team member answers three questions:
What did I do yesterday?
What will I do today?
What impediments got in my way?
Sprint Review
Team demonstrates to the Product Owner the
potentially shippable product increment that
has been developed during the sprint.
Product Owner accepts or rejects what has
been finished.
Sprint Retrospective
Team assesses how well they worked together
in this sprint and identifies improvements.
Scrum defines 3 artifacts for prioritizing work
and tracking progress: the product backlog, the
sprint backlog, and a burn down chart.
Product Backlog
Single list of features prioritized according to
value delivered to the customer
Contains rough estimates (relative to others in
‘story points’)
Sprint Backlog
Details how the team is going to implement
the bundle of top priority features selected
from the Product Backlog for the upcoming
sprint
Product Backlog items are broken down into
tasks with no task taking longer than 16 hours
to complete
Team members volunteer to take responsibil-
ity for individual tasks
Burn Down Chart
Chart showing the cumulative work remain-
ing in a Sprint on a time axis with day by day
details
Shows the daily progress of the team during
the current sprint
Gives hints about possible impediments
Map of Change
What are the elements of successful change?
What aspects do I have to consider?
Our “Map of Change ” provides you with an
overview of the most important elements of
successful organizational change.
wibas provides the following services among
others
Coaching for ScrumMasters, Product Owners
and teams
Interim ScrumMasters
Facilitating large scale Scrum implementations
Change Management
Retrospectives
CMMI, SPICE and CITIL (CMMI+ITIL) services
ContactVolker Reiss
wibas IT Maturity Services GmbH
Otto-Hesse-Straße 19 B
64293 Darmstadt/Germany
Tel.: +49 (0) 6151 503349-19
Fax: +49 (0) 6151 503349-33
E-Mail: [email protected]
http://www.wibas.com