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: volker.reiss@wibas.com

http://www.wibas.com