How we estimate software projects

Early in a project, nobody knows exactly how long it will take. Estimates that pretend otherwise create a bad dynamic: the vendor pads the number, the client negotiates it down, and both sides end up arguing about a figure neither believed.

We estimate differently, and we show our working.

Break the work down until it is boring

We split the scope into pieces small enough that an engineer can describe how they would build each one. Anything that can't be described that way is marked as unknown rather than guessed.

Give every piece a range

Each piece gets a low and a high estimate. The gap between them is information: a wide range means we need to learn more before committing.

# excerpt from an estimate sheet
feature                     low   high  confidence
Applicant sign-up             3d     5d   high
Credit bureau integration     8d    20d   low   # API docs not seen yet
Officer dashboard             6d    10d   medium

Write the assumptions down

Every estimate comes with a list of assumptions: which systems we can access, who approves designs, how fast feedback arrives. If an assumption turns out wrong, both sides can see why the plan changed.

Keep the buffer visible

We add a risk buffer based on the low-confidence items and show it as its own line, not hidden inside each task. That makes it a shared decision: you can reduce scope to remove risk, or keep the buffer.

Re-estimate after discovery

The first range is wide on purpose. After a two-week discovery sprint, the unknowns are smaller and we commit to a fixed price for the agreed scope.