Recommended
Recommended
More Related Content
Similar to The art (and science) of software estimation - Otto Coster
Similar to The art (and science) of software estimation - Otto Coster (20)
Recently uploaded
Recently uploaded (20)
The art (and science) of software estimation - Otto Coster
- 1. The art (and science) of software estimation Otto Coster Van Lanschot Kempen
- 2. • Why is it so hard? • Common pitfalls • The estimation game • Proven methods • Becoming better at estimation
- 3. The hardest part of software development?
- 5. Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
- 6. Why is it so hard?
- 7. Known knowns • Tapped knowledge • Requirements Known unknowns • Risks Unknown knowns • Untapped knowledge Unknown unknowns • New software features
- 16. Task A Estimate: 3 points Team has done already ten times in the past Task B Estimate: 3 points Never done before, or it has unclear interdependencies
- 17. What estimates actually are: they are not single numbers but big blobby things with uncertainties, assumptions, and constraints
- 18. 8x 2 point stories vs. 2x 8 point story
- 19. Proven methods
- 34. 0 1 2 3 4 5 6 7 8 9 1 2 3 5 8 0 5 10 15 20 25 30 35 40 1 2 3 5 8 13 21 34
- 35. Use anchor stories • Define a 1, 5 and 13 point story • Relate (or categorize) every story to these anchors
- 38. Excersise
- 39. A private banking customer wants to buy some Lockheed Martin stock options via Van Lanschot Kempen. How can it fail?
- 40. Restricted stock Not enough balance eXimius is down Bankview is down Wrong type of investment account No rights to order online No rights to order options Does not fit in the customer’s risk profile VLK doesn’t offer the stock anymore Stock exchange is closed
- 41. Estimating better • Do a premortem when refining • Break things down • Estimate further up the hill • If you are early on the hill: • Add more points for uncertainty • OR spent more time on refinement • Use anchor stories • Expand your Fibonacci range
- 42. Estimating better • Look beyond just the code • Testing risks • Remember test environment unavailability or test data issues • New technology risks • Integration risks • Tech debt / refactoring risks • Non-functional requirements • Performance, security, availability
- 43. Estimating better • Push the scariest work uphill first • Recognize your own biases: what do you generally underestimate? • When is it really Done? • Agile cycle: define new user stories with findings
- 44. Thank you