Estimating User Story Using Story Points.ppt

Story Points
Estimation And
Planning Poker
An introduction

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

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

1
.
Basic concepts
Let’s start with a few
4

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

2. What is a Story 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

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

2
.
How does Planning Poker
work?
Let’s go into details
8

» List of items to be estimated
» Deck of estimation cards (or any scrum
poker app)
» Deﬁnition of done
10

Use the tools that best ﬁt your team
11

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

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

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

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

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 brieﬂy debate
the arguments.
Continue from
step 2.
17

If consensus can not be reached after 3
iterations, go with the highest estimation
18

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

Agile estimation is a team sport
21

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

Story 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
…)

Use the same sequence throughout the project
25

26
What goes into
a Story Point?

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 ﬁeld 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 3 or 10 times as much effort as
the 1st one.
1. The amount of work to do
27

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. The complexity of the work
28

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 reﬂected 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
reﬂected in the estimate.
3. Any risk or uncertainty of the work
29

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

Story Points advantages over hours
» No correlation with skills and experience of the
estimator
» Velocity is tracked
» No re-estimation needed if the team’s capacity
changes
33

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

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 ﬁnding them proves di cult, look instead
ﬃ
for a 2 and an 8, or a 3 and an 8.
36

Establish a new baseline when needed
37

The Deﬁnition 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
ﬁnal story point estimation.
39

If no Deﬁnition of Done is set yet, start
small and work towards your ideal
DOD.
40

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

Over or under estimation can negatively
affect the team’s velocity making it hard
to have any predictability
43

3
.
DOs and
DON’Ts
What to do, what not to
do
44

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

DON’T
s
» 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 Deﬁnition of Done
» go into to much details regarding
implementation
» average story points during planning poker
46

4.
Example
Let’s do an
example
47

5
.
Other Estimation Methods
Let’s see what else is out there
48

» T-Shirt Sizes
»
Big/Uncertain/Small
» The Bucket
System
» Fist of Five
» A nity
ﬃ
Estimation
49

Key takeaways
» Don’t forget to leverage what everyone
knows.
» Discuss differences of opinions
» Remember your complete Deﬁnition of
Done.
50

THANKS!
Any questions?
51
You can ﬁnd me
on:
/dantdr @dantdr
/
danieltoade
r

Estimating User Story Using Story Points.ppt

More Related Content

Similar to Estimating User Story Using Story Points.ppt

Recently uploaded

Estimating User Story Using Story Points.ppt