Why is it so hard to give a fixed price for a software project? Because you're estimating the unknown. Here's how Scrum handles this honestly — and how to explain it to a client.
Estimating a software project is one of the most perilous exercises in the industry. You're asking experts to estimate the duration and cost of something they've never done in exactly that way before. The planning fallacy, documented by Kahneman and Tversky, shows that individuals systematically underestimate the duration of complex tasks — even having lived through similar past experiences.
The cone of uncertainty
Barry Boehm formalised the cone of uncertainty: at the start of a project, the estimate can vary by ±400%. At the midpoint, ±25%. At delivery, uncertainty drops to zero — because it's done. This isn't incompetence: it's the nature of design work. Promising a precise estimate at the start of a project means pretending the cone doesn't exist.
Relative estimation and story points
Scrum addresses this challenge with relative estimation. Rather than saying "this feature will take 3 days", you compare features to each other: "this one is twice as complex as that one". Story points capture this relativity. Planning Poker forces each developer to vote independently, revealing disagreements that hide misunderstandings or risks. The ensuing discussion is more valuable than the number itself.
Fixed price vs Time & Material
A fixed-price contract gives the client budget certainty but transfers uncertainty onto scope and quality. A Time & Material contract is more honest about what can be promised, but requires trust and transparency. The best approach: a fixed appetite (Shape Up) — "here's what we can do with this budget in this timeframe" — letting the team optimise delivered value within the constraint.
How to explain this to a client
A software project is more like writing a book than building a wall. You don't know how many pages the book will be until you've written it. The right question isn't "how much does it cost?" but "what value can be delivered with this budget?" Scrum structures this conversation sprint by sprint, with real deliverables at each iteration.