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

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.

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:

• "How can I get better at estimating long-term projects?"
• "How can I be better at executing on my work when it comes to coding and breaking down ambiguity?"

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