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?
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.
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
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:
I recommend these other discussions as well: