Story points or hour bands: estimating agency work

A story point is a statement about relative size. This piece of work is about twice the one we did last sprint. It says nothing about calendar time until you multiply it by measured velocity.

An hour band is a statement about cost and commitment. This will take between forty and sixty hours, assuming these things are true.

Confusing them produces the classic failure: a client hears "eight points" as "eight days", or a team converts hours to points by dividing, which discards the only property points have.

Estimating relative size is a thing humans do reasonably well. Estimating absolute duration is a thing humans do badly, consistently, and with confidence.

Points also decouple the estimate from who does the work. A task is the same size whether your fastest developer or your newest one picks it up; velocity absorbs the difference over a few sprints.

The catch is that points are meaningless without measured velocity, and velocity takes two or three sprints to establish. A team quoting points before that has a vocabulary, not an estimation method.

Fibonacci spacing exists because precision is false at larger sizes. The gap between 8 and 13 reflects genuine uncertainty; a 10 or 11 pretends to a confidence nobody has.

A client cannot fund a point. They can fund a range with stated assumptions, and they can decide against a range that is too wide.

Bands also make the uncertainty visible, which is the honest position. A single number implies a confidence that almost never exists on technical work, and it gets treated as a commitment regardless of the caveats attached verbally.

The essential part is the assumptions. A band without written assumptions is a number that will be renegotiated the first time content arrives late or feedback comes from three stakeholders separately.

The fourth row is the one that saves the most money. Where a line of work has no precedent, do not buffer it — carve it out as a separate discovery phase with its own small fixed fee.

Clients accept "we will spend two days establishing this, then price it" far more readily than a large number with no visible basis. Buffers, by contrast, get negotiated away first because they look like padding — which removes the cover and leaves the risk.

Decompose the work until each line resembles something the team has actually done. Estimate those lines in points for sequencing. Convert to hours through measured velocity for the commercial conversation, and state the assumptions the conversion depends on.

Keep the conversion one-directional. Points to hours through velocity is a calculation. Hours to points by division is a habit that destroys the only useful property points have.

Then hold the line in delivery. A written change record — what changed, the effort delta, the decision — sent the same day, with the option to absorb, defer or re-price. Most agencies have a change control clause and have never issued a change order, which is where fixed-fee margin actually goes.

If the same estimate is wrong the same way twice, the problem is not the technique. It is that retrospectives are not happening, so nothing is being learned from the variance.

If nobody can say where a fixed-fee project went over, the problem is that work was not decomposed finely enough to locate the overrun.

If estimates are produced by whoever sold the work rather than whoever will build it, no technique will help. That is a delivery structure problem, and it is the gap a fractional technical project manager is brought in to close — the role, described as a job rather than a title.

A clinical research organisation had a related version of this: the development team understood the target state and could not express it as a plan their VP sponsor could fund or track. Decomposing the program into 159 tracked work items with acceptance criteria, sequenced with dependencies made explicit, is what made it fundable — the estimate was downstream of the decomposition, not a substitute for it.