ForHosting KIT · Finance & money

Team sprint capacity calculator

Five people over 10 working days at 8 hours a day with a 0.7 focus factor have 400 gross hours and 280 hours of real sprint capacity; the other 120 go to meetings and interruptions. Free in your browser.

Free
Runs in your browser
No sign-up
Your data stays on your device

Run — free How it works & API

Use it from WebAPIEmailTelegramApp soon

Worked example

If you enter

Headcount: 5
Working days: 10
Hours per day: 8
Focus factor: 0.7

You get

Person days: 50
Gross hours: 400
Capacity hours: 280
Capacity person days: 35

Sprint capacity is the realistic amount of work a team can commit to in a fixed iteration, measured in hours after meetings, interrupts, and partial availability are discounted. Scrum masters, engineering managers, and delivery leads need a transparent arithmetic baseline before they pull stories into a sprint board or compare planned load against historical velocity. This team sprint capacity calculator accepts headcount (or full-time equivalents), working days in the sprint, nominal hours per person per day, and a focus or availability factor between zero and one, then returns gross hours, capacity hours, person-days, capacity person-days, and overhead hours with a short formula string.

What sprint capacity means and how the formula works

Agile teams rarely have one hundred percent of calendar time for committed backlog items. Holidays shrink the working-day count, part-time members reduce effective headcount, and meetings, support rotation, and context switching consume a fraction of every day. The standard planning model multiplies four drivers: how many people (or FTE) are on the team, how many working days fall inside the sprint window, how many nominal hours each person can offer per day, and a focus or availability factor that scales nominal time down to the share reserved for sprint work.

Gross hours equal headcount times working days times hours per day. Capacity hours equal gross hours times the focus factor. Person-days equal headcount times working days; capacity person-days apply the same focus factor so you can plan in day units when your board tracks stories in person-days rather than hours.

Overhead hours are the difference between gross and capacity—the meetings and unplanned work already removed by the focus factor. Example: five people, ten working days, eight hours per day, and a focus factor of zero point seven yield four hundred gross hours and two hundred eighty capacity hours, with one hundred twenty overhead hours and thirty-five capacity person-days. The calculator does not replace story-point velocity forecasting; it is the hour-budget ceiling against which you compare estimated remaining work.

Fractional headcount is allowed for part-time contributors (for example four point five FTE). Focus factor must sit between zero and one inclusive: send zero point seven for seventy percent focus, not seventy.

Where a team sprint capacity calculator earns its keep

Scrum masters and agile coaches use a team sprint capacity calculator at sprint planning to set a transparent hour budget before the team pulls backlog items, especially when headcount changes mid-quarter or holidays carve days out of a two-week cadence. Engineering managers compare capacity hours across squads when balancing staffing for a release train, and product owners see why a smaller or partially available team cannot absorb the same commitment as last sprint.

PMO and delivery-reporting tools automate the same formula inside portfolio notebooks so every team stores gross hours, capacity hours, and overhead side by side for audit. Training courses and LMS plugins need a deterministic oracle that rejects a focus factor of seventy or a zero headcount instead of silently emitting NaN that a buggy grader might treat as success. Failed validation does not consume balance.

Keep requests small, pin the rounded capacity fields in tests, and you get reproducible sprint budgets for planning ceremonies, edge workers, and CI checks without standing up a full project-portfolio stack of your own.

What you can do with it

Sprint planning hour budget

Compute capacity hours from team size, working days, daily hours, and focus factor before the team commits stories so planned load stays inside a transparent budget.

Holiday and part-time adjustments

Recalculate capacity when holidays shrink working days or fractional FTE reduces headcount, and show overhead hours next to the adjusted capacity person-days.

Multi-team portfolio reporting

Automate the same capacity formula across squads in notebooks or delivery tools so finance and PMO compare gross versus focus-adjusted hours on one audit trail.

FAQ

What is the focus factor?

A fraction of nominal time available for committed sprint work after meetings, support, and interrupts. Use 0.7 for 70% focus—not 70. Values must be between 0 and 1 inclusive.

Can headcount be fractional?

Yes. Fractional headcount models part-time contributors or shared FTE (for example 4.5). Headcount must still be strictly greater than zero.

Does this replace story-point velocity?

No. Capacity hours are the time budget ceiling. Story-point velocity forecasts how much backlog the team usually finishes; use both together at planning.

How do you calculate sprint capacity in hours?

Multiply headcount by working days, hours per day and the focus factor. Five people, 10 days, 8 hours and 0.7 give 280 capacity hours out of 400 gross hours, or 35 capacity person-days.

Do I enter 70 or 0.7 for a 70% focus factor?

Enter 0.7. The focus factor is a fraction between 0 and 1, so 70 is rejected rather than read as a percentage. Both extremes, 0 and 1, are allowed.

Related tools

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/biz/team-capacity-sprint

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/biz/team-capacity-sprint \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"headcount":5,"working_days":10,"hours_per_day":8,"focus_factor":0.7}'

const res = await fetch("https://api.kit.forhosting.com/biz/team-capacity-sprint", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "headcount": 5,
    "working_days": 10,
    "hours_per_day": 8,
    "focus_factor": 0.7
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/biz/team-capacity-sprint",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "headcount": 5,
    "working_days": 10,
    "hours_per_day": 8,
    "focus_factor": 0.7
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/biz/team-capacity-sprint", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"headcount":5,"working_days":10,"hours_per_day":8,"focus_factor":0.7}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"headcount":5,"working_days":10,"hours_per_day":8,"focus_factor":0.7}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/biz/team-capacity-sprint", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "headcount": 5,
  "working_days": 10,
  "hours_per_day": 8,
  "focus_factor": 0.7
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "biz.team_capacity_sprint",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Technical notes

Invalid inputs fail with invalid_input and are not billed.

Input contract, response shape, and error behaviour

A focus factor outside zero to one also fails—do not send seventy for seventy percent. POST a JSON body with four required finite numbers: headcount (people or FTE, strictly positive), working_days (positive count of working days in the sprint, excluding weekends and known holidays), hours_per_day (positive nominal productive hours per person per day, commonly six to eight), and focus_factor (availability or focus as a fraction in the closed interval from zero to one). Each field may arrive as a JSON number or as a numeric string; missing fields, empty strings, non-finite values, and non-positive headcount, working days, or hours per day fail with invalid_input naming the field. On success the body echoes the four drivers and returns person_days, gross_hours, capacity_hours, capacity_person_days, overhead_hours, and a formula string restating capacity_hours equals headcount times working_days times hours_per_day times focus_factor. Pair the numeric result with your own story-point estimates and WIP limits outside this endpoint; the calculator returns the hour and person-day budget only and does not emit Jira tickets, board commits, or burndown charts. Keep units consistent across a planning series: if you model hours per day as six for deep-focus engineering days, use the same convention when you later compare capacity_hours to remaining estimate hours.

Technical questions

How is team sprint capacity calculated?

capacity_hours = headcount × working_days × hours_per_day × focus_factor. Send positive headcount, working days, and hours per day, plus a focus factor between 0 and 1; the API also returns person-days, gross hours, and overhead hours.

What does the team sprint capacity calculator cost?

The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.

Read the full KIT documentation →

Run — free