We ran a Spec Review recently and came back to the client with an estimate of around $300k, Time and Materials.

Before the work started, the Solution Architect on the job wanted to see what would happen if he handed the project to Claude Code and let it run. Overnight, it got through a substantial amount of the build. Our revised view was that we could finish the job off with roughly $60k of additional work.

Same scope. Same client. Same outcome. A fifth of the invoice.

That is a good result for the client and a genuine problem for the way we sell. It is worth being honest about both.

The link between hours and value has snapped

The old model held together because of a chain of assumptions. Hours were a proxy for effort, effort was a proxy for difficulty, and difficulty was a proxy for value. None of those links were perfect, but they were close enough that billing by the hour felt fair to everybody.

Agentic workflows break the chain in the middle. When an agent runs overnight and a developer spends the morning reviewing what it did, the hours on the timesheet describe the review, not the work. The hardest and most valuable part of that engagement was the architect deciding what to ask for and knowing whether the answer was any good. That took him twenty minutes.

There is also a transparency problem coming. Clients know what these tools cost, because most of them are using them too. A client who pays for a subscription at home is going to ask why the invoice looks the same as it did in 2023.

The market has already noticed

McKinsey now reports that around a quarter of its global fees come from outcome-based arrangements rather than billable hours, with clients increasingly arriving with a result they want rather than a scope they want delivered. BCG has told investors it expects AI-driven work to be about 40% of revenue.

Before we all declare the billable hour dead, one industry estimate puts genuine pay-for-results contracts at under 10% of AI consulting work. Most of what is actually happening is a shift from Time and Materials to fixed price, which is a much smaller change than the headlines suggest.

The demand is running ahead of the supply. Clients are asking to buy outcomes faster than consultancies are offering to sell them, which is not surprising when you look at who carries the risk in each model.

What this does to Agile

This is the part that matters for those of us who have built our delivery practice on Scrum.

Velocity was a measure of capacity

Velocity only ever worked because the team was stable. Ten people this sprint, ten people next sprint, so last sprint’s throughput tells you something useful about the next one. Once a meaningful share of the work is done by agents running at variable speed and variable quality, velocity stops forecasting anything. It becomes a record of what happened rather than a prediction of what will.

Story points might actually survive

Story points are a relative measure of how big and complex a piece of work is, deliberately divorced from how long it takes. That design decision, which used to feel like an academic distinction, is now the thing that saves them.

If a story might take an agent eighteen minutes or three hours of debugging depending on how well it goes, any estimate in hours is a guess. But the story is still the same size relative to the one next to it. My advice is to keep estimating in points and stop trying to convert them to days.

Fixed outcomes pull against adaptive scope

Here is the awkward one. Scrum is built on the premise that the client buys capacity and steers it, sprint by sprint, as they learn what they actually need. The Sprint Review exists precisely so scope can change.

Selling a fixed outcome pulls in the opposite direction. It pushes you back toward a specification agreed months ago, defended by change requests, which is very close to the thing Agile was invented to get away from. I do not think these two ideas reconcile as neatly as the consulting blogs imply, and I would be suspicious of anyone who says they have solved it.

The trade-off nobody mentions

Outcome pricing is not a free upgrade.

• The risk moves to you. Our own rule on Fixed Price vs Time and Materials has always added a 20% premium to fixed price work, on the basis that the consultant is carrying the risk. That premium does not disappear because the tooling improved. If anything the variance is higher now, because agent performance across different problem domains is genuinely hard to predict.
• Your cost base changes shape. The $60k in the story above is not the whole cost. API and token spend is now a real line item, it scales with usage rather than headcount, and it is far less predictable than a salaried developer. That has to be priced in.
• Cash flow gets lumpy. Getting paid on results rather than on effort stretches payment cycles and makes revenue harder to forecast.
• Somebody has to define the outcome. “Working software” is easy to say and hard to write into a contract in a way both parties will still agree on in six months.

Where we’ve landed so far

Not on an answer. We have always been an Agile Scrum house, and I still think the practices underneath are the right ones. Small increments, working software, a Product Owner who prioritises ruthlessly, and a client who can change their mind next sprint are all more valuable when delivery is fast, not less.

What has to change is the commercial wrapper around them. Selling hours when the hours no longer describe the work is not a pricing problem, it is an honesty problem, and clients will get there before we do.

The good news is that the thing we are actually selling has not changed. It was never the hours. It was knowing what to build, knowing when it is good enough, and being able to tell whether what came back is any good. Those judgements are worth more now than they were two years ago, not less. We just have to work out how to put a number on them.

I’ve also written about the first half of this problem in SSW’s rule on Specification Reviews, which is where the estimate gets set in the first place.