I think the typical software development group (team, department, …) has many more urgent matters to attend to than forecasting when tasks will be done. I don’t think it’s a bad idea to try to forecast more accurately; I merely believe that most organizations, most of the time, would benefit more from addressing other issues and letting this particular issue be as it is.

At the same time, almost everyone all the time wants to know when it’ll be done, for all kinds of meanings of “it”. And it therefore seems reasonable and urgent to try to forecast more accurately. This is merely a trick that the brain plays on us. We would have to train ourselves to resist the temptation to act on this source of false urgency.

I urge you not to bother trying to forecast the cost of tasks, even features, more accurately, but instead to work on other ways to improve. I can help you figure out what to focus on in your context, but maybe you’d rather start doing that on your own. In that case, start with the question of what’s interfering with delivering value to customers, then start chipping away at those obstacles. What’s valuable and when is it well and truly finally delivered? As you deliver more value to more paying customers, you’ll have more resources (including cash!) with which to figure out where to improve next. There’s more to it, but that’s a particularly helpful place to start (on average).

And if you insist on trying to forecast costs more accurately, then read Mike Bowler’s recent article on the topic.