Your Sprint Has Fewer Hours Than You Think: Sprint Capacity in the Age of AI Agents

Дата публикации: 30-09-2026 08:46:22

Image


 Most Scrum Teams don't miss their Sprint forecast because they estimate badly. They miss it because they plan against hours that never existed.Picture a Sprint Planning I have watched play out, in one form or another, in dozens of organisations. Five Developers. A two-week Sprint. Someone at the whiteboard does the quick maths: five people, ten days, six focused hours a day. "We have 300 hours." Heads nod. The Product Backlog items get pulled in until the number feels full.Ten days later, at the Sprint Review, three items are not Done. Nobody slacked off. Nobody estimated wildly wrong. The Retrospective turns into a familiar conversation about "unexpected interruptions".But the interruptions were not unexpected. There was a public holiday in the middle of the Sprint. One Developer had two days of planned leave. The Scrum events took their share, as they always do. The team had booked refinement sessions. And an AI coding assistant had produced twenty pull requests that someone had to read, test and take responsibility for.All of that was visible on the first day of the Sprint. It simply never made it onto the whiteboard.When I ran the real numbers for that Sprint, the team had about 182 hours, not 300. Roughly 61% of what they planned against. This article is about closing that gap, honestly and without turning capacity into a stick to beat the team with.What sprint capacity actually isSprint capacity is the time the Developers can realistically spend on Sprint work. It is not headcount multiplied by working days multiplied by eight. Holidays, leave, the Scrum events, Product Backlog refinement and, increasingly, the review of AI-generated work all draw from the same pool of hours.It is worth being precise about what the Scrum Guide does and does not say here.It does not prescribe a capacity formula. There is no required calculation, template or percentage. How a team understands its capacity is the team's decision.It does name capacity as an input to Sprint Planning. The Guide explains that Developers forecast with more confidence when they understand three things: their past performance, their upcoming capacity and their Definition of Done.It never treats capacity as a quota. The Developers select what they believe they can do towards the Sprint Goal. Capacity helps them make that call. It does not make the call for them.That last point matters more than any formula. The moment capacity becomes a number the team is expected to fill, it stops being a tool for transparency and becomes a tool for pressure. Empiricism needs the opposite: an honest picture of reality that the team can inspect and adapt against.Watch: sprint capacity, step by stepBefore we go line by line, take a few minutes to see it working. In this video I walk through a real two-week Sprint and show exactly where the hours go, including the one line most teams leave out: the time it takes a human to review what an AI agent produced.





 If you prefer to read first, keep going. Everything in the video is explained below, and you can come back to it when you run the numbers for your own team.If this is useful, the AgileWoW YouTube channel has more short, practical sessions on Scrum with AI.Where the hours actually goFive things quietly eat into a Sprint. None of them is a surprise. All of them are routinely ignored.1. Focus hours, not office hoursNobody spends eight hours a day on Sprint work. Email, organisational meetings, support queries and context switching take their share. Many teams start with five to six focus hours per person per day and adjust after a few Sprints based on what actually happened.2. Allocation: people shared across teamsA Developer who spends half their week on another product is not a full member of your capacity. Count the share of their time that genuinely belongs to this team. Treating a 50% person as 100% is one of the fastest ways to build a forecast that cannot be met.3. Public holidays and planned leaveThis sounds obvious, yet it is the line most often skipped. In India alone, national, state and festival holidays shift every year, and distributed teams face several calendars at once. Add the holidays your organisation observes, then add each person's leave. It is known on day one; use it.4. The Scrum eventsSprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective are where inspection and adaptation happen. They are not overhead, but they do take time. The Scrum Guide sets maximum timeboxes for a one-month Sprint: eight hours for Sprint Planning, four for the Sprint Review and three for the Sprint Retrospective, usually shorter for shorter Sprints. A reasonable starting point is to scale those in proportion (a two-week Sprint starts at half) and then replace them with what your team really uses. Add 15 minutes per person per day for the Daily Scrum.5. Product Backlog refinementRefinement is an ongoing activity, not an event, and the Scrum Guide sets no fixed amount of time for it. Resist borrowing an old rule of thumb. Instead, count the refinement sessions your team has actually booked this Sprint. Two 2-hour sessions with five Developers is not 4 hours of capacity; it is 20.The new blind spot: AI agents are capacity, not membersHere is the question I now hear in almost every PSM-AI and PSPO-AI class: "We have an AI coding agent. Do we add it to our capacity as an extra Developer?"No. And getting this wrong is the fastest way to build a plan that looks comfortable on paper and collapses mid-Sprint.An agent can generate code, tests and documentation at remarkable speed. What it cannot do is be accountable for any of it. In Scrum, accountability sits with people. The Developers are accountable for creating a usable Increment that meets the Definition of Done, whoever or whatever typed the first draft.That changes where the real constraint sits. AI relocates the constraint from writing work to verifying it. Every agent task produces output that a human must read, test, question and own. That review is Sprint work, and it comes out of the same human hours as everything else.So the honest way to plan is the reverse of the instinct:Do not add hours for the agent.Do subtract the human time needed to review what the agent will produce.The calculation is simple: expected agent tasks × review minutes per task. Twenty tasks at 30 minutes each is 10 hours of Developer time, gone before anyone writes a line themselves. Leave that out and your forecast carries a silent 10-hour hole.There is a useful side effect, too. Once review time is visible, teams start asking better questions in the Retrospective. Are we giving the agent work that is cheap to verify? Is our Definition of Done clear enough that review is fast? Transparency does its job.A worked example: from 300 hours to 182Let's go back to the team from the opening. Five Developers run a two-week Sprint from Monday 28 September to Friday 9 October 2026. Gandhi Jayanti on Friday 2 October is a public holiday. Everyone is fully allocated at six focus hours a day. One Developer takes two days of leave. The team has booked two 2-hour refinement sessions. An AI coding assistant is expected to complete 20 tasks, each needing 30 minutes of human review.About 61% of the headline number is left for Sprint work. That 118-hour gap is the story behind most "we carried work over again" Retrospectives.For those who like to see the logic, this is the shape of the calculation:Baseline = working days × focus hours per day × allocation, per personAvailable = Baseline − holiday hours − leave hoursScrum events = (Planning + Review + Retrospective) × share of the Sprint attended, plus 15 minutes per day present, each × allocationRefinement = hours booked × share of the Sprint attended × allocation, per DeveloperAI review = agent tasks × review minutes ÷ 60Team focus hours = Available − Scrum events − Refinement − AI reviewYou can do this in a spreadsheet. If you would rather not, we built a free Sprint Capacity Calculator that does it in the browser, with holidays, leave, allocation, refinement and AI review time built in. No sign-up, and no team data leaves your device.Using capacity in Sprint Planning without turning it into a quotaCapacity informs the Developers' forecast. It never replaces it. Here is how I coach teams to use the number well.Start with the Sprint Goal, not the hours. Capacity tells you roughly how much room there is. The Sprint Goal tells you what matters in that room. A team with 182 hours and a clear goal will outperform a team with 300 hours and a shopping list.Compare Sprint to Sprint. If capacity drops by a fifth and the forecast stays the same size, the forecast deserves a second look. This single comparison prevents more overcommitment than any estimation technique I know.Look at the per-person view. Someone present for three days of a ten-day Sprint cannot own work that needs them the whole Sprint. Seeing this at Sprint Planning lets the team plan around the gap early instead of discovering it on day eight.Scale from what really happened. If you track completed work in points or items, scale last Sprint's result by the ratio of this Sprint's capacity to last Sprint's. If last Sprint had 200 focus hours and completed 30 points, and this Sprint has 182 hours, a starting point is about 27. Treat that as an opening for the conversation, never as a commitment.Recalibrate focus hours. Every few Sprints, revisit the hours-per-day assumption using what actually happened, not what the calendar promised. That is empiricism applied to your own planning.Five traps I see in almost every organisationThe eight-hour day. Counting eight hours for everyone ignores email, organisational meetings and support work. It inflates capacity by 25–35% before you start.The phantom full-timer. People shared across several teams are counted as if they were fully available to each one.The invisible events. Teams forget that Scrum events take real time, and the proportion is higher in shorter Sprints.The AI "team member". Agents are added as extra capacity, while the review work their output creates is ignored entirely.Capacity as a target. The number is used to push the team to fill every hour, instead of helping the Developers make a realistic forecast. This is the most damaging trap of all, because it quietly destroys the transparency that capacity planning was meant to create. Try it at your next Sprint PlanningCapacity planning is not about squeezing more out of people. It is about making the Sprint's reality visible before the Sprint starts, so the Developers can forecast honestly and the Scrum Team can inspect and adapt against something true.Here is a small experiment for your next Sprint. Before Sprint Planning, run the real numbers: holidays, leave, allocation, events, refinement and AI review. Put the headline figure and the real figure side by side on the board. Then watch the conversation change.If you want a head start, watch the walkthrough video and try the free Sprint Capacity Calculator with your own team's data.I'd love to hear from the community in the comments:What share of your headline hours does your team really have? Is it closer to 60% or 80%?How is your team accounting for the review of AI-generated work today, if at all?Have you seen capacity used as a quota, and how did you help the organisation move away from it?Sanjay Saini is a Professional Scrum Trainer with Scrum.org and the founder of AgileWoW. He teaches all Scrum.org courses, and works with Scrum Teams on using AI without losing accountability.

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Scrum's Meetings Are Capped at Five Hours a Week. Something Else Filled Your Calendar.	0	17.09	20-09-2026
2	Does Your AI Know the Scrum Guide? Twelve Questions to Find Out	0	9.71	21-09-2026
3	The New SDLC From Google Has a Harness. It Doesn't Have a Team.	0	14.4	30-09-2026
4	AI on Top of a Dysfunctional System (1): The Product Backlog	0	5.29	20-09-2026
5	Scrum's Protocol Is Easy to Copy. Its Agenda Is Not.	0	14.4	27-09-2026
6	Your Scrum Team Might Be Excellent at Building the Wrong Thing	0	13.28	27-09-2026
7	‘Batches’ in Scrum	0	13.56	24-09-2026
8	Your Team Isn't Slow. Your Handoffs Are.	0	8.51	22-09-2026
9	🎉 Published: Scrum Team Magazine - October 2026 - Issue #2	0	15.71	30-09-2026
10	KI auf einem dysfunktionalen System (1): Das Produkt-Backlog 🇩🇪	0	8.42	24-09-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 14.09. Источник: www.scrum.org.