Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Scrum Estimation


Published on

Few practices on Agile Estimation

  • Be the first to comment

Agile Scrum Estimation

  1. 1. Estimation - Thoughts<br />Scrum Master<br />Prasad Prabhakaran<br />
  2. 2. Agenda<br /><ul><li>Estimation : waterfall Vs Scrum
  3. 3. Product back log estimation units</li></ul>Story points <br />Ideal time<br /><ul><li>Techniques for estimation
  4. 4. Iteration planning
  5. 5. Release planning
  6. 6. Summary
  7. 7. References </li></li></ul><li>Water fall Vs Scrum estimation<br />Manager estimates<br />Task is assigned <br />Time based estimates <br />Work break down estimates <br />Team estimates their own work<br />Self organized <br />Size based - unit less relative estimates<br />Feature break down estimates <br />Water fall <br />Scrum<br />
  8. 8. Estimating user stories <br />We are talking about product backlog estimates<br />Two techniques <br /><ul><li>Story points
  9. 9. Ideal days </li></ul>Estimate size & derive duration <br />
  10. 10. Story points<br /><ul><li>The bigness of the task
  11. 11. Influenced by how hard it is ? & How much there is?
  12. 12. Relative values are what is important , for eg: login screen is a 2,search feature is 6
  13. 13. Points are unit less
  14. 14. On order of magnitude
  15. 15. Clue is determine complexity factor ( for eg: due to requirement and technology)
  16. 16. What is your t-shirt size ? </li></li></ul><li>Estimating in ideal time <br /><ul><li>How long it would take if </li></ul> a) It is all you worked on <br /> b) You had no interruption<br /> c) Every thing you need is available<br /><ul><li> for eg: Ideal time for a football game is 60 minutes, but elapsed time is much longer
  17. 17. It is easier to estimate in ideal time than in ‘actual ‘/ ‘elapsed’ time, because need to consider all the factors that affect elapsed time at the same time you are estimating.</li></ul>What is your office timings? What is your focus factor?<br />
  18. 18. Ideal time Vs Story point approaches <br /><ul><li>Story points help drive cross-functional behavior</li></ul>• Story point estimates do not decay<br />• Story points are a pure measure of size<br />• Estimating in story points is typically faster<br />• My ideal days cannot be added to your ideal days<br />• Ideal days are easier to explain outside the team<br />• Ideal days are easier to estimate at first<br />
  19. 19. Three levels of planning<br />Release plan -&gt; Product back log<br />Sprint / iteration plan -&gt; Sprint back log<br />Daily plan -&gt; Daily Scrum / stand up meeting<br />
  20. 20. Best practice <br /><ul><li>Prefer story points</li></ul>...but they make some teams uncomfortable, so start with ideal time<br />• Gives the team a nice foundation for the initial stories, helps team get started<br />• Define “1 story point = 1 ideal day”<br /> Then gradually convert team to thinking in unit-less story points<br /> “This story is like that story.”<br />• Stop talking about how long it will take<br />
  21. 21. Estimation technique<br />Estimate by Analogy <br />Comparing a user stories to other – Relative sizing <br />Planning poker game <br /><ul><li>Each estimator is given a deck of cards, each card has a valid</li></ul>estimate written on it<br />• Customer/Product owner reads a story and it’s discussed<br />briefly<br />• Each estimator selects a card that’s his or her estimate<br />• Cards are turned over so all can see them<br />• Discuss differences (especially outliers)<br />• Re-estimate until estimates converge<br />
  22. 22. Why Planning poker works<br /><ul><li>Emphasizes relative estimating</li></ul>• Focuses most estimates within an approximate one order of magnitude<br />• Everyone’s opinion is heard<br />• Estimators are required to justify estimates<br />• It’s quick<br />• It’s fun<br /><br />
  23. 23. Sprint planning <br /><ul><li>What is the sprint duration? 3 weeks/ 4 weeks etc..
  24. 24. Availability of team members
  25. 25. What is the ‘focus factor’ ( from history, Available days ÷ Story points completed
  26. 26. Velocity - use historical, very difficult in initial sprints, forecast it. best in range, total number of story points can be completed in a sprint
  27. 27. Pick up product backlogs based on your velocity </li></li></ul><li>Release planning – fixed time <br />Determine how many sprints you have ( (desired date – today’s date)/ sprint duration ) <br />2. Estimate velocity as a range<br />3. Multiply low velocity X number of sprints<br />• Count off that many points<br />• These are “Will Have” items<br />4. Multiply high velocity X number of sprints<br />• Count off that many more points<br />• These are “Might Have items”<br />
  28. 28. Summary & Key takeaway <br /><ul><li>Objectives Estimate - Product Backlog items / story points
  29. 29. Many Tasks leading up to the objectives
  30. 30. Relative value should be used for estimating - story points
  31. 31. Absolute value for tasks
  32. 32. Estimate product back log items during release / product planning
  33. 33. Estimate tasks during sprint planning meetings
  34. 34. Velocity - average story points completed in sprints </li></li></ul><li>References<br /> scrum-xpfrom- the-trenches<br /><br />Confessions of a serial product owner Based on a true story Anna Forss<br />Join Agile Alliance group @ Linkedin<br />Join Agile alliance charter CoP @ <br />Go to ( give u r network id and password) <br />Select CoP-&gt; join CoP<br />CoP Sites -&gt; Agile Alliance <br />
  35. 35. Q &A Thanks <br />