27

How to do better estimation of task time length for sprint planning?

Profile picture
Entry-Level Software Engineer [SDE 1] at Amazon2 years ago

When working on a new task, I often find myself asked to estimate how long a task may take. Luckily, my team is pretty forgiving, but a critical step will be to start more accurately estimating tasks.

How do you get better at breaking down tasks to understand what needs to get done, and then giving proper estimations for how long those tasks will take?

758
3

Discussion

(3 comments)
  • 18
    Profile picture
    Mid-Level Software Engineer at TikTok
    a year ago

    You’ll get better at estimating things as you build more experience on the system. Until you get there, I would suggest this equation:

    If you have done similar thing before: just give that number if you’ve done it before.

    If you have not done it before: Set up an investigation work ticket. Let the task estimation itself be the task, and drive the design and investigation first, then estimation comes in. As for how much an estimation should take… just x2 on how long you think you will take. E.g if you think it will take 2 days give it 4.

    • multiplier can decrease as your task estimation skill increases ( better overall knowledge around the context ) - basically have the multiplier be in the inverse relationship in relation to your confidence level.
  • 12
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    How do you get better at breaking down tasks to understand what needs to get done...

    This is where real system design comes in: Push to understand the step-by-step product flow - From there, you can convert each step into its own task.

    For an in-depth concrete example of breaking down a product flow, check out the discussion here: "How do I make software less overwhelming?"

    After you have broken down the product flow, keep breaking things down until each task is roughly a commit worth of work (2-3 days to do max). From there, you can follow the "One Diff, One Thesis" principle as we talk about here: One Diff, One Thesis - What Every Code Review Should Be Like

    ...and then giving proper estimations for how long those tasks will take?

    Here's my core advice there:

    1. Junior engineer estimates generally need at least 50% of buffer - It can go as high as 100% as Seoyoon described. So if your initial estimate for a task is 4 weeks, it's probably 6 (50% bump) to 8 (100% bump) weeks in reality.
    2. Solicit feedback regularly - A lot of estimation and decomposition does come from "muscle memory" just shipping project after project within your team. To expedite that learning process, leverage your teammates so you can draw on their battle-tested wisdom instead of solely needing to build up that battle experience yourself.

    I recommend these other discussions as well:

  • 8
    Profile picture
    Senior Software Engineer and Career Coach
    a year ago

    I agree with Seoyoon and I'd also add that this can be very team dependent.

    In some teams it may be very easy depending on the process. Everyone might get together estimating things and you have senior people able to give pretty solid estimates.

    However, it's not always the case. To give you a better answer, I'd love to know how your team process works a bit more.

    In the meantime, if it helps, I wrote an article on this very topic that echoes Seoyoon's advice too. It might give some other insights to pick up on: https://careercutler.substack.com/p/how-to-get-estimates-right-95-of