Software estimation techniques
- 2. Agenda ● Overview ● Estimation ● Challenges with Estimation ● Story points ● Estimation techniques ● Sprint velocity ● Challenges with Sprint velocity ● Brainstorm ● Final considerations
- 3. Overview —John Maynard Keynes. It is better to be roughly right than precisely wrong.
- 4. Overview ● The problem with estimation is people ● We’re bad at making absolute estimates ○ Ideal time (hours, days, weeks) ● We’re good at making relative estimates ○ Size and complexity ● Exercise: Packing for a weekend trip
- 5. Estimation ● Relative measure of size ● How long a story will take (effort) ● Influenced by complexity, uncertainty, risk, volume of work ● Relative values are what is important ○ Login screen is 2 ○ Checkout screen is 8 ● Basic math properties should hold
- 6. Challenges with Estimation ● Ambiguous/changing requirements ● Estimating takes too long and still don’t get it right ● Estimations are provided by the wrong people ● Software projects are unique and ambiguous. ○ Hard to provide exact estimates ○ Exponential complexity ● Estimations are not commitments
- 7. Story Points ● Abstract unit of time ○ Depending on the person it can be hours, days, weeks ● The goal is to take us away from thinking in terms of absolute estimates ● Start doing estimations relatively
- 8. Story Points ● Fibonacci sequence ○ 1, 2, 3, 5, 8, 13, 21 ● Why does it work? ○ Weber’s Law states that the difference we can identify between objects is given by a percentage ○ Each Fibonacci number is about 60% larger than the preceding value ○ According to Weber’s Law, if we can distinguish a 60% difference in effort between two estimates, we can distinguish that same percentage difference between other estimates
- 9. Estimation techniques ● Poker planning ○ Each team member gives an estimation using a card ○ Create consensus ● Affinity sizing ○ Draw a vertical line on a board ○ Review stories and add them to the board ○ Determine points in the end ● Complexity buckets ○ Agree on the bucket criteria ○ Review stories and add them to the buckets ○ Combine points from the buckets and define the final story point value
- 10. Sprint Velocity ● Velocity it is a measure of team rate of progress used to estimate future commitments ● How to calculate a team velocity? ○ Look at the historical data from the previous sprints ○ Calculate a confidence interval (usually ~ 90%) ● How to use them? ○ Size -> Calculation -> Duration ■ 300 points is the size ■ 20 points is the velocity ■ The duration is 300/20 = 15 ○ It helps the team to do a rough estimation of when something is gonna be released ● Practice: Velocity chart on Jira
- 11. Challenges with Sprint Velocity ● Number of team members ● Unresolved impediments ● Unclear acceptance criterias ● Shifting priorities ● Interruptions ● Multi-tasking ● Skill level ● New members ● Team dynamics ● Vacation/sick leave
- 13. Questions?
- 14. Thank you!