Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Estimation Sucks

Estimation Sucks


Chris Trevarthen

June 21, 2014


  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…
  12. None
  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.
  32. None
  33. None
  34. None
  35. None
  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.
  55. None