Agile Scrum Estimation


Published on

Few practices on Agile Estimation

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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 />