What do you do if your time estimation skills as an application developer are causing missed deadlines?

I will start by critically analyzing past projects to identify patterns or common tasks where my estimations were off. I'll then seek feedback from more experienced developers on how they estimate time for similar tasks and incorporate their strategies. To improve accuracy, I'll break down my work into smaller, more manageable tasks, estimating time for each and adding buffer periods for unforeseen challenges. Implementing a time-tracking tool will help me better understand how long tasks take versus my initial estimations. I'll also continuously refine my estimation skills by comparing actual task durations against my predictions, learning from discrepancies.

If you are an application developer, having challenges with accurate estimates, whereby causing missed delivery deadlines, I will suggest you work with your Iteration manager or Scrum master, to do the following: - identify the lower and higher range of the number of stories you've completed during past iterations and make projections using the lower range. - find the average of the numbers of stories you've completed in the past 3 iterations. That should give you a more accurate estimate, that can be used for future estimation.

One should always acknowledge their mistakes in that thought that they will try to learn from that and avoid repeating the same next time. As whenever we provide our estimation we might miss some of the external factor dependency or not checking with the respective teams resulting into project delays and missing deadlines. But doing such checks with co-worker one could understand where did they go wrong and what could have been done in such situations.

Check if tasks are more abstract at activity level, if so use task decomposition technique to identify all steps needed to accomplish it. Estimating actionable lower level tasks are more effective than estimating the abstract higher level tasks.

Estimation review should be mandated in retrospective sessions as part of continuous improvement. Identify patterns or common themes for underestimation. Practice kaizen for small and continuous improvements to estimation practices over time

It is normal that estimations are not always met. There are always factors that can cause struggles during development. Accepting this reality can be helpful in discussing and analyzing the topic. The focus should not be solely on achieving "on point" estimations, but rather on reducing the range of variations. During your retrospective, it is important to examine the data (lead and/or cycletime) and identify tasks that fall outside the normal range. Some tasks may take less time than estimated, while others may take significantly longer. By working together, the team can aim to improve task estimation and create tasks that align better with their range.

If the project has extreme volatility due to "Unknown Unknowns", its better to add a factor of safety for "unknown unknowns" that are unforeseeable or impossible to anticipate as they cant be planned or anticipated in advance