# how to estimate in scrum

Post on 23-Feb-2017

68 views

Category:

## Software

Embed Size (px)

TRANSCRIPT

How to estimate Story Points in SCRUM

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 Granularity3

Estimation Over Time5

Estimation Granularity6EpicThemeFeatureUserStory

User StoryAs a (role) I want (something) so that (benefit).

8

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

9

Estimating Time Boxes10

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 weve already agreed is a 2 so its probably a 5) and to emphasize that the larger the story, the more uncertain the estimate.

Story PointsRelative ValuesSize not DurationAdditiveWork Best in Iterations

13

Story Points

7.5 FL. OZ222 ml.12 FL.OZ355 ml.

14

Story Points12358132040100?

15

In simple terms:

Its 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 commonlyused 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 weve already agreed is a 2 so its 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. Its 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 Poker

In 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 dont know (?), infinity or, sometimes, to indicate its time for a coffee break.

22

Planning Poker

Discuss 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.

23

Planning Poker35?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.

24

Planning Poker

Reach 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.

25

5Planning Poker

35355

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

26

Planning is essential, the plan is useless.

27

Thank you.

Recommended