Successfully reported this slideshow.
Upcoming SlideShare
×

# How to estimate in scrum

469 views

Published on

A short explanation why and how to estimate in Scrum with Story Points.

Published in: Software
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

### How to estimate in scrum

1. 1. How to estimate User Stories in Story Points with SCRUM Created and presented by Gloria Stoilova SCRUM Trainer
2. 2. What is “STORY POINTS”? •Story point is an arbitrary measure used by Scrum teams to measure the effort required to implement a story.
3. 3. Estimation Granularity 3
4. 4. Estimation Over Time 5
5. 5. Estimation Granularity 6 Epic Theme Feature User Story
6. 6. User Story As a (role) I want (something) so that (benefit).
7. 7. “As a registered user I want to be able to search the online catalog so that I can find items to purchase.”
8. 8. Estimating Time Boxes 10
9. 9. 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.
10. 10. 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.
11. 11. Story Points
12. 12. Story Points 7.5 FL. OZ 222 ml. 12 FL.OZ 355 ml.
13. 13. Story Points 1 2 3 5 8 13 20 40 100 ?
14. 14. 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.
15. 15. 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.
16. 16. * 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.
17. 17. 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.
18. 18. 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.
19. 19. 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.
20. 20. 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 don’t know (?), infinity or, sometimes, to indicate it’s time for a coffee break.
21. 21. Planning Poker Discuss and jot down any details you want to remember when implementing this story These can be bullet points on the story card or text in the notes section of a tool, or Story board notes, etc.
22. 22. Planning Poker 3 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.
23. 23. 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.
24. 24. 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.
25. 25. “Planning is essential, the plan is useless.”
26. 26. Thank you.