Most sprint estimates carry a hidden assumption: that a person will write every line of the work being sized. Story points, ideal days, t-shirt sizes, they all trace back to how long a developer expects to spend typing, reading, and debugging. Once Claude Code is drafting the first version of a feature and a good part of the test suite, that assumption breaks. A ticket a team once called an 8 can land in an afternoon, and a ticket they called a 3 can still eat two days because the hard part was never the code.
Why the old point scale stops matching reality
When we sit with engineering teams around Sydney and Melbourne, the first thing we hear is that velocity has gone strange. The burndown chart looks noisy. Some sprints finish early with room to spare, others stall on work that looked trivial on the board. The scale has not changed, but the thing it measures has. Points were a proxy for developer effort, and developer effort is no longer the main cost of most tickets.
The work Claude Code handles well, such as boilerplate, CRUD endpoints, migrations, test scaffolding, and refactors with a clear pattern, used to carry real point weight. It now costs very little. The work Claude cannot shortcut, such as deciding what to build, resolving ambiguity, and integrating with a legacy system nobody documented, is where the hours still go. If a team keeps sizing by old habit, its estimates drift and planning meetings lose their footing.
What actually changes in the estimate
It helps to split any ticket into two parts: the generation cost and the judgement cost. Generation is producing the code, the tests, and the config. Judgement is everything a person still has to decide or verify.
Claude Code collapses the generation cost. Judgement cost stays roughly where it was, and in some cases rises, because a person now reviews more output in less time. The tickets that shift the most are the ones that were almost all generation to begin with.
Pure generation work (scaffolding, repetitive endpoints, straightforward tests) drops sharply, often from a full day to under an hour.
Ambiguous work (unclear requirements, undecided data models) barely moves, because the bottleneck is the decision, not the typing.
Integration with poorly documented or legacy systems stays heavy, since Claude needs context a team may never have written down.
Review and verification grow as a share of the sprint, because more code arrives for humans to check.
A sizing method that holds up
The fix is not a new points formula. It is sizing the judgement, not the keystrokes. When a team estimates a ticket, we ask one question first: how much of this is a decision, and how much is production? If it is mostly production, the estimate should be small and the review slot should be explicit. If it is mostly decision, size it the way the team always did, because Claude changes little about it.
This sounds simple, and the discipline is the hard part. Teams are used to arguing about whether something is a 3 or a 5. The more useful argument now is whether the risk sits in building the thing or in knowing what the thing should be. Once a room starts sorting tickets that way, the estimates settle down within a sprint or two.
Run a two-week calibration
Before trusting any new numbers, run a short calibration. For two sprints, record the old point estimate, the actual elapsed time, and a short note on where the time went. Most teams find their generation-heavy tickets were over-sized by a factor of three or four, while their ambiguous tickets were about right. That evidence, not a consultant's opinion, is what convinces a room to change how it plans.
The numbers a lead should watch
Once the scale is re-anchored, a few signals tell you whether estimation is healthy again.
Review time as a share of the sprint. If it climbs past a quarter of capacity, the team is generating faster than it can verify, and the plan needs a review buffer.
Rework rate on Claude-drafted code. A low rate means the sizing is honest; a high rate means judgement cost was underestimated.
Estimate accuracy on ambiguous tickets, which should stay stable, since those are the true test of a team's understanding of the work.
For a mid-size product team the payoff is concrete. A ten-developer group in Australia running fortnightly sprints can recover the equivalent of one to two full engineers in freed capacity, on the order of $180,000 a year, but only if planning reflects where the work actually sits. Teams that keep sizing by the old scale often spend that gain on rework and missed commitments instead, and a single slipped release can cost more than $45,000 in lost momentum.
Sprint planning was never really about the points. It was about a shared, honest picture of the work ahead. Claude Code does not remove the need for that picture, it changes what belongs in it. Teams that re-anchor their estimates around judgement, and treat review and rework as first-class numbers, plan with more confidence than they had before. If you want help calibrating your own estimates, book a short session and we can walk through your last two sprints together.
