Estimating requires experience, lots of it, and even then, the gap between the estimates and the final time can be huge.
Asking a freshly-graduated teammate to estimate is a huge failure on the part of the organization. I'd advise to push back on this. My personal feeling is that it's a sign of a dysfunctional organization and it's just the tip of the iceberg.
Multiply your own estimates by Pi (3.14). It ensures you always overdeliver and underpromise. People are only angry if you promise something you cannot keep. If you multiple your own estimates by Pi, you're 95% likely of being able to deliver below expectations ... ;)
I'd also add that it's much easier to estimate small things than big things.
If your estimate is longer than 5 days, then break it up into parts until all your estimates are under 5 days.
Yet another tip: design your UI first, then make your estimate. Estimates become a LOT more certain once you've defined the UI (look up cone of uncertainty for a graphical explanation).
This isn't entirely true for many projects. Developer management doesn't get angry if you over-estimate your work, sure, especially in a dysfunctional company where the development team doesn't care about the business side. Everybody who interacts with the outside world, though, and might need things done to beat competition or have releases available for key events get extremely angry when told to put off their big announcements, and then find out that their original deadline would have worked. Or worse, it means that projects get cancelled, because yours will take too long to help the overall strategy.
I just graduated and started my first job as a developer. The thought of having to provide accurate estimates for my work seems really intimidating 😬
Estimating requires experience, lots of it, and even then, the gap between the estimates and the final time can be huge.
Asking a freshly-graduated teammate to estimate is a huge failure on the part of the organization. I'd advise to push back on this. My personal feeling is that it's a sign of a dysfunctional organization and it's just the tip of the iceberg.
Multiply your own estimates by Pi (3.14). It ensures you always overdeliver and underpromise. People are only angry if you promise something you cannot keep. If you multiple your own estimates by Pi, you're 95% likely of being able to deliver below expectations ... ;)
I'd also add that it's much easier to estimate small things than big things.
If your estimate is longer than 5 days, then break it up into parts until all your estimates are under 5 days.
Yet another tip: design your UI first, then make your estimate. Estimates become a LOT more certain once you've defined the UI (look up cone of uncertainty for a graphical explanation).
This isn't entirely true for many projects. Developer management doesn't get angry if you over-estimate your work, sure, especially in a dysfunctional company where the development team doesn't care about the business side. Everybody who interacts with the outside world, though, and might need things done to beat competition or have releases available for key events get extremely angry when told to put off their big announcements, and then find out that their original deadline would have worked. Or worse, it means that projects get cancelled, because yours will take too long to help the overall strategy.
I've found it enough of a mess at every company that I wrote a post describing what I've done for fairly solid estimates.
How Long Will That Project Take?
John Colagioia (he/him) ・ Jan 28 '21 ・ 10 min read
It takes time itself, but I find that it's worth it to consistently hit the target.