I’m into tech as a software engineer since 2022, and one thing I remember was estimation rounds in my first refinement meeting. In Agile methodologies, there is practice to estimate development tasks in PD’s (person days) or story points, t-shirt sizes, and so on… One is better than the other, but it’s not relevant for this blog post, so let’s proceed…

As a new joiner, you could feel awkward about your estimation on ticket because you don’t have a know-how of the code base or module inside the project.  Sometimes management can make you feel like you are committed to an estimated time, which shouldn’t be like that! If you are feeling uncomfortable, I suggest you skip the first two meetings where the team estimates the tasks. Observe how team do it, along with the discussion they’re developing while bringing their opinions on the topic. Just be honest and speak up. The team should understand it. They have been there too. If there is no such option and maybe there are 2 developers at the time, then I suggest the following:

Take the time to look into the tickets before the meeting

The tickets for estimation should be ready, which means, there should be proper description about the feature with relevant background information. Also, if there are some designs or screenshots, they should be attached to the tickets. If there is no such a thing, then “Definition of ready” document should be in place. Again, this is different topic worth another blog post. You should request tickets which are ready for estimation from product owner or scrum master. Try to make short static code analysis what are the main components in that feature or if it’s connected to some other feature. Ping other developer and discuss the tickets.

Be pesimistic

I don’t say this often, but here it makes sense. Try to find all the thing which are wrong in the ticket description, design, some bottle necks in the code base and force your mind to find something. With this approach you will gain better understanding how things work and also give more realistic estimate. Even if your colleagues say something will take 4h to finish the task, if you see holes in the design, slap higher estimate and bring discussion up. Those things are highly appreciated.

Listen carefully

Some of those meetings can become boring, especially when some “bikesheding” discussions are happening and you multitask while on meeting. Don’t do this, politely stop non relevant discussion and bring the topic back on track. Also, listen to more senior engineer how they communicate and how they discuss complex topic, note down unknown topics which you can explore later.

It's just an estimation

Slapping some ridiculous number for an estimation is common thing and will happen. Most of the time you’ll be asked why your estimation should be relevant. Just explain your thought process at the moment, nobody will judge you for that because you can bring some good points and change others people opinion about their estimates. At the end of the day, it’s just an estimation and not a commitment to the work. You are not promising the delivery, you are estimating effort.