Moving from traditional coding to agentic coding requires a large mindset shift.
As a developer, your job transitions into an orchestrator and reviewer role. You design the ticket, hand it off to an agent like Claude Code to implement, review what was done, and request changes.
A major side effect of this shift is that traditional agile velocity estimations can no longer be calculated the way they once were.
Historically, cost estimates focused mostly on the time it would take a human developer to build out the code. With agentic coding, the time to write becomes an almost non-factor; even a large ticket can take 30 to 60 minutes to implement, instead of days. However, that doesn't mean you can push out production-ready software in that window.
First, the developer must collaborate with the agent to design what it is going to do. After that comes the heaviest time sink: code review. Reviewing what an AI wrote to ensure it maintains architectural standards and strictly achieves the business intent requires an entirely different type of energy.
The bottleneck is no longer how fast a developer can write code; it is the developer's cognitive capacity to review it thoroughly.
A notorious adage in software development describes this perfectly (often called Parkinson’s Law of Triviality, or Bikeshhedding): a 5-line code change gets deeply scrutinized in a PR, while a 10,000-line change gets checked off without much thought. This stems directly from the massive cognitive strain that goes into a large code review.
With agentic coding, this cognitive fatigue arises much sooner in the process; occurring continuously during development rather than being back-loaded to a post-development pull request.
Instead of measuring velocity in terms of implementation time, teams must start viewing it through the lens of cognitive complexity.
How do you calculate cognitive complexity?
After a lot of thought about this I think the complexity should be broken up into 5 categories, and within those categories, a rating of low, medium, high.
- Planning complexity
- Review surface area
- Cognitive load
- Test complexity
- Ambiguity
1. Planning Complexity
How difficult will the planning session be? How many design decisions need to be locked down before the AI can start?
A simple CRUD endpoint with an obvious implementation path is Low. A feature that touches three architectural layers, requires a new abstraction, or has a data migration is High. Planning complexity determines how long the /plan session takes and how much rework happens if it goes wrong.
2. Review Surface Area
How many files will a reviewer need to read? How many lines of code?
This is measurable. Under five files and 200 lines is Low; a focused change a reviewer can hold in their head. Over ten files or 500+ lines is High; and at that point you're asking reviewers to maintain the full picture of a system they didn't design while looking for subtle AI mistakes.
3. Cognitive Load
Review surface area is a reading-time problem. Cognitive load is a comprehension problem. They're different.
A three-file change that touches your authentication and permission system can be harder to review than a fifteen-file change that adds a new resource with standard CRUD. Cognitive load measures how much system knowledge a reviewer must hold simultaneously to catch the errors an AI is most likely to make.
An isolated, self-contained change is Low. Something that requires understanding a state machine, a set of permission rules, and an async coordination pattern simultaneously is High; because the risk isn't that any individual piece is hard, it's that one wrong assumption about how the pieces interact creates a bug that passes all the tests.
4. Test Complexity
AI writes tests too, but someone still has to design the test scenarios, verify that the mocks actually reflect the system's behaviour, and confirm that edge cases are covered. More scenarios, more external service stubs, and more integration requirements all increase the human overhead here.
5. Ambiguity
This one is different from the others. When a human developer hits an ambiguous requirement mid-implementation, they make a judgment call or ask a question. When an AI hits an ambiguous requirement, it makes a confident guess; and the guess is often plausible enough that nobody catches it in review.
High ambiguity in a ticket doesn't just add a fixed overhead. It multiplies all the other costs, because a poorly-defined ticket is likely to produce a result that needs reworking; and rework means running the entire planning-review-QA cycle again.
Turning Scores Into a Number
Measuring dimensions is useful, but planning boards need a number. Here's a formula that works.
Score each execution dimension (Planning, Review Surface, Cognitive Load, Test Complexity) using a non-linear scale; Low=1, Medium=3, High=6; and sum them. This is your base score, ranging from 4 to 24.
The non-linearity is deliberate. Complexity doesn't scale evenly: a reviewer holding one complex mental model isn't just 50% more taxed than one holding none; they're three to four times as taxed, because there's no margin for error. High=6 reflects that disproportionate cost. Two Highs together compound further still: a reviewer must hold both difficult models simultaneously in a single pass, which is qualitatively harder than doing each separately.
Then apply an ambiguity multiplier:
- Low ambiguity: ×1.0 (no adjustment; the ticket is well-defined)
- Medium ambiguity: ×1.25 (some gaps; expect some iteration)
- High ambiguity: ×1.5 (rework likely; the AI will miss the intent)
Round the result to the nearest integer, then map it to velocity points.
The calibration anchor matters here: these points represent human overhead hours, not implementation hours. Using a conventional 1 point = 4 hours sprint velocity, the mapping looks like this:
| Weighted Score | Velocity Points | Human Overhead |
|---|---|---|
| 4–9 | 1 pt | ~4 hrs; focused plan + quick review |
| 10–14 | 2 pts | ~8 hrs; a full day of human attention |
| 15–19 | 3 pts | ~12 hrs; plan, review, and QA across 1.5 days |
| 20–23 | 5 pts | ~20 hrs; complex plan + heavy review load |
| 24–28 | 8 pts | ~32 hrs; close to a full person-week |
| 29+ | 13 pts | Epic; must split before pickup |
If your team uses a different anchor (2 hours per point, 8 hours per point), slide the boundary ranges accordingly; the formula stays the same, only the lookup table shifts.
These aren't implementation hours. They're human-overhead hours; the time that real people spend planning, reviewing, and verifying work the AI produced.
Calculating on a ticket by ticket basis
This formula isn't straightforward, and asking developers to calculate this will take time and experience with agentic coding, Once they are familiar with their work habits and experiences with agentic coding, they will be able to figure it out just fine.
Until that happens, Product managers and Dev managers still are going to want to know with some accuracy, what the likely ticket velocity will be, and calculating it based on the amount of coding required won't arrive at the right answer (or maybe it will but for the wrong reasons)
For that reason I created a small skill for Claude Code that takes a PM built ticket requirement list, and goes through the planning of the ticket, using both the tickets ask and context of the code base, to pre plan the ticket and calculate the weights. This could be something run by a Dev Manager, or Principal developer, or team lead before the ticket reaches a backlog meeting. It could highlight changes that need to be made before presenting the ticket to the team, potential vertically slicing the ticket if its a high complexity, or fold other tickets into one if it's low.
The plan generated by the estimator wouldn't be the final plan, that should be left to the developers to work through, and deliver. Developers have their own systems for building features, even when AI is involved. However, an initial plan can give Product Managers the information they need to create sprints that deliver in an agentic space.
Alleviating bottlenecks
Developers can help some of the cognitive overheads by implementing processes during development. Specifically, teams can create agentic review skills that compare generated code against the claude.md specifications, architectural rules, and original ticket plan before a human ever sees the code.
Doing this will mean that the AI agent can self review its code and find holes in it before the developer needs to look at it. Having a First-pass AI skill can help remove the obvious issues and leave the developer only needing to look at the deeper things, rather than having to look for both.
Helpful visual tool
I am providing a link to a helpful estimate tool, so you can see the difference various combinations make to the overall velocity. Hopefully seeing it in action will help it make sense!
