How To Do Sprint Capacity Calculation For Mixed Full Time And Part Time Team

Most sprint plans fail for a boring reason. The team’s capacity was guessed, not calculated.

It gets worse when you’ve got a mixed team: two full-timers, a part-time QA, a designer shared with another squad, and an engineering manager who codes “when there’s time.” If you treat that as five equal people, your sprint commitment becomes fiction.

This is where sprint capacity calculation for mixed full time and part time team needs to be explicit, simple, and repeatable. Not perfect. Repeatable.

What capacity is (and what it isn’t)

Capacity is the amount of working time the team can realistically spend delivering sprint work, after you account for time off, planned meetings, and part-time allocation.

Capacity isn’t velocity.

Velocity is an output measure based on what the team finished. Capacity is an input constraint based on time. You can use one to inform the other, but mixing them leads to bad commitments and worse conversations.

If you’re using Scrum, the Scrum Guide is blunt about the Sprint Backlog being a plan by and for Developers, and it changes as you learn. Capacity is one of the few inputs you can know before the sprint starts. The Scrum Guide doesn’t prescribe a formula, but it does assume you’re making an honest plan.

The base formula that works in real teams

Here’s the calculation we’ve seen hold up across SaaS and enterprise teams:

• Capacity (hours) per person = (working days in sprint × hours/day × allocation %) − planned time off − non-delivery time
• Team capacity = sum of all individual capacities

You can do it in hours, or in “ideal hours,” or in “focus hours.” Just pick one unit and keep it consistent.

Two decisions matter more than the math:

• What counts as non-delivery time for your team (ceremonies, support, interviews, on-call, production releases)
• What “allocation %” actually means for part-timers (and whether it’s protected)

We’ll get to both.

A worked example with mixed allocations

Let’s use a two-week sprint (10 working days). Your team:

• Asha (backend): full-time, 8h/day
• Ben (frontend): full-time, 8h/day
• Carmen (QA): 50% allocated to your team
• Diego (designer): 30% allocated, shared with another product team
• Elena (engineering manager): 20% hands-on, rest is management

Planned non-delivery time per person per sprint (you should customize this):

• Sprint Planning: 2 hours
• Daily Scrum: 15 min/day = 2.5 hours
• Review: 1 hour
• Retro: 1 hour

That’s 6.5 hours per person per sprint, before you even talk about support, incidents, or stakeholder meetings.

Now compute each person’s capacity.

• Asha: (10 × 8 × 1.0) − 6.5 = 73.5 hours
• Ben: (10 × 8 × 1.0) − 6.5 = 73.5 hours
• Carmen: (10 × 8 × 0.5) − 6.5 = 33.5 hours
• Diego: (10 × 8 × 0.3) − 6.5 = 17.5 hours
• Elena: (10 × 8 × 0.2) − 6.5 = 9.5 hours

Total team capacity: 207.5 hours.

That number will feel low to leaders who still think “five people equals 400 hours.” Good. It’s supposed to feel low, because meetings and split time are real.

Two adjustments most teams need

First, time off. If Ben has one vacation day, subtract 8 hours (or 8 × allocation) before subtracting the fixed ceremonies.

Second, support and interrupts. If your team covers customer escalations or production support, treat it like a budget line, not an afterthought. For example:

• Planned support load: 10 hours per sprint for Asha, 6 for Ben, 4 for Carmen

Subtract those too. You’re not being pessimistic. You’re being accurate.

My take: stop converting part-time people into story points

Most guides push you to “just use velocity” and ignore hours, because story points are what agile teams do.

That advice is wrong for mixed full-time and part-time teams.

Story points are a relative sizing tool. Capacity is a time constraint. When half your team is split across three priorities, you need time math to prevent overcommitment. Use hours to set the sprint boundary. Then use story points to choose the best work inside that boundary.

If you want a bridge between the two, translate last sprint’s delivered points into an implied points-per-hour ratio and sanity check it. Don’t pretend it’s physics. Treat it as a steering instrument.

How to handle the messy parts: allocation, focus time, and context switching

Mixed teams don’t fail on arithmetic. They fail on assumptions.

Allocation % only counts if someone protects it

If Diego is “30% allocated” but gets pulled into ad hoc executive requests, Diego’s real allocation might be 10%. Your plan will still assume 30%, and you’ll blame the team when design work slips.

Make allocation a visible agreement. Put it in the team charter, the PI plan, or the resourcing doc. Then enforce it.

If you’re tracking work in Jira, it’s worth formalizing who owns what with a dedicated board or component ownership. Atlassian’s own guidance on agile boards and workflows is a practical baseline if your setup is inconsistent: Atlassian’s agile resources.

Part-time capacity needs a context-switch tax

A designer at 30% doesn’t deliver 30% of a full-time designer’s output if their work is chopped into tiny windows.

Context switching eats time. Reserve a tax for it.

• If someone is 50% on your team and 50% elsewhere, subtract 10% of their allocated time as a switching penalty.
• If someone is 20% on your team, subtract 20% of their allocated time. Yes, really.

In the earlier example, Elena had 16 allocated hours (10×8×0.2). With a 20% switching penalty, that becomes 12.8 hours. Then subtract ceremonies. Now you’re looking at roughly 6.3 hours of real delivery time for the sprint.

This is why “EM is a developer too” planning often collapses.

Don’t subtract ceremonies equally if attendance isn’t equal

Some teams subtract 6.5 hours from everyone, even the shared designer who only joins planning and review.

That’s lazy math.

Instead, subtract the meetings each role truly attends. If Diego only joins Planning (2h) and Review (1h), subtract 3 hours, not 6.5.

Capacity works when it reflects your actual week, not your ideal process diagram.

Turning hours into a sprint commitment

Once you have team capacity in hours, you still need to decide what to pull into the sprint.

Here’s a practical workflow that doesn’t turn Sprint Planning into a spreadsheet contest.

1. Calculate individual capacity (including time off and known interrupts).
2. Agree on a buffer. For most product teams, 10% to 20% is reasonable. If you’re on-call or release-heavy, go higher.
3. Pick the sprint goal first. If you can’t state it in one sentence, you’re planning a backlog, not a sprint.
4. Pull in work until you hit the buffered capacity limit.
5. Check role constraints. If QA has 25 hours, don’t pull testing work that assumes 50.

If you want a simple calculator format for the spreadsheet people in the room, Google Sheets or Excel is fine. If you want a purpose-built template, tools like Smartsheet can be useful for teams that already run project reporting there.

But the tool choice won’t save you if the inputs are fantasy.

Common failure modes (and how to correct them)

Failure mode 1: treating part-time QA as “help when needed”

If QA is part-time, QA work must be planned like a scarce resource. Otherwise, testing becomes the sprint’s hidden critical path.

Correction: write explicit testing tasks, and cap them to QA capacity. If developers will help test, say so during planning and allocate their hours.

Failure mode 2: planning in points with no time reality check

A team pulls 40 points because “that’s our velocity,” while two people are out and a key specialist is 30% allocated.

Correction: run capacity first, then pull points. If your ratio says you can likely deliver 28 points, argue about priorities, not miracles.

Failure mode 3: ignoring public holidays and corporate events

Enterprise teams lose days to town halls, compliance training, and quarterly planning. If you don’t subtract it, the sprint becomes a blame exercise.

Correction: add a shared calendar step to refinement. If your company uses Outlook, put the sprint dates on a shared calendar and tag known drains.

Failure mode 4: undercounting meetings outside Scrum

Architecture reviews. Security sign-offs. Customer calls. Hiring loops. These don’t show up in Scrum diagrams, but they consume the week.

Correction: track “overhead hours” for two sprints. Don’t guess. Measure. Even a lightweight time audit will change the conversation.

If you want a neutral reference on why interruptions and multitasking hurt output, the PubMed Central repository is a good place to find primary research on cognitive load and task switching without relying on vendor blogs.

Capacity is also a risk signal, not just a planning input

When capacity drops, your delivery risk rises. That’s obvious. What’s less obvious is how early you can see it.

If Elena’s delivery capacity is 6 hours and the sprint plan assumes she’ll build a complex integration, you’ve got a risk that should be visible on day one.

Same with shared roles. A 30% designer can’t carry a full redesign, even if the story points look small.

Use capacity to force tradeoffs early, when they’re cheap.

Teams that track flow metrics can connect capacity dips to cycle time changes. If you’re using Kanban concepts alongside Scrum, the Kanban University resources are a solid reference point for flow thinking without turning your sprint into a factory simulation.

A simple template you can reuse every sprint

Keep it boring. Boring scales.

• Working days in sprint: ___
• Hours per day (default): ___
• Per person: allocation %, time off (hours), support budget (hours), meeting attendance (hours)
• Context-switch tax (%): ___
• Buffer (%): ___
• Total delivery capacity (hours): ___

Then add one more line that most teams skip:

“What assumption would make this plan wrong?”

If the answer is “Diego won’t actually have 30%,” fix the resourcing issue or reduce scope before the sprint starts. Don’t wait for day eight.

Next sprint, don’t aim to get the number “right.” Aim to keep the method consistent, compare planned capacity to actual availability, and adjust one parameter at a time. That’s how teams build planning credibility without turning agile into theater.