I have started a role where the team lead asked me the estimations, and I told him 2-3hrs as the team lead expects me to finish it faster as I am experienced. But I am bogged down by many issues such as slow virtual machines, and inexperience with the codebase. The expectations set by the team lead is making me stressed out and I can't figure out how to do it within 2-3 hrs. What should I do to handle such cases in future?
When someone asks you for an estimation do not mirror their expectations. This is your first mistake, because now you have painted yourself in a corner where not fulfilling the estimation is your personal fault.
If someone asks you for your estimation, give a truthful estimation. And truthful means include things that can go wrong, do not just assume everything works as expected. If you don't know, because you have never done it before, say so. Even "I don't know" is a good estimation, as long as it followed by "I would need to do X to figure it out".
If your truthful estimation is higher than the team lead expects, you will have a conversation about this automatically. They will ask. Maybe they will just raise an eyebrow. Then you can explain what you would need to finish sooner. Some of those issues will be easy to fix, some you may have to include in your calculations for longer. But there will be communication and even if the team lead thinks you are too slow, they can plan with that. Compared to you just totally blowing your own unrealistic deadline, which is hard to plan with.
If you lie in your own estimation to make someone happy, you only set yourself up for failure. And if you lied in the first place then that failure is yours alone, no matter what the actual problem is in that project.
Good estimates take time. Each time you're asked for an estimate, ask for some small amount of time (1 hour) to develop the estimate. Also ask if they'd prefer you start immediately, or if the estimate is required.
Estimating is a task. Like all tasks, it takes effort. You can't decide how much time a bug fix will take without spending some time to know the bug's impact; and, analyzing how many items you'd have to change to possibly fix the bug.
When faced with someone doubting my estimates, I always found it helps to dig in deeper and give more detailed estimates. (In your case, the first 2-3 sub tasks would probably revolve around checking out the existing code, reading the documentation, and/or talking to someone who's worked with this part of code before.)
This has a few advantages:
- It forces you to reevaluate your own estimates. ("Oh, right. Doing B already solves sub-problem E, so I don't have to count it again when I do E.")
- It proves you've done the work rather than just come up with a random number.
- It makes it harder to argue against the details. (1 day here and a few hours there are much harder to try and talk down than the summed up estimate.)
You can also point out that, the next time you'll do a similar task, when you know the system, you'll be able to do much faster. But this time, you'll have to be a bit more careful, so you can learn about the system and not accidentally break something.