Agile Estimation Notes Estimation Fundamentals Velocity vs Commitment Based Planning Estimation Best Practices When to Re-Estimate Estimation Time-frames Estimation Techniques Relative Estimation Estimation Troubleshooting Estimation Fundamentals 1. An “Agile Estimate” is a measure of the effort involved in completing a piece of work. 2. “By “effort”, we mean a) amount of work b) complexity of work & c) uncertainties involved. 3. An estimate is not a target or a commitment. 4. Estimation is analytical & unbiased while planning is a biased, goal-seeking process 5. Estimation and planning should ideally be kept separate to keep estimation unbiased 6. The primary goal of estimation is to allow a team to set good targets 7. Research has shown that a +20% gap between estimates & targets are hard to achieve Estimation Best Practices 8. Estimation will only work if the team members are open & honest with each other 9. The whole team should participate in estimation 10. Estimation relies on a clear “Definition of Ready” and “Definition of Done” 11. Especially in early stages where project uncertainty is high, estimate using a range (A to B) or a confidence level (A with X% confidence) 12. Don’t use a linear estimation scale. Instead use a Fibonnaci sequence, or a Modified Fibonnaci sequence 13. Rely on your teams current velocity numbers when estimating & planning, and don’t rely on a projected future velocity Estimation Time-frames 14. A project is at risk if a plan extends well beyond a planner's horizon & does not include opportunities for the planner to make adjustments 15. A progressive elaboration of plans works best in agile environments 16. Agile teams do planning in different time-frames 17. Most agile teams do daily planning via a 15 minute “daily scrum” 18. Iteration planning usually looks 1 to 4 weeks out 19. Release planning focuses on supporting upcoming releases 20. Product planning is driven by the Product Owner, and considers how the product needs to evolve 21. Portfolio & strategic planning are usually performed outside the Agile team Relative Estimation 22. A relative estimate does not measure using “time units” but an “arbitrary unit” 23. A story point is a measure of effort to complete a user story that is relevant only to a specific team i.e. 1 story point for team A cannot be compared with 1 story point for team B 24. Story points work well because they a. Are agnostic of individual skill levels b. Speed up the estimation process c. Remove emotional attachment from estimation d. Reduce unhealthy competition between teams 25. An “ideal day” assumes a) no multitasking b) all resources are available and c) no interruptions 26. Velocity is the amount of work a team can complete in an iteration 27. Focus factor = actual velocity / available days Velocity vs Commitment Based Planning 28. Velocity based planning looks at past results and takes a formulaic approach to determine how much work a team should pick up in an upcoming iteration 29. Commitment based planning relies on the team using “gut feel” and making a commitment on how much work they should pick up in an upcoming iteration 30. Velocity based planning is easy to justify and works well for long term planning but not as well for shorter term planning 31. Commitment based planning empowers the team, and can result is greater team dedication, but does not work as well for long term planning When to Re-Estimate 32. A story that has not been picked up by development can be re-estimated at any time. 33. A story that is currently in development should generally not be re-estimated as this will undermine the team's velocity calculations. 34. Bugs discovered that are unrelated to the current iteration can be estimated. 35. Bugs discovered that are related to the current iteration are not estimated, but are included in the estimation for the related story. 36. Any investigative work (spikes) are usually not estimated, but time-boxed. 37. At the end of an iteration, for partially completed stories, re-estimate work remaining if that story will be moved back into the Product Backlog i.e. not picked up immediately in the upcoming iteration. Estimation Techniques 38. Planning poker encourages “independent thinking” within Agile teams. 39. In Planning Poker, each team member receives a deck of 13 cards with values ?, ∞, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 and 100. During estimation... a. Each team member places their selected card face down on the table. b. Team members all reveal their estimates (cards) at the same time. c. Differences are discussed, task breakdowns are done as needed until the team arrives at an agreement. 40. Planning Poker can also be done with distributed teams, using tools like Pointing Poker. 41. T-shirt sizing uses sizes ranging from “XS, S, M, L, XL”. 42. The Bucket System uses a “divide and conquer” approach to estimate a large number of backlog items in a short period of time. 43. Silent Estimation is optimized for speed, and involves teams performing estimations silently, with only stories that have disagreements being discussed. 44. The 3 point estimation considered the “Optimistic”, “Likely” & “Pessimistic” outcomes to triangulate an estimate Estimation Troubleshooting 45. Estimation is difficult because: a. Teams often operate in an environment of high uncertainty. b. Team members have biases such as “planning fallacy” which results in a bias towards optimism, and “anchoring” which creates a bias towards initial estimates. 46. A user story is not a requirement. It is a short, informal statement that focuses on the end user and facilitates a conversation within the team. It helps drive clarity and enables better estimation. 47. A good user story is targeted to a specific persona, is not overly prescriptive (don’t define the how), and includes acceptance criteria to define the boundaries of the story. 48. Multi-tasking results in a) burnout b) mistakes & c) lack of creativity 49. Acknowledge uncertainty by a) not making early promises b) iterating often and c) learning how to negotiate with stakeholders 50. A stable agile team has dedicated members who ideally focus on 1 product
