Estimation Sucks

Transcript

1. est. sux.
2. @malusman
3. What is estimation, really? Estimation is a bet
4. Devs bet that they understand the problem and the toolset
5. QA bets that there will be little or no bugs (or that they can handle the amount)
6. Delivery leads bet that the business requirements are well-defined and that the velocity will be constant.
7. Product owners bet that the customers want certain features.
8. The business bets that there will be a return on investment for the project. So why does estimation suck, then?
9. Most estimates are poop. Even when we try to compensate for them…
10. Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. But why are we so bad at estimating software projects? In software, we’re solving problems instead of just building a thing.
11. A house predictably solves a set of problems that fit almost everyone’s: been building houses for thousands of years, roof/shelter, heat/cooling, security (doors), not-falling-down…
13. Once we get out of those basic requirements, though, things can get a little more complicated, and estimates start to slip.
14. tools to build a house pretty well known and fundamentally unchanged (fits in a Home Depot)
15. zoning laws and codes builders have to adhere to
16. Software needs to be more adaptable (not everyone has the same needs/values) We’ve only been building software for a few decades
17. Wikipedia’s List of Computer Languages: 679 tools to build software are always changing
18. tools that are supposed to help us build software faster are also always changing
19. many “best practices”, but very little enforcement (so many ways to fail)
20. Y? Why does estimation suck?
21. Estimation costs money Anecdote: project estimation $200K on a project, detailing features and then the features were completely changed by the time they were implemented Anecdote: project estimation took 6 months, flip-flopping between solutions and estimating all possibilities, then took 1 year to develop
22. Lends to waterfall approach
23. Doesn’t align with delivering value.
24. WRONG. Most of all, because we hate to be wrong and we are wrong A LOT.
25. A LOT. Most of all, because we hate to be wrong and we are wrong A LOT.
26. How are we estimating?
27. +30% Guesstimate
28. x2 Both of these add some arbitrary buffer that may or may not give you enough time. Could go the opposite way and over inflate your estimate, which can actually remove a sense of urgency.
29. Break down projects into tasks and assign hours Anecdote: UI/DB/Logic Very detailed Might be slightly more accurate Tedious on very large projects with large teams Assigning hours implies an accuracy that might not be there
30. Planning poker helps to share estimation across the team without anchoring. (Can’t estimate in isolation). Fibonacci removes some options so at higher levels, forced to consider the complexity up or down (if it was going to take a 6, it’s probably an 8) It’s still numbers, so team needs to decide what they mean. What is a point?
31. Points can be too easy to use math, and we get stuck thinking of the time it will take instead of relative complexity.
36. Team still needs to agree on a frame of reference.
37. Dirty truth: someone is going to convert those arbitrary measurements into numbers, so it might as well be you. Sure we can measure the velocity of cards, but then we have to break them down anyway. How many smalls equal a large? We did 2 mediums and a large this week but 4 smalls and a medium the previous week.
38. K…
39. how do we do this in the real world?
40. involve the whole team, especially the product owner in estimation answers questions, clarifies real requirements, gets a glimpse into the mind of the dev
41. Estimation is a great time to talk about priorities
42. With prioritization, you can let the product owner do the estimation for you.
43. Keep things high level until you’re getting ready to do the work. sprint planning priorities can shift, so you’ll focus your time on detailed estimates of what counts
44. Constantly assess the situation with the whole team
45. burn-down is a traditional way of tracking progress (great if no scope changes)
46. If scope increases, you get hills and no real way to know what your progress was (especially if the hills are more gradual)
47. burn up charts let you see where scope increased and decide how far out to adjust the x axis to meet the change.
48. No estimates* no estimates* (hard to do on a new team) play a psychological trick on yourself - break cards down to 1 day or 1/2 day chunks
49. at the end of each sprint, count how many cards you finished = that’s your velocity no need to do formal estimation, just break cards down like you normally would with tasks takes a few sprints to get decent velocity numbers and would still require some way of breaking cards down in the backlog. Could work well with tshirt/ reptile size estimates.
50. I SAID NO ESTIMATES! Need a mature team and a trusting business. Continually iterate and provide a valuable product. A bit like “how much will it cost”? “well how much do you have?”
51. Make commitments. Keep them.
52. Should I include writing tests/TDD in my estimates? Do you actually write tests normally?
53. Should I include QA time in my estimates? What is your definition of done? When can you ship a feature?
54. What if I’m an independent contractor and I need to provide hours? even if you’re not on a team, create your own turndown chart. track EVERYTHING.