Software Estimation Without Lying to Yourself
A practical way to estimate timelines and scope when requirements are uncertain — without fake precision.
Estimation is hard because you are forecasting discovery work. The mistake is pretending you can eliminate uncertainty with a single date. Here is how teams estimate in a way that supports planning, sets expectations, and still leaves room for reality.
Estimate ranges, not points
Point estimates are comforting but fragile. Ranges are honest. Start with “best case / likely / worst case” and communicate what drives the spread.
The range narrows as you learn. That is the whole point — estimation should evolve with evidence, not lock you into a number you made up early.
Separate “build” from “figure out”
Many tickets mix implementation and discovery. When you split them, timelines become clearer and stakeholders understand what they are paying for: learning or building.
Discovery has a different failure mode. You can timebox it and still succeed even if the answer is “do not build this yet.”
Use milestones that produce decisions
Better than “50% done” is a milestone that unblocks a decision: API shape confirmed, data model stable, performance baseline measured, rollout plan defined.
Decision milestones let non-engineers track progress without reading code. They also reduce last-minute surprises.
Protect engineering time with scope rules
Agree on what changes the schedule: new user roles, new integrations, new data sources, new compliance requirements. These are not “small tweaks.”
When everyone shares the same scope rules, negotiations are faster and less emotional.
If you need a delivery plan that leadership can trust (and engineers can actually hit), we can help you scope, estimate, and execute with tight feedback loops.
Get in touch