Agile Capacity Planning: 45-Min Ops Sprint Guide

You know the drill: you tally up your team"s available hours, subtract vacations and meetings, divide by your average story-point velocity, and call it a plan.

Sounds good–until Tuesday hits.

"Feeling overwhelmed by our over-dependence on SaaS."
–Ops PM on Reddit, r/SaaS, 57 upvotes. Zero comments with real solutions.

Then–bam–three urgent requests drop on your desk out of nowhere. None of them existed during last week"s sprint planning. By Tuesday afternoon, your carefully crafted capacity spreadsheet is already a relic.

Here"s the kicker: Your planning isn"t broken. Your framework is.

You"re applying a dev-team model to an Ops reality. You know the symptoms: nobody actually tracks velocity. Sprint reviews happen–with zero numbers. Your Trello board has 200 cards, but no one reads it, because every stakeholder update is just gut feeling anyway.

This guide is your way out. You"ll see how capacity planning truly works for Ops teams: using the right unit (hours, not story points), the right metric (Ad-hoc Ratio, not velocity), and a process that takes 45 minutes per sprint–not four hours. At the end, you"ll have a working Google Sheets setup, a formula to calculate predictable capacity, and a stakeholder template that prevents escalation before it starts.

TL;DR: The Real Ops Capacity Cheat Sheet

Scrum-style capacity planning falls flat for Ops teams because story points measure complexity, not availability; it"s not your team–it"s the wrong metric. The secret number is Ad-hoc Ratio, typically 30–70% depending on your team type, and most teams never track it, nearly all underestimating it. The simple formula is Net hours × (1 – Ad-hoc Ratio) × 0.85. In real life, a 5-person team gets, at best, 143 out of 400 calendar hours for planned work (just 36%); if you plan for 200, you"re setting yourself up to fail. The full system takes just 45 minutes per sprint, spread across the sprint start, middle, and end.

Why Scrum Capacity Planning Fails for Ops Teams

Imagine this: You"re running a two-week sprint, and you"ve meticulously mapped out everything using Scrum"s best practices. But Ops isn"t Dev. The reality? Scrum capacity planning was built for feature teams, not support or operations.

Here"s why that matters.

The Scrum.org Sprint Capacity Planning Guide was designed for software dev teams. That"s by design, not by accident. Dev teams work from a well-defined backlog–features are described, estimated, prioritized. Complexity changes, but the flow is steady enough to measure velocity and plan future sprints.

Ops teams live in the opposite world.

Most Ops requests aren"t all that complex–a support ticket here, a process doc there, a stakeholder report. But the volume and timing? Completely unpredictable. You don"t get neat backlogs; you get drive-by requests from every direction, at any time, in every possible flavor of urgency.

And here"s the killer: SLA commitments don"t wait for your next sprint.

Meanwhile, "work about work"–chasing statuses, prepping updates, toggling between tools–eats a huge chunk of your day, but never shows up in JIRA. According to Asana"s research, 60% of knowledge workers" time is lost to this overhead. Only 27% goes to actual skill-based work. That means you lose almost two-thirds of your talent to tasks that generate zero forward momentum.

And with the average SaaS Ops team juggling 87 different tools (saasoperations.com), you"d expect more clarity. Instead, you get 87 dashboards and no real insight into your actual capacity.

Let"s break it down:
Here"s how capacity planning looks when you stick with the Scrum model versus what actually works for Ops:

Here"s the consequence:
In Plaky"s 2026 PM stats, 75% of project managers say they"re constantly asked to do too much with too little. Why? Because capacity is guessed, not measured–and the guesses are based on a model built for someone else"s team.

Now, let"s dig into what Ops teams actually need to measure.

The 4 Inputs Ops Teams Really Need for Capacity Planning

So what should you actually be tracking to plan capacity in an Ops team?

Forget story points and velocity. They don"t capture the chaos of your day-to-day. Instead, you need these four inputs:

1. Net Available Hours (after subtracting meetings and vacations)
2. Historical Ad-hoc Ratio (the true percentage of unplanned requests)
3. SLA-blocked Capacity (hours tied up by non-negotiable response times)
4. A 15% Buffer (for surprises–because 10% is never enough)

Let"s walk through each.

Input 1: Net Available Hours

Not calendar hours, not contract hours–NET hours. Take your gross working hours and subtract everything that doesn"t directly produce output: regular meetings, 1:1s, company-wide calls, admin tasks, onboarding. For most Ops teams, this overhead eats up 30–40% of your gross hours. So, from 80 working hours per person in a two-week sprint, you"re usually left with just 48–56 net hours.

Input 2: Historical Ad-hoc Ratio

Here"s the big one.
The Ad-hoc Ratio is the percentage of tickets in a sprint that were unplanned. If your ratio is 40%, only 60% of your time is truly plannable–even before subtracting overhead and buffer.

Most teams have no idea what their real Ad-hoc Ratio is. They guess–usually too low. We"ll fix that soon.

Input 3: SLA-Bound Capacity

What percentage of your work is locked in by Service Level Agreements? These are the tasks you can"t push back: hard response deadlines, unmovable commitments. Treat these as non-negotiable blocks in your planning, not afterthoughts. Often, these eat up 15–25% of your net capacity. Ignore them at your peril.

Input 4: The 15% Buffer–Why 10% Just Doesn"t Cut It

A 10% buffer covers estimation errors and planned wiggle room. But another 5% is your insurance against real chaos: escalations, surprise stakeholder requests, that bug that lands on your desk at 4:59pm. Teams running above 90% capacity see higher error rates and burnout risk. This isn"t a comfort buffer–it"s risk management.

Consider this: ProProfs" Workflow Automation Stats show 50% of Ops teams spend at least a full day each month manually compiling project status info. That"s a symptom of missing capacity tracking. If no one knows the real numbers, alignment overhead is inevitable.

Ready to make this practical? Next up: how to actually measure your Ad-hoc Ratio.

Step 1: Measuring Your Team"s Ad-hoc Ratio (The 2-Sprint Method)

Most teams guess their Ad-hoc Ratio–and almost all are wrong. Here"s how to measure it in under 30 minutes.

Here"s what you do:

1. Open your ticket system.
2. For the last two sprints, tag every ticket as either "planned" (was in sprint planning) or "ad-hoc" (arrived after planning).
3. Even with busy boards, this shouldn"t take more than half an hour.

The formula:

Ad-hoc Ratio = (Number of ad-hoc tickets / Total tickets) × 100

Typical values by team type:

Notice how much these numbers swing? That"s because different Ops teams face wildly different levels of unpredictability. A support team"s world is nothing like a product ops team"s.

Why two sprints, not one?
A single sprint can get skewed by a big launch, an incident, or a quarterly report. Two sprints smooth out the noise for a more reliable baseline. Six sprints is even better, but you can start with two and refine from there.

"Most teams underestimate their ad-hoc ratio by 10–15 points. If you"re guessing 25%, odds are you"ll measure 40%."
–Georg Singer, capacity planning coach

And here"s another reality check: BetterCloud"s State of SaaS found 60% of IT teams in SaaS are buried under manual tasks, despite ever-growing tool stacks. Much of that is unplanned work that never gets measured–and so it never makes it into your capacity planning.

Now that you know how to measure chaos, let"s see how to turn it into numbers you can use.

Step 2: Calculating Capacity in Hours–The Ops Formula

So how do you turn all that chaos into a number you can actually plan around?

Here"s the formula for plannable capacity:

Net Hours × (1 – Ad-hoc Ratio) × 0.85

This gives you the portion of your team"s time that"s genuinely available for planned, strategic work.

Let"s run through a real-world example.

Example: 5-person Ops team, 2-week sprint

5 people × 80 hours = 400 gross hours
minus 30% meeting overhead = 280 net hours
with 40% ad-hoc × 0.6 = 168 planned hours
minus 15% buffer × 0.85 = 143 plannable hours

Out of a theoretical 400 hours, only 143 hours are realistically available for planned work–just 36%.

Most PMs are shocked by that number. But it explains why sprint plans with 200 hours of work for a 5-person team are doomed from the start.

See how it plays out across scenarios:

| Team Size | Ad-hoc 30% | Ad-hoc 50% | Ad-hoc 70% | |---|---|---| | 3 people | 104 h | 74 h | 44 h | | 5 people | 173 h | 124 h | 74 h | | 10 people | 346 h | 247 h | 148 h |

If your 5-person support team has a 70% ad-hoc ratio, you get just 74 hours per sprint for planned projects. Assign them 150 hours? Delivery will slip–guaranteed.

Asana"s Anatomy of Work Index shows the upside: better process can win back 4.9 hours per week per knowledge worker–six full workweeks per year. But you only get that if you first admit how much time you"re really losing.

Next, let"s make this operational with a dead-simple template.