Originally published on lavkesh.com
What if we let a machine tell us how much work a software task will be? This is not a hypothetical question for many researchers, and it is becoming less so for engineering teams, too. A review of 66 published studies on software effort estimation, presented at the ICEIS 2025 conference, found machine learning models are now the most tested approach in the literature, ahead of expert-judgment methods like planning poker and t-shirt sizing. The academic world has moved on.
For years, planning poker was the default. It brought the team together, forced discussion, and built a shared understanding of the work. You had engineers talking through dependencies, clarifying acceptance criteria, and arriving at a consensus. This social aspect is undeniably valuable, and it is the main reason many teams still cling to it, even when the estimates themselves prove to be inaccurate more often than not.
The process of gathering everyone, explaining stories, debating, and re-voting takes significant time. Consider a typical sprint planning session: two or three hours for a team of six. That is twelve to eighteen person-hours spent on estimation every two weeks, and for many teams, the numbers they arrive at are often wildly optimistic or pessimistic. The 'expert judgment' often gets swayed by the loudest voice or the person who spoke first, anchoring everyone else.
Machine learning models approach effort estimation from a different angle entirely. They learn from the past. By ingesting historical data - completed tickets, their descriptions, the actual time spent, the engineers who worked on them - these models can identify patterns. Modern approaches, especially those using large language models, can even size a backlog item based on its description text alone, before any human has deeply considered it.
The immediate benefit is speed. Imagine a model pre-populating estimates for hundreds of backlog items in seconds. This shifts the human effort from generating numbers to validating them. Instead of debating every ticket, the team focuses on the ones where the model's confidence is low, or where its estimate seems like an outlier. This is a data-driven approach, not a replacement for human intelligence, but an augmentation of it.
Accuracy is the first challenge. The model is only as good as the data it trains on. If your historical data is messy, inconsistent, or lacks context, the model will reflect that. Furthermore, what happens when you introduce a completely new technology, or a project unlike anything the team has done before? The model will struggle, just as a human would, but perhaps in less predictable ways.
The greater hurdle, though, is trust. Engineers are rightly skeptical of black boxes. They want to understand how a number was derived, not just be handed one. Building trust means providing transparency, allowing engineers to see the factors the model considered, and most importantly, giving them a clear mechanism to override or adjust an estimate. If engineers feel their expertise is being dismissed, they will reject the tool, no matter how statistically accurate it might be.
I have seen teams begin to experiment with this, where the model provides a baseline, and the human conversation then centers on exceptions. The machine provides the first draft, the team provides the critical edit. This way, the team still engages in deep discussion on complex items, but the simpler, more routine tasks are handled quickly and consistently. It moves the judgment call earlier, to deciding which of a model's sizes to trust and which to override.
Embracing machine learning for effort estimation is not about eliminating human input; it is about optimising where that input is most valuable. It is about applying the same data-driven rigor we use for monitoring systems and tracking user behavior to the foundational act of planning our work. We use data to understand our systems; why not use it to understand our own capacity?
If you lead a software team of six, how would you begin building that trust in a model's numbers, without losing the valuable team discussion that planning poker once offered?
Top comments (0)