AriesDevs engineering team Engineering notes
4 min read
A single-number estimate is a polite fiction. "Twelve weeks" sounds precise, but it hides everything the team does not know yet. When the real figure turns out to be fifteen, the number becomes a broken promise, even though the original guess was reasonable. We quote ranges, not single numbers.
What a range actually says
When we quote "10 to 15 weeks", we mean there is roughly a one in ten chance of finishing earlier, and a one in ten chance of finishing later. The width of the range is information. A narrow range means the scope is well understood. A wide one means there are decisions or unknowns the client and we should deal with first.
This changes the conversation. Instead of negotiating the number down, we ask what would make the range narrower. Usually the answer is something concrete: access to a third-party API sandbox, a decision about which payment providers to support, a sample of the data to be migrated.
The estimation workshop
Every estimate starts with a two-hour session with the people who will build the work: an engineer, a designer, a tester and someone from delivery. The client joins for the first half to explain goals and constraints. We then break the work into pieces small enough to reason about, usually 20 to 40 of them, and for each piece we record three values.
- Best case: it goes smoothly and nothing surprising shows up.
- Likely case: the number each person would bet on.
- Worst reasonable case: something goes wrong that has gone wrong before, but not a disaster.
Large gaps between best and worst point at risk. We then spend the remaining time on the five items with the widest gaps and ask what we would need to know to shrink them.
Write the assumptions down
Each estimate comes with a list of assumptions, written in plain language and numbered. Examples: "The client supplies final designs for all screens before sprint 2." "The existing API returns consistent error codes." "Single sign-on uses the client's identity provider with standard configuration." There are normally between 10 and 25.
The list does two jobs. It tells the client what the range depends on, and it gives us a clean way to talk about change. When an assumption turns out to be false, we do not argue about whose fault it is. We point at assumption 14, show what it was worth, and adjust the range together.
Track the range, not just the burn-down
After kickoff, we update the range at the end of every sprint. As work completes, the uncertainty falls, and the range should narrow towards a single date. If it is not narrowing, that is the earliest warning sign we have, and it appears weeks before a missed milestone would.
We also recommend recording the outcome of every estimate in a shared sheet: the range given, the actual result, and which assumptions broke. After enough projects this shows where a team is consistently optimistic. Integrations with third-party systems and data migration are the usual offenders, so add a standing buffer to both.
The goal of an estimate is not to be right. It is to make the next decision better.
What to ask any vendor
If you are comparing quotes, ask three questions. What is the range, and what is the likelihood of landing outside it? Which assumptions does it rest on? How often will the estimate be updated, and what happens when it moves? A vendor who answers clearly is probably going to manage your project the same way.
