Estimating isn't guessing: it's a collective exercise in reducing uncertainty. Here are the principles and techniques we've learned for building a reliable process.
There's a dynamic anyone who works on software projects knows well: the estimation meeting that turns into a negotiation. On one side, the people who need numbers to make an offer or plan a roadmap; on the other, the delivery team, who know those numbers are fundamentally uncertain and say so, sometimes with an "I'm just making the numbers up anyway" that shuts the discussion down before it even starts.
It's not cynicism: it's the rational response of someone who perceives the process as a "contract" dressed up as a method. The numbers turn into commitments, uncertainty gets read as incompetence, and the people doing the estimating end up having to "sell" a figure instead of reasoning through a problem.
For me, coming from design, estimation was always uncharted territory, something the more experienced PMs knew how to handle. It was talking to them at Buildo that made me understand it was mainly a problem of method, and that there was no absolute answer. From there, the curiosity and the need to dig deeper took over. Two books were recommended to me right away, books many people probably already know: Software Estimation: Demystifying the Black Art by Steve McConnell and How to Measure Anything by Douglas Hubbard. A light came on for me about something I'd taken for granted as inevitably opaque.
What follows gathers the things that, through reading and trying, made a real difference for us. Some come from the books; others we figured out in the field: reflections on how to frame the problem, concrete techniques to bring into meetings, and a few thoughts on what changes when you start to have historical data to lean on. You won't find a definitive answer here on how to estimate, but you will find a few more tools to face the moment with more method and less stress.
The starting point of almost all the literature on the topic, which McConnell repeats many times, is a distinction that sounds obvious but in practice gets ignored constantly: an estimate is not a commitment.
An estimate is a prediction based on the information available at a given moment. A commitment is a promise of a result. Confusing the two creates a perverse effect: the team learns to underestimate so as not to seem incompetent, or so as not to disappoint expectations, and whoever receives the estimate uses it as a fixed deadline. When reality turns out to be different (which is to say, always), frustration and mistrust set in.
One thing that helped us was making this distinction explicit before we even start talking about numbers. Not "how long will it take?" but "what do we know today, and how uncertain are we about what we don't yet know?" Changing the question changes the climate of the meeting: people stop defending a number and start reasoning together about a problem.
Hubbard redefines measurement in a way that initially sounds philosophical but turns out to be very practical: measuring doesn't mean finding the exact answer, it means quantitatively reducing uncertainty. You don't have to know how long it will take. You just have to know a little more than you did before.
This changes the question you ask in an estimation meeting. Instead of "What's the right number?", the question becomes "what would make us more certain about what we're estimating?" Sometimes the answer is a technical spike. Sometimes it's pulling data from a similar project. Sometimes it's simply breaking down the scope better.
The point is that uncertainty isn't a problem to hide or pretend you don't have: it's the most useful piece of information you can bring into a meeting.
One of the most useful insights we found in Hubbard is this: the data needed to estimate better is almost always more accessible than we think. It's in the timesheets of past projects, in the WBSs, in Jira tracking, in the team's memory.
The problem isn't (always) a lack of evidence: it's that we aren't used to looking for it before estimating. Individual intuition is faster and less uncomfortable than a reality check. But it's also far less reliable. Moving from intuition to the question "what does this resemble, among things we've already done?" is one of the most useful shifts you can make.
Estimates get more accurate the more granular they are. A big feature is almost impossible to estimate well. The same total hours, distributed across ten sub-tasks, get estimated much better, because the act of breaking it down forces you to understand what you're really estimating. It's often in this step that the bits of work nobody had considered come out: "Who does the code review?" "Is there documentation to update?" "Does this need an alignment with the design team?"
There's a side effect worth naming, though: when you break things down well, the numbers tend to grow. It's an effect of the minimum-estimate bias: we tend never to drop below a certain threshold for a single task, however small it is. When those thresholds get multiplied across all the sub-tasks, the total climbs. It isn't something to ignore or correct upstream, but it is something the PM needs to keep in mind when refining the final estimates before taking them outside.
One thing that changed how we run our meetings was no longer treating divergences as a problem to solve quickly. If someone estimates 4 hours and someone else 20, taking the average and moving on is the fastest path, but almost always the least useful one.
Discrepancies are information. They signal that two people understood different scopes, are aware of different risks, or have different experience with that technology. The right question is: "What did you each see differently?" The conversation that follows is almost always the one that leads to the most useful estimate, and it surfaces implicit assumptions that would otherwise stay hidden until halfway through the project.
Before getting into the estimation itself, it can be worth doing a quick exercise: imagine the project is already over and things went badly. Ask the team, "What happened?" Freeing the mind from mandatory optimism (the kind that leads you to estimate the best-case scenario as if it were the likely one) lets us surface the risks no one wants to name out loud. And if those risks influence the estimates, better to know up front.
Estimates need to be revised as the project moves forward. Not because the first ones were wrong, but because as the work progresses, information accumulates that simply didn't exist at the start.
An estimate made at the proposal stage is based on a certain level of scope knowledge. An estimate made midway through the project is based on something far more solid. Expecting the first one to hold all the way to the end means ignoring everything we've learned about the project in the meantime. One of the first things I understood working alongside the PMs at Buildo is that re-estimates are an integral part of the estimation facilitation process, something that doesn't end with the first meeting. Of course, that doesn't mean redoing everything from scratch every iteration: the idea is to focus only on the tasks where new information has surfaced (a requirement that's been clarified, a risk that's materialized, a scope that's changed, or even just having gotten your hands directly on it). Selective re-estimates keep meetings lean and don't load up the week with a ritual that ends up feeling bureaucratic.
How do you actually run estimates in a meeting? There are several formats that help structure the moment, each with its own strengths and ideal use cases. There's no single answer: the most useful thing is to know them and pick the one most suited to the project, the team's maturity, and the phase you're in. Here I'll suggest two we still use at Buildo and find very effective, plus a small bonus: a cross-cutting technique I've found particularly useful, which you can apply inside any format to bring out estimates independently and free of bias.
T-shirt sizing is useful when you want to get the order of magnitude of a set of features before even discussing hours or days, or even instead of hours and days altogether. The idea is simple: instead of assigning numbers, you assign a size (XS, S, M, L, XL), reasoning in terms of relative complexity. Is this feature bigger or smaller than that one? Is it an L or an XL?
The value of this approach isn't in its precision, but in alignment and the ability to handle uncertainty honestly. In the early phases of a project, when information is still scarce, faking numerical precision ends up hiding the uncertainty. Using sizes is a way of explicitly acknowledging that the level of knowledge doesn't yet allow precise numbers, and proceeding in a structured way anyway. Before using sizes, the team needs to agree on what "big" or "small" means in that specific context (as in all estimation meetings, setting common rules at the start is essential). Making this collective calibration explicit prevents everyone from using a different ruler.
It works well in the early phases of a project, when information is still scarce and faking numerical precision would be misleading. But it works just as well in sprint planning: it's fast, easy for the whole team to grasp, and has the advantage of removing the tension that often comes with numbers. When the discussion isn't "8 hours or 12 hours" but "is it an M or an L?", the climate of the meeting changes, and you get to a shared estimate with less friction.
The evidence-based approach starts with a critique of how estimates usually get made: we look at a new feature and ask, "how long will it take?" The result is numbers based on feelings and personal knowledge, hard to justify and easy to challenge, and, above all, that don't really frame the uncertainty and complexity in front of us, but rather sweep them under the rug.
The fundamental difference of this method is that you compare with things you've already done. Instead of asking yourself "how long will it take?", the question becomes "what does this resemble in our history?" If we built a similar feature last year in 35 hours, and this one is slightly more complex but not radically different, we can reason from there and not invent a number. Anchoring the estimate to something real helps quantify the unknown and make it manageable with actionable interventions: I know this feature looks like something that took us three weeks, and I know how much that estimate had deviated from reality.
There's an aspect that can seem counterintuitive at first: the unit of measure doesn't matter. We could use hours, days, story points, or any other unit. What matters is the consistency of the comparison: if feature A is worth "5" and feature B is twice as complex, then it's worth "10". The relationship between the numbers is what makes them useful, not the number itself. Why? Because what you're really measuring isn't "exactly how many hours it'll take," but how far you are from the unknown, and that's measured by comparison, not in absolute terms.
At Buildo we've started building an archive of historical data (WBSs of past projects, feature tracking, actual time logs) and using it as a basis for comparison in meetings. It's an approach that requires an initial investment: data has to be collected and structured, and it takes time before the archive is rich enough to be useful. But once comparison with real data becomes possible, the dynamic of the meeting changes too: it's harder to dispute evidence than an impression, and that reduces the tension that often characterizes these moments.
After taking a moment to align on the scope to be estimated, each member of the team secretly and silently assigns a value to the feature (hours, days, ranges, sizes…) and, on cue, everyone reveals their estimate at the same time. As mentioned before, the goal isn't to take the average: it's to understand why the person who estimated 4 hours and the one who estimated 16 saw different things.
The mechanism of simultaneous reveal serves to reduce anchoring bias: that effect where the first number said in a room influences all the ones that follow. If the cards are revealed together, there's no anchor, and each person brings their own independent reading of the problem.
In practice, Planning Poker works best when divergences are large. If everyone estimates roughly the same thing, you can move on. If one person estimates 2 and another 13, that distance is the signal worth exploring: it almost always hides an implicit assumption about the scope, a technical dependency one person knows about and another doesn't, or a piece of work that not everyone had considered. The final number is almost secondary compared to the conversation it opens up.
Back to the developer making numbers up: the problem, almost always, isn't a lack of competence. It's the lack of a process that turns the estimate into something other than a personal opinion under pressure.
What we've learned from both the literature and our practice is that estimates become more reliable when they become a collective exercise in reducing uncertainty. When the team doesn't have to "know" the right answer, but reason together with the data they have.
The number is still there in the end. But it's the result of a process, not the point people fight over.
Steve McConnell, Software Estimation: Demystifying the Black Art (Microsoft Press, 2006)
Douglas Hubbard, How to Measure Anything (Wiley, 2014)
Giorgia is a designer at Buildo, specializing in UX and Research in the healthcare sector and innovative technologies. She has refined her skills in product design, project management, and facilitation, driven by both curiosity and a desire to continuously improve as a designer.
Are you searching for a reliable partner to develop your tailor-made software solution? We'd love to chat with you and learn more about your project.
