• jvisick@programming.dev
    link
    fedilink
    arrow-up
    11
    ·
    edit-2
    1 year ago

    My favorite approach I’ve seen is just units of time -“this task will take a few [days/weeks/months/years]”.

    No specific number. Instead, the scale of the task is measured in one of those units and I can give you an estimate but it’s just a guess.

    If it’s task that might take “a few days”, it could be done tomorrow or it could take 5 days. If it’s one that takes “a few weeks”, it might be done next week or maybe next month.

    • atheken@programming.dev
      link
      fedilink
      arrow-up
      8
      ·
      edit-2
      1 year ago

      Breaking larger tasks down effectively removes uncertainty.

      My general rule of thumb in planning is that any task that is estimated for longer than 1 day should be broken up.

      Longer than one day communicates that the person doing the estimate knows it’s a large task, but not super clear about the details. It also puts a boundary around how long someone waits before trying to re-scope:

      A task that was expected to take one week, but ends up going 2x is a slide of a week, but a task that is estimated at one day but takes 3x before re-scope is a loss of 2 days.

      You can pick up one or two days, but probably not one or two weeks.