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

    View Slide


  2. SOFTWARE ESTIMATION
    STEVE MCCONNELL
    2006, MICROSOFT PRESS

    View Slide

  3. WHAT IS AN ESTIMATE?

    View Slide

  4. LET’S DRIVE FROM ONE END OF THE CITY TO ANOTHER!
    “How much time will it
    take to finish all these
    things?”

    View Slide

  5. Estimates always
    have a probability.

    View Slide


  6. Targets are not
    estimates!

    View Slide

  7. THE TRAIN LEAVES AT 4.40 PM!
    “Here are a bunch of
    things we have to get
    done by X”

    View Slide


  8. Are you chasing a
    target or an estimate?

    View Slide

  9. PRESSURE
    & BAD ESTIMATES

    View Slide

  10. — ALL ENGINEERS
    “Okay, that is a bit of
    work but I’m sure I can
    do it in 3 days.”

    View Slide


  11. Stop putting yourself
    in unreasonable
    situations.

    View Slide

  12. There are no prizes
    for getting there fast!

    View Slide

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

    View Slide

  14. (that is…
    if teams have lots of extra time,
    more work will magically get
    created.)

    View Slide

  15. — GOLDRATT’S STUDENT SYNDROME
    “Given lots of time,
    students will delay
    studying until the last
    possible moment”

    View Slide

  16. Underestimation is worse than
    Overestimation!
    Stastically reduced chance
    of on-time completion.

    View Slide


  17. Engineers are too
    optimistic already.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  21. OTHER SIDE EFFECTS…
    - meetings to cut scope!
    - fix bugs arising from hacks!

    View Slide

  22. View Slide

  23. THE CONE OF
    UNCERTAINTY

    View Slide

  24. View Slide

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

    View Slide

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

    View Slide

  27. View Slide


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

    View Slide

  29. The Cone does not
    narrow itself.

    View Slide

  30. View Slide

  31. View Slide

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

    View Slide


  33. View Slide

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

    View Slide

  35. INCLUDE EVERYTHING.
    Some requirements are
    stated.
    Others are implied.

    View Slide

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

    View Slide

  37. INCLUDE EVERYTHING…
    Writing documentation
    Onboarding new team
    members

    View Slide

  38. INCLUDE EVERYTHING!
    Creating test data
    Upgrading dependencies

    View Slide

  39. FACTORS THAT
    INFLUENCE ESTIMATES

    View Slide

  40. Size of the software!
    The biggest contributor to
    project effort and schedule.

    View Slide

  41. As size increases, effort
    goes up exponentially.
    Exponentially. Not linearly.

    View Slide

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

    View Slide


  43. COCOMO-2 software
    estimation model.

    View Slide

  44. IMPROVING
    YOUR ESTIMATES

    View Slide


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

    View Slide

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

    View Slide

  47. STORY POINTS.
    (for e.g.
    A team using 1/2/3 points
    for a project.)

    View Slide

  48. STORY POINTS.
    A junior engineer takes
    5 days to finish a 3-point
    task.

    View Slide

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

    View Slide

  50. The time taken is
    different.
    But the complexity is
    similar!

    View Slide

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

    View Slide

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

    View Slide

  53. COMPLEX?
    Allow Blood Pressure
    measurements to be
    deleted

    View Slide


  54. The Law
    of Large Numbers

    View Slide

  55. “If you create one Big
    Estimate, your error(s) will
    either be completely on the
    high side, or the low side”

    View Slide

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

    View Slide

  57. “… so the errors will
    cancel each other out,
    to some extent.”

    View Slide

  58. COMPLEX?
    Allow Blood Pressure
    measurements to be
    deleted

    View Slide

  59. View Slide

  60. ALSO COMPLEX
    Sync Protocol Drugs
    across all facilities and
    display in the app

    View Slide

  61. View Slide


  62. Some tricks!

    View Slide

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

    View Slide

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

    View Slide

  65. TRICKS!
    Compare different stories
    of similar complexity.

    View Slide

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

    View Slide

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

    View Slide

  68. TRICKS!
    Look at past data for your
    team, for similar type of
    work.

    View Slide

  69. TRICKS!
    Measure yourself
    privately

    View Slide

  70. NEGOTIATIONS
    & AGREEMENTS

    View Slide


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

    View Slide


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

    View Slide


  73. The goal of estimation is
    NOT pinpoint accuracy!

    View Slide


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

    View Slide


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

    View Slide

  76. VALUE EFFORT
    A: S M
    B: M S
    C: S L
    D: XL M

    View Slide


  77. Separate people from the
    problem.

    View Slide


  78. Focus on interests, not on
    positions.

    View Slide


  79. Come up with options
    that benefit everyone.

    View Slide


  80. Either everyone wins,
    or everyone loses.

    View Slide


  81. GO FORTH
    AND ESTIMATE!

    View Slide