Simplifying Software Estimation

Presented at GDG MAD in July 2020.

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