Planning poker is a consensus-based estimation technique where a development team discusses story point estimates by using estimation cards. It involves the product owner presenting a story to be estimated, team members privately selecting a card with their estimate, revealing estimates simultaneously, and discussing until consensus is reached. Key factors in estimates include amount of work, complexity, and risk/uncertainty. Velocity is tracked to measure team capacity over sprints.

1. Story PointS
Estimation And
Planning Poker
An introduction

2. HELLO!
2
I am Daniel Toader
Software Engineer and Scrum Master
@eMAG
You can find me on:
/dantdr @dantdr /danieltoader

3. TopicS
1. Basic concepts
2. How does Planning Poker
work?
3. DOs and DON’Ts
4. Example
5. Other estimation methods
3

4. 1.
BdSic conceptS
Let’s start with a few
4

5. 1. WhdtiS EStimdtion?
Estimation is a forecast …just like weather
prediction. Estimation can go either way because
of known unknowns and unknown
unknowns.
5

6. 2. Whdt iS d Sto/y Point?
A Story Point (SP) is a relative unit of measure,
decided upon and used by individual Scrum teams,
to provide relative estimates of effort for completing
requirements.
6

7. 3. WhdtiS Pldnning PoLe/?
Planning Poker is a consensus-based estimating
technique. Planning Poker can be used with story
points, ideal days, or any other estimating unit.
7

8. 2.
HowdoeS Pldnning PoLe/
wo/L?
Let’s go into details
8

9. Prerequisites
9

10. » List of items to be estimated
» Deck of estimation cards (or any scrum poker
app)
» Definition of done
10

11. Usethetools that bestfit yourteam
11

12. TheProcess
12

13. 1. The Scrum Product Owner presents the story to be
estimated. The Scrum Team asks questions and the
Product Owner explains in more detail. A time-
constraint can be set for each story estimation.
13

14. 2. Each member of the Scrum Team privately (to make
the
estimate objective) chooses a card to represent his
or
her estimate.
14

15. 3. When all the members of the Scrum Team have
chosen
their estimates, they reveal their cards at the same
time.
15

16. 4.1. If there is consensus on a particular number then the
size
is recorded and the team moves to the next story.
16

17. 4.2. In the event that the estimates differ, the high and
low
estimators are allowed to explain their estimates to
the
rest of the team. The Scrum Team can briefly debate
the arguments.
Continue from step
2.
17

18. Ifconsensuscannotbereachedafter 3
iterations, gowith the highestestimation
18

19. 19
WhoParticipates?

20. It is essential that the whole team (developers,
designers, testers, deployers... everyone) is
involved in the process of estimation so that the
estimates are made by the people who will actually
be doing the work and are therefore as accurate as
possible.
20

21. Agile estimation is ateamsport
21

22. 22
Estimation Values

23. When we estimate with story points, we assign a
point value to each item. The raw values we assign
are unimportant.
What matters are the relative values.
A story that is assigned a 2 should be twice as
hard as a story that is assigned a 1.
23

24. Sto/y point SequenceS
24
» Standard
(0,½,1,3,5,8,13,20…)
» Fibonacci
(0,1,2,3,5,8,13,21…)
» Powers of 2 (1,2,4,8,16 …)

25. Usethesamesequencethroughouttheproject
25

26. 26
Whatgoesinto a
Story Point?

27. Certainly, if there is more to do of something, the
estimate of effort should be larger.
Consider the case of developing two web pages: the
1st page has 1 input field and the 2nd page has
100.
The 2nd page should be given more story points, not
100 times more, but maybe making the 2nd page is
just 2 or 3or 10 times as much effort as the 1st one.
1.Thedmount of wo/L to do
27

28. Additional complexity should be reflected in the
estimate provided.
What if for the 2nd page the fields are of different
types and interact with each other? There are still
100 fields on the page, but now they are now harder
to implement.
There is a higher chance to make a mistake or
miss something and having to go back and
correct it.
2. Thecomplexity of the wo/L
28

29. The amount of risk and uncertainty of an item
should affect the story point estimate given to it.
If the item is unclear about what will be needed,
that uncertainty should be reflected in the
estimate.
If implementing a feature involves changing a
particular piece of old, brittle code that has no
automated tests in place, that risk should be
reflected in the estimate.
3. Any /iSL o/ unce/tdinty of the wo/L
29

30. Learnfrompastestimates
30

31. 31
Story Points
Vs.
Hours

32. With man-hours, developers expect that they’ll log
the exact number of hours estimated for the
sprint.
But that’s a double-edged sword.
If they exceed the estimate for a sprint, then it
suggests they’re a poor performer.
But if they complete the sprint under the estimate,
then it means that there was something wrong with
the it.
32

33. Sto/y PointS ddvdntdgeS ove/ hou/S
» No correlation with skills and experience of the
estimator
» Velocity is tracked
» No re-estimation needed if the team’s capacity
changes
33

34. 34
Story Point Baseline

35. Planning Poker relies on relative estimating, in
which the item being estimated is compared to
one or more previously estimated items.
It is the ratio between items that is important.
An item estimated as 10 units of work (generally,
story points) is estimated to be twice as hard as
an item estimated as 5 units of work.
35

36. In order to establish a baseline, the team must
identify at least two items that span the 1 to 10
point range.
The size should be set just through discussions,
solid arguments and everyone must be in
consensus.
Ideally, 2 and 5 story point items are chosen, but if
finding them proves difficult, look instead for a 2 and
an 8, or a 3 and an 8.
36

37. Establish anewbaseline whenneeded
37

38. 38
Definition of Done

39. The Definition of Done is a list of criteria which must
be met before an item is considered "done".
It is an important part of planning poker as when
estimating, the scrum team needs to take into
account each and every item on the list in order
for the item to be considered done.
Based on what is on the list it may increase the
final story point estimation.
39

40. IfnoDefinitionofDoneis set yet,start
small andworktowardsyourideal DOD.
40

41. 41
Velocity

42. Velocity is a measure of the amount of work a team
can tackle during a single sprint. Velocity is
calculated at the end of the sprint by totaling the
points for all fully completed items.
Points from partially-completed or incomplete
stories should not be counted in calculating
velocity. Velocity should be tracked throughout the
sprint on the sprint burndown chart and made
visible to all team members.
42

43. OVerorunderestimationcannegatiVely
affect theteam’sVelocity makingit hard
tohaVeanypredictability
43

44. 3.
DOS dnd DON’TS
What to do, what not to do
44

45. DOS
» it is OK to have differences
» time box the estimation process for each
story
» vote independently without undue
influence
» discuss high and low votes
» keep discussions productive
» remember the baseline
» establish a new baseline when needed
45

46. DON’TS
» force your ideas / vote
» intentionally over or under estimate
» only estimate your own work (not the whole
team’s)
» only estimate the coding time
» have a clear Definition of Done
» go into to much details regarding
implementation
» average story points during planning poker
46

47. 4.
Exdmple
Let’s do an
example
47

48. 5.
Othe/ EStimdtion MethodS
Let’s see what else is out there
48

49. » T-Shirt Sizes
»
Big/Uncertain/Smal
l
» The Bucket
System
» Fist of Five
» Affinity
Estimation
49

50. Key tdLedwdyS
» Don’t forget to leverage what everyone
knows.
» Discuss differences of opinions
» Remember your complete Definition of
Done.
50

51. THANKS!
Any questions?
51
You can find me
on:
/dantdr
@dantd
/danieltoade
r