How to estimate

User Stories in Story

Points with SCRUM Created and presented by

Gloria Stoilova SCRUM Trainer

What is “STORY POINTS”?

•Story point is an arbitrary measure used by Scrum teams to measure the effort

required to implement a story.

Estimation Granularity

3

Estimation Over Time

5

Estimation Granularity

6

Epic ThemeFeature User

Story

User Story As a (role) I want

(something) so that

(benefit).

“As a registered user I want to be able to search the online catalog so that I can find items to purchase.”

Estimating Time Boxes

10

Why we need to estimate the User Stories?

• Estimating the relative size of stories in terms of effort/time and can help a team to decide how many of the highest priority stories from the product backlog can be taken on in a single sprint and delivered by its end.• Estimating is also used to measure the velocity of a team (VELOCITY -

the amount of work that team gets through per sprint), helping the Product owner to forecast the release schedule and the product development.

Estimating using story points.• The most common way of estimating the size of user stories in Scrum

is by allocating story points. • Story points are just numbers drawn from a pool of numbers of a set

size e.g. a story could have 1, 2, 3, 5, 8, 13, 20, 40 or 100 story points.• The reason for using a Fibonacci-like sequence of numbers is to

encourage stories to be estimated relatively (e.g. that story looks like it requires about twice the effort for a story we’ve already agreed is a 2 so it’s probably a 5) and to emphasize that the larger the story, the more uncertain the estimate.

Story PointsRelative Values

Size not Duration

Additive

Work Best in Iterations

Story Points

7.5 FL. OZ222 ml.

12 FL.OZ355 ml.

Story Points

1 2 3 5 8

13 20 40 100 ?

In simple terms: • It’s a number that tells the team how hard the story is! Hard could be related to Effort, Complexity and Uncertainty.

IF you look at the Fibonacci curve it is really takes a steep climb. If using this series consider not using 1 and rarely use 2. Use 3, 5, 8, 13, 20, 40, 100.

• In most cases a story point range is 1, 2, 4, 8, 16 or X Small, Small, Medium, Large, Extra Large.

Most commonly used series is the Fibonacci series.

A Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, 34, 45.... Teams use a modified version of this which looks like 1, 2, 3, 5, 13, 40, 100. The reason it is suggested that way is because the original sequence suggests mathematical accuracy and real projects are not like that.

* The reason for using a Fibonacci-like sequence of numbers is to encourage stories to be estimated relatively (e.g. that story looks like it requires about twice the effort for a story we’ve already agreed is a 2 so it’s probably a 5), and to emphasize that the larger the story, the more uncertain the estimate.

When we estimate?• A Scrum team will estimate story points during backlog refinement or

perhaps as part of a dedicated session. It’s essential that the whole team 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.

• When a story is ready for estimation? –when it is small enough to fit within a single sprint and when the acceptance criteria have been agreed by the scrum team – the team then discusses its relative size and reaches consensus over how many story points of effort it requires.

When a story is ready for estimation?

• when it is small enough to fit within a single sprint and when the acceptance criteria have been agreed by the scrum team – the team then discusses its relative size and reaches consensus over how many story points of effort it requires.• Stories may be estimated before these criteria are met but should be

revisited.• The most common way to do this is Scrum is by playing planning

poker.

Baseline story In order to do that each team would have to find a baseline story.

It does not have to be the smallest one, but one that all in the team can relate too.

From then on all sizing should be done compared to that baseline.

It is important to identify one or multiple baseline stories or also called reference stories against which you would do a relative sizing of the backlog. This story is picked from the current product backlog or is a different story that we have done earlier. But what is important is that the understanding of this story is same among everyone on the team. The team should be confident of this base story.

Planning PokerIn planning poker each member of the team gets a set of Scrum cards with the allowable story points printed on the front as well as extra cards for don’t know (?), infinity or, sometimes, to indicate it’s time for a coffee break.

Planning PokerDiscuss and jot down any details you want to remember when implementing this storyThese can be bullet points on the story card or text in the notes section of a tool, or Story board notes, etc.

Planning Poker3

5

?13

5

Once the story is ready to be estimated, there is a round of voting. At the same time, all team members hold up the card which corresponds to their estimate.

Planning PokerReach a consensus

consenting to a proposal of the size of the story as per Definition of

Done doesn't necessarily mean it is your choice.

The team is encouraged to come up with the best estimation that,

as a group, everyone accepts.

5

Planning Poker

3

5 3

5

5

Revote

If all the team members agree then the story is given that number of points and the team moves on.

“Planning is essential, the plan is useless.”

Thank you.