I find the whole thing with task estimation is largely masturbative. The reality is that the only thing you have to decide is whether the task is worth doing or not. If it is, then it needs to be done correctly, and that means it’ll take as long as it takes to finish. You can’t just cut corners on a feature for the sake of a timeline. Realistically, deciding on what tasks are a priority should be the main focus of planning. You pick the tasks that are most urgent, and then you work on them till they’re done.

Furthermore, there are broadly two types of tasks. First, is something you’ve done before using the same tools. For that sort of task you can give a relatively accurate estimate. However, any task where you’re doing something new, or using a different tool such as a new framework, library, etc., then all best are off. Even if the task is simple conceptually, it can take a long time because there will be some weird quirk in the libraries, or how they interface together, or a million other things that can go wrong. Best you can do here is to do a research spike that’s time boxed to get a feel for how long the task will take.

The problem is that management gets really obsessive with trying to fit work into whatever timelines are pushed onto them from up top. So they end up forcing developers to commit to some arbitrary numbers that are largely pulled out of your ass, and then either projects run overtime or they’re delivered with lots of bugs because the timeline was completely unreasonable.