Sprint planning with two capacities: your team and your agents

Your velocity chart says 34 and you stopped believing it weeks ago. Half those points were closed by people, half by coding agents, and averaging two populations that share no unit produces nothing you can plan on.

Here is the sprint that produced it. Committed 34, closed 26, and at the retro nobody could say which half slipped. Every agent ticket hit review on schedule. Six came back twice. Two engineers spent most of a Thursday reading generated diffs instead of writing their own code, the human stories slid a day, and the chart logged a team wide dip.

Two track here is not dual track agile, which splits discovery from delivery. This is one sprint, some tickets worked by people and some by agents, and one capacity number that fits neither. Disclosure: we make a tracker teams point their agents at, so discount the product section.

Two populations, one average

Velocity works because it measures something slow. Team throughput drifts with hiring, leave and attention, so three sprints of history forecast the fourth.

Agent throughput has no such inertia. It tracks whoever is free to read output this week. Add a reviewer and it roughly doubles. Put your two seniors on a customer escalation and it goes to zero while the agents keep producing, which is the worse failure, because the work still looks like it is happening.

Blend them and the number moves for reasons that have nothing to do with your team. CircleCI's 2026 State of Software Delivery report, built from 28,738,317 workflows run in September 2025, found the median team's feature branch throughput up 15 percent year over year while main branch throughput fell 7 percent. More produced, less landing, and their list of where it collects is review, validation, integration, recovery.

flowchart LR
    H["Human track, in points"] --> R["Review queue"]
    A["Agent track, in tickets"] --> R
    R --> M["Merged to main"]
    R --> B["Bounced back"]
    B --> A

Human capacity still measures what it always did

Nothing about your people changed when the agents arrived. Attention is still the bound, a sprint is still ten working days, and an engineer in a two hour meeting is not writing code. Whether you count that in points or hours is a per project setting and an old argument, which story points or hours takes apart properly.

What changes is what you stop putting in. When Sara reviews an agent's pull request for two hours on Wednesday, those hours leave her capacity as review time, but the ticket carries no story points on the human side. It gets counted once, in the other track, in a different unit.

Teams get this wrong in one specific way. They leave the points on the agent ticket because the work did happen, then wonder why velocity climbs while nothing ships sooner. Points measure what your team can absorb, and an agent absorbs nothing from your team except review. For the preparation half, see what actually works in AI sprint planning.

Reviewer hours, not agent hours, bound the agent track

Ask what limits the agent side and the intuitive answers are agent time or token spend. Both are wrong, and the token answer is the more expensive mistake.

The most complete published framework is Marcelo Bernardes's Story Points to Tokens, from 11 February 2026: sprint capacity is the lower of velocity capacity and token budget over tokens per point. Clean arithmetic, wrong second constraint, and his own cost note gives it away. Twenty million tokens, a whole sprint at 500k per story point, prices out near 233 US dollars at Opus rates, a rounding error against the reviewer hours the same sprint eats. Capping on tokens caps the input you have plenty of.

That review capacity is the real ceiling is not our observation. Rick Pollick made the case in review capacity is the new delivery ceiling on 13 July. What nobody has published is a number you can carry into a planning meeting. Two measurements give you one.

LinearB's 2026 engineering benchmarks, drawn from 8.1 million pull requests across roughly 4,800 teams, put AI assisted pull requests just over 400 lines at the 75th percentile against 157 unassisted, with fully agentic ones near 290. They wait about 1,050 minutes to be picked up against roughly 200, and merge within thirty days 32.7 percent of the time against 84.5. Bigger, slower to be looked at, far less likely to land.

The reviewer side has not moved in twenty years. SmartBear's write up of the Cisco study still puts the ceiling at 200 to 400 lines per sitting, no more than 60 minutes at a stretch, with defect density dropping sharply past 500 lines an hour. A 400 line agent pull request is one whole sitting.

Doing the multiplication

reviewers = 2                # people who will really review
review_hours_per_day = 2.5   # protected time, not spare time
sprint_days = 10
hours_per_agent_pr = 1.25    # 60 min of inspection + 15 min of everything else
utilisation = 0.7            # past 85 percent the queue bites

budget = reviewers * review_hours_per_day * sprint_days / hours_per_agent_pr * utilisation
print(round(budget))         # 28 agent pull requests
print(round(budget * 0.5))   # 14 in the first sprint

Sixty minutes is SmartBear's ceiling for one sitting. The extra fifteen is the part nobody budgets: writing the comments, reloading the context you dropped, and skimming the second version. If your reviewers are honest, it is more than fifteen.

The 0.7 is not caution for its own sake. Pollick's piece points at queue behaviour any operations person will recognise, where expected wait scales with utilisation over one minus utilisation. At 70 percent you have headroom and a surprise costs you a little. At 85 the queue starts to bite. At 95, in his words, wait time does not degrade, it detonates.

	Human track	Agent track
Bounded by	Attention, and the hours left after meetings	Reviewer hours you can protect
Unit	Points or hours	Tickets that can clear review
Read from	Velocity over three sprints	Merged agent pull requests, not opened ones
Fails as	Overcommitment, obvious at the retro	A full queue that stalls both tracks

What goes on the board for sprint one

Fourteen tickets, then adjust after two sprints. Halving the first run is deliberate: you do not yet know your diff sizes, your rework rate, or how much review time your people can defend.

Name the reviewer for every agent ticket during planning, not when the pull request appears. An unnamed reviewer is how a queue forms, quietly, by Wednesday.

Ticket quality moves this arithmetic more than anything else here. A vague ticket costs several review rounds because the reviewer writes the spec in comments, so the same hour buys less. If your agent tickets bounce twice on average, your real budget is half what the script printed, which makes writing tickets an agent can finish the cheapest lever you have.

Two questions in the planning meeting instead of one

The old meeting asked what fits. Ask two questions in order, and give the second one teeth.

What fits the team? Human capacity, exactly as before, over tickets with a person's name on them.

What fits review? Rank the agent candidates, cut at the review budget, then the awkward part: each named reviewer says out loud whether their week contains those hours. If two of your three reviewers are on incident rotation, the agent budget shrinks at planning instead of on day six.

Whatever the cut leaves out stays in the backlog. Do not hand it to a person as a consolation prize. A ticket written for an agent is usually the wrong shape for a human.

When the agent track overruns into yours

The signature is a review column that stops draining while everything upstream keeps moving. Assignments still go out, sessions still open, queue age climbs.

The move is counter intuitive the first time: stop starting agent work, do not stop reviewing. Idle agents cost you almost nothing. A reviewer pulled off their own tickets to clear generated diffs costs the human track directly, which is how one overrun sprint becomes two. Freeze new assignments until the review column is under its number.

Be careful what your board actually enforces, ours included. The per column WIP number in our project settings is stored and read back to you, and nothing consumes it. The board's WIP toggle counts against a fixed per category default instead, four in progress and three in review, and colours the header when a column is over. Neither refuses a card. The rule that does refuse a move is the allowed transition list on a status.

What to report, and what to stop reporting

Stop reporting blended velocity, and stop reporting agent hours or token counts as output, because they measure the input you are not short of. Do not build a per person leaderboard, agents included. The first response to a leaderboard is defensive estimating, and then every input to your capacity maths is junk.

Four things earn a slide. Review queue depth next to the age of the oldest item, since depth alone hides one stale review blocking a release. Pending pull requests per active reviewer, where anything above two is more than a day of backlog per person. Merged per agent ticket, not done per agent ticket: eleven pull requests opened where four merged is four tickets of work and eleven tickets of review. And cycle time split by author type, because a fatter tail on agent tickets is nearly always review wait, which you only see once you separate cycle time from lead time.

What the product does here, and what it does not

Two track planning is a convention you run with ordinary fields. There is no capacity planner in Taskfolk, no resource levelling, no auto scheduling.

Sprints run in parallel, so a review bound agent track can be its own sprint with its own dates, and velocity and burndown follow the project's estimation unit.

Agent work is countable because a connected agent is a real workspace member with its own user id, not a bot borrowing yours. A saved view filtered to that assignee is your agent track, and the same filter is one API call.

BASE=https://taskfolk.ai/api/v1/workspaces/acme
curl -H "Authorization: Bearer $TASKFOLK_KEY" \
  "$BASE/projects/WEB/issues?assignee=$AGENT&sprint=$SPRINT&status=in_review"

auth = {"Authorization": f"Bearer {os.environ['TASKFOLK_KEY']}"}
r = requests.get(f"{BASE}/projects/WEB/issues", headers=auth,
                 params={"assignee": agent, "sprint": sprint, "status": "in_review"})
print(len(r.json()["data"]))

{ "data": [ { "key": "WEB-142", "status": "in_review", "sprint_id": "0198f2b0-8c11-..." } ] }

Sessions keep the count honest. Assigning an issue to an agent creates a pending session before the agent wakes, and the pull request URL lives on it, so sessions in review are your queue depth.

Where it falls short. The Insights Capacity tab is a workload view, not a capacity model: open issues per assignee for the twenty busiest people, with summed estimate minutes beside them. No availability model, no story point column, and no marker for which rows are agents, so you split the tracks by reading names. More of that surface in project reports and insights.

Agent cost rolls up per day and per model over a 7, 30 or 90 day window, and cumulatively per agent, never per sprint. Every figure is agent reported: we deliver the trigger and store the record, we never run the model, which is why agent cost per task is its own subject.

Tool	Human capacity model	Agent throughput control
Jira Premium and Enterprise	Team capacity and velocity inside Plans, estimate unit configurable	None
Azure Boards	Hours or days per person per day, days off, split by activity	None
Linear	None	Agent platform from Free, coding sessions on Business
Taskfolk	None. Capacity tab lists open work per assignee	Sessions per issue, saved views per agent, cost rollups

Checked 26 July 2026. Jira keeps capacity behind Premium; Azure Boards has the richer model and asks only for Basic access. Neither models agents, and neither do we.

Next sprint, do one thing. Put a number on the review column before you plan, and refuse to start more agent tickets than that number. Within a week you will know whether the agents were ever your bottleneck.