2

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?

4
  • @Kilisi I was forced to reduce my estimations. I get your point regarding credibility, but the main point I want to address is when the lead doesn't agree with my expectations and expects me to finish something really fast, just coz of my experience tag, which is not justified. – cixerit231 Jan 18 at 15:00
  • Regarding the slow virtual machines, do your colleagues face similar problems? Does the team lead? – Llewellyn Jan 18 at 18:39
  • No, they work on their own machines. – cixerit231 Jan 19 at 7:42
  • 1
    Does this answer your question? How to deal with unrealistic deadlines as an intern in a startup? – Fattie Jan 19 at 17:04
11

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.

5
  • This answer could be improved by adding how the OP can handle the current 'I estimated it, but I won't be able to do it" situation. – Erik Jan 18 at 7:07
  • @nvoigt thanks for the answer. Well, for some strange there is some sort of cheap tactics being used to undermine my mental state, I tried to resort to the correct estimations earlier, but the lead often taunts me saying you are senior/experienced and it can't take lesser hours for you. Its been just a few weeks, and the expectations are highly unreasonable and doesn't do justice, just coz I am senior doesn't mean I know the project inside out. – cixerit231 Jan 18 at 14:57
  • Giving in is never the correct response. With unreasonable expectations, ask who can do it inside the given constraints and ask to be paired with them to learn how to do it yourself. Two things can happen: you can either find an ally that confirms the expectations are unreasonable... or you can learn from them how to do it. – nvoigt Jan 18 at 15:07
  • @nvoigt I agree with you of not giving in, I tried to reason out the following things. I told him I need some more time to do it, and but he taunts me saying a senior would take x hours to do it. Well I replied, I am still getting used to the project, he sarcastically says we don't pay you to learn. Estimations are basically approximations, I might encounter blocker which might ruin the estimations totally. For e.g My virtual machine assigned is really damn slow. – cixerit231 Jan 18 at 18:03
  • Besides that all the Dev's are really busy coz they need to meet their deadlines. I tried asking someone to help and they don't know how to do it either – cixerit231 Jan 18 at 18:11
2

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.

2
  • I understand what you mention, in fact I had estimated everything. But the lead didnt agree with my estimations and said I am taking more than usual time. I took time and estimated all my tasks, but I am being questioned for my estimations and being asked to speed up. – cixerit231 Jan 18 at 18:09
  • @cixerit231 If the lead disagrees with your estimate, permit the lead to disagree. Don't argue with them; but, don't alter your estimate either. Just say "I think it takes this long, and <lead programmer> thinks it takes this long" Estimates aren't accurate, often being off by half to twice the actual effort. It's not worth it to get into a discussion about which estimate is correct. – Edwin Buck Jan 22 at 5:40
1

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:

  1. 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.")
  2. It proves you've done the work rather than just come up with a random number.
  3. 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .