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

Simplifying Software Estimation

Simplifying Software Estimation

Presented at GDG MAD in July 2020.

Pratul Kalia

July 24, 2020
Tweet

More Decks by Pratul Kalia

Other Decks in Programming

Transcript

  1. Pratul Kalia @PRXTL • OBVIOUS.IN SIMPLIFYING SOFTWARE ESTIMATION

  2. SOFTWARE ESTIMATION STEVE MCCONNELL 2006, MICROSOFT PRESS

  3. WHAT IS AN ESTIMATE?

  4. LET’S DRIVE FROM ONE END OF THE CITY TO ANOTHER!

    “How much time will it take to finish all these things?”
  5. Estimates always have a probability.

  6. Targets are not estimates!

  7. THE TRAIN LEAVES AT 4.40 PM! “Here are a bunch

    of things we have to get done by X”
  8. Are you chasing a target or an estimate?

  9. PRESSURE & BAD ESTIMATES

  10. — ALL ENGINEERS “Okay, that is a bit of work

    but I’m sure I can do it in 3 days.”
  11. Stop putting yourself in unreasonable situations.

  12. There are no prizes for getting there fast!

  13. — PARKINSON’S LAW “Work will expand to fill all available

    time.”
  14. (that is… if teams have lots of extra time, more

    work will magically get created.)
  15. — GOLDRATT’S STUDENT SYNDROME “Given lots of time, students will

    delay studying until the last possible moment”
  16. Underestimation is worse than Overestimation! Stastically reduced chance of on-time

    completion.
  17. Engineers are too optimistic already.

  18. OTHER SIDE EFFECTS… Poor technical foundation, worse in the long

    run.
  19. OTHER SIDE EFFECTS… Unproductive, emotionally draining behaviours.

  20. OTHER SIDE EFFECTS… - more status meetings! - frequent re-estimation!

    - interim releases!
  21. OTHER SIDE EFFECTS… - meetings to cut scope! - fix

    bugs arising from hacks!
  22. None
  23. THE CONE OF UNCERTAINTY

  24. None
  25. “As the project progresses, estimates become more accurate.”

  26. (yes that’s quite , isn’t it.)

  27. None
  28. It is easily possible to do worse… but not better.

  29. The Cone does not narrow itself.

  30. None
  31. None
  32. Stop doing first-number-in-your-head estimates! It sets the wrong expectation!

  33. Even a 15-minute estimate is exponentially better than an instant

    one.
  34. INCLUDE EVERYTHING. Some requirements are stated. Others are implied.

  35. INCLUDE EVERYTHING. Deployment setup Maintaining build scripts Code reviews

  36. INCLUDE EVERYTHING… Writing documentation Onboarding new team members

  37. INCLUDE EVERYTHING! Creating test data Upgrading dependencies

  38. FACTORS THAT INFLUENCE ESTIMATES

  39. Size of the software! The biggest contributor to project effort

    and schedule.
  40. As size increases, effort goes up exponentially. Exponentially. Not linearly.

  41. Programmer capability. Time constraints. Team continuity. Required reliability.

  42. COCOMO-2 software estimation model.

  43. IMPROVING YOUR ESTIMATES

  44. I hope you use story points of some type.

  45. STORY POINTS. Mark of complexity They don’t (necessarily) represent time!

  46. STORY POINTS. (for e.g. A team using 1/2/3 points for

    a project.)
  47. STORY POINTS. A junior engineer takes 5 days to finish

    a 3-point task.
  48. STORY POINTS. A senior engineer takes 2 days to finish

    a 3-point task.
  49. The time taken is different. But the complexity is similar!

  50. NOT COMPLEX… Create a “lint step” on the CI server

  51. NOT COMPLEX… Add “patient has already visited” option to Overdue

    list
  52. COMPLEX? Allow Blood Pressure measurements to be deleted

  53. The Law of Large Numbers

  54. “If you create one Big Estimate, your error(s) will either

    be completely on the high side, or the low side”
  55. “but if you create multiple Small Estimates, some will be

    on high side, some on the low side.”
  56. “… so the errors will cancel each other out, to

    some extent.”
  57. COMPLEX? Allow Blood Pressure measurements to be deleted

  58. None
  59. ALSO COMPLEX Sync Protocol Drugs across all facilities and display

    in the app
  60. None
  61. Some tricks!

  62. TRICKS! Do a detailed task breakdown: spend some time!

  63. TRICKS! Think of the “worst case” while estimating.

  64. TRICKS! Compare different stories of similar complexity.

  65. TRICKS! Use a project management tool that understands “velocity”.

  66. TRICKS! Engineers should break down tasks and estimate them.

  67. TRICKS! Look at past data for your team, for similar

    type of work.
  68. TRICKS! Measure yourself privately

  69. NEGOTIATIONS & AGREEMENTS

  70. An estimate is a conversation, and a negotiation.

  71. Engineers “own” the estimate… but Management “owns” the target.

  72. The goal of estimation is NOT pinpoint accuracy!

  73. People want to understand VALUE in comparison to EFFORT.

  74. Do t-shirt-sizing with all stakeholders.

  75. VALUE EFFORT A: S M B: M S C: S

    L D: XL M
  76. Separate people from the problem.

  77. Focus on interests, not on positions.

  78. Come up with options that benefit everyone.

  79. Either everyone wins, or everyone loses.

  80. GO FORTH AND ESTIMATE!