Story Points Estimation And Planning Poker
5 likes4,685 views
The document provides an introduction to story points estimation and planning poker, emphasizing their roles in the Agile methodology for estimating effort in software development. It details the planning poker process, including the need for team consensus, the significance of story points relative to effort, and guidelines for effective estimation. Additionally, it highlights best practices, common pitfalls, and alternative estimation methods to enhance team collaboration and the accuracy of project planning.
Story Points Estimation And Planning Poker
- 1. Story Points Estimation And Planning Poker An introduction
- 2. HELLO! I am Daniel Toader Software Engineer and Scrum Master @eMAG 2 /dantdr /danieltoader@dantdr You can find me on:
- 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. Basic concepts Let’s start with a few 4
- 5. What is Estimation? Estimation is a forecast … just like weather prediction. Estimation can go either way because of known unknowns and unknown unknowns. 1. 5
- 6. What is a Story Point?2. 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. What is Planning Poker?3. 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. How does Planning Poker work? Let’s go into details 8
- 10. » List of items to be estimated » Deck of estimation cards (or any scrum poker app) » Definition of done 10
- 11. Use the tools that best fit your team 11
- 12. The Process 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. When all the members of the Scrum Team have chosen their estimates, they reveal their cards at the same time. 3. 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. If consensus can not be reached after 3 iterations, go with the highest estimation 18
- 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 a team sport 21
- 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. 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 …)
- 25. Use the same sequence throughout the project 25
- 26. 26 What goes into 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 3 or 10 times as much effort as the 1st one. 1. The amount of work 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. The complexity of the work 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 risk or uncertainty of the work 29
- 30. Learn from past estimates 30
- 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. 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
- 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 a new baseline when needed 37
- 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. If no Definition of Done is set yet, start small and work towards your ideal 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. Over or under estimation can negatively affect the team’s velocity making it hard to have any predictability 43
- 44. 3. DOs and 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. Example Let’s do an example 47
- 48. 5. Other Estimation Methods Let’s see what else is out there 48
- 49. » T-Shirt Sizes » Big/Uncertain/Small » The Bucket System » Fist of Five » Affinity Estimation 49
- 50. Key takeaways » Don’t forget to leverage what everyone knows. » Discuss differences of opinions » Remember your complete Definition of Done. 50
- 51. THANKS! Any questions? 51 /dantdr /danieltoader@dantdr You can find me on: