• OsrsNeedsF2P@lemmy.ml
    link
    fedilink
    arrow-up
    21
    ·
    edit-2
    1 year ago

    At my work, we have P1 and P2 tickets. Ideally you get them all done in a week, but you’re only supposed to have 3 days worth of P1 tickets, so it’s required to have all the P1s done.

    It worked really well for a few weeks. Then the PM started putting 4, 5, I even had one week where I had 9 days worth of P1 tickets assigned.

    I’m growing very tired of this company.

  • SorteKaninA
    link
    fedilink
    arrow-up
    20
    ·
    1 year ago

    I guess it makes somewhat intuitive sense. When I give an estimate, I’m probably more like to say “it’ll take 2 weeks. Maybe less, maybe more” and that maybe/maybe is 50%/50%, which suggests that the estimate is the median, not the mean.

    I like the thinking. I think looking at task uncertainty is much more useful than task size. Task size can easily be managed by breaking it up. Uncertainty can’t be managed in the same way.

    • 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.

      • SorteKaninA
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        1 year ago

        I think that’s neat but I doubt a lot of product managers would like that 😅.

  • Wojwo@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    What happened to estimating the pessimistic, most likely and optimistic times and apply that to a beta distribution? That’s how I was taught back in the dark ages.