Team-Sprint-Kapazität
Fünf Personen über 10 Arbeitstage zu 8 Stunden täglich mit einem Fokusfaktor von 0,7 haben 400 Bruttostunden und 280 Stunden echte Sprint-Kapazität; die übrigen 120 gehen in Meetings und Unterbrechungen. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Mitarbeiterzahl
- 5
- Arbeitstage
- 10
- Stunden pro Tag
- 8
- Fokusfaktor
- 0,7
- Personentage
- 50
- Bruttostunden
- 400
- Kapazitätsstunden
- 280
- Kapazität in Personentagen
- 35
Sprint-Kapazität ist die realistische Arbeitsmenge, die ein Team in einer festen Iteration zusagen kann, gemessen in Stunden nach Abzug von Meetings, Unterbrechungen und teilweiser Verfügbarkeit. Scrum Master, Engineering Manager und Delivery Leads brauchen eine transparente arithmetische Basis, bevor sie Stories auf das Sprint-Board ziehen oder geplante Last mit historischer Velocity vergleichen. Dieser Team-Sprint-Kapazitätsrechner nimmt Kopfzahl (oder Vollzeitäquivalente), Arbeitstage im Sprint, nominale Stunden pro Person und Tag sowie einen Fokus- oder Verfügbarkeitsfaktor zwischen null und eins entgegen und liefert Bruttostunden, Kapazitätsstunden, Personentage, Kapazitäts-Personentage und Overhead-Stunden samt kurzer Formelzeichenkette.
Was Sprint-Kapazität bedeutet und wie die Formel funktioniert
Agile Teams haben selten einhundert Prozent der Kalenderzeit für zugesagte Backlog-Elemente. Feiertage verringern die Arbeitstagezahl, Teilzeitmitglieder senken die effektive Kopfzahl, und Meetings, Support-Rotation sowie Kontextwechsel verbrauchen einen Teil jedes Tages. Das Standard-Planungsmodell multipliziert vier Treiber: wie viele Personen (oder FTE) im Team sind, wie viele Arbeitstage in das Sprint-Fenster fallen, wie viele nominale Stunden jede Person pro Tag anbieten kann, und einen Fokus- oder Verfügbarkeitsfaktor, der die nominale Zeit auf den für Sprint-Arbeit reservierten Anteil skaliert.
Bruttostunden entsprechen Kopfzahl mal Arbeitstage mal Stunden pro Tag. Kapazitätsstunden entsprechen Bruttostunden mal Fokusfaktor. Personentage entsprechen Kopfzahl mal Arbeitstage; Kapazitäts-Personentage wenden denselben Fokusfaktor an, damit Sie in Tageseinheiten planen können, wenn Ihr Board Stories in Personentagen statt in Stunden führt.
Overhead-Stunden sind die Differenz zwischen brutto und Kapazität — die Meetings und ungeplante Arbeit, die der Fokusfaktor bereits entfernt hat. Beispiel: fünf Personen, zehn Arbeitstage, acht Stunden pro Tag und ein Fokusfaktor von null Komma sieben ergeben vierhundert Bruttostunden und zweihundertachtzig Kapazitätsstunden, mit einhundertzwanzig Overhead-Stunden und fünfunddreißig Kapazitäts-Personentagen. Der Rechner ersetzt keine Story-Point-Velocity-Prognose; er ist die Stundenbudget-Obergrenze, gegen die Sie die geschätzte Restarbeit vergleichen.
Bruchteilige Kopfzahl ist für Teilzeitbeitragende erlaubt (zum Beispiel vier Komma fünf FTE). Der Fokusfaktor muss zwischen null und eins inklusive liegen: senden Sie null Komma sieben für siebzig Prozent Fokus, nicht siebzig.
Wo ein Team-Sprint-Kapazitätsrechner seinen Nutzen entfaltet
Scrum Master und Agile Coaches nutzen einen Team-Sprint-Kapazitätsrechner in der Sprint-Planung, um ein transparentes Stundenbudget festzulegen, bevor das Team Backlog-Elemente zieht — besonders wenn sich die Kopfzahl mitten im Quartal ändert oder Feiertage Tage aus einem zweiwöchigen Rhythmus schneiden. Engineering Manager vergleichen Kapazitätsstunden über Squads hinweg, wenn sie Staffing für einen Release Train ausbalancieren, und Product Owner sehen, warum ein kleineres oder teilweise verfügbares Team nicht dieselbe Zusage wie im letzten Sprint tragen kann.
PMO- und Delivery-Reporting-Tools automatisieren dieselbe Formel in Portfolio-Notebooks, sodass jedes Team Bruttostunden, Kapazitätsstunden und Overhead nebeneinander für die Prüfung speichert. Trainingskurse und LMS-Plugins brauchen ein deterministisches Orakel, das einen Fokusfaktor von siebzig oder eine Null-Kopfzahl ablehnt, statt still NaN auszugeben, das ein fehlerhafter Bewerter als Erfolg werten könnte. Fehlgeschlagene Validierung wird nicht abgerechnet.
Anwendungsfälle
Stundenbudget in der Sprint-Planung
Berechnen Sie Kapazitätsstunden aus Teamgröße, Arbeitstagen, Tagesstunden und Fokusfaktor, bevor das Team Stories zusagt, damit die geplante Last in einem transparenten Budget bleibt.
Anpassungen bei Feiertagen und Teilzeit
Berechnen Sie die Kapazität neu, wenn Feiertage Arbeitstage verkürzen oder bruchteile FTE die Kopfzahl senken, und zeigen Sie Overhead-Stunden neben den angepassten Kapazitäts-Personentagen.
Multi-Team-Portfolio-Reporting
Automatisieren Sie dieselbe Kapazitätsformel über Squads in Notebooks oder Delivery-Tools, damit Finance und PMO Brutto- versus fokusbereinigte Stunden auf einem Audit-Trail vergleichen.
Häufige Fragen
Was ist der Fokusfaktor?
Ein Bruchteil der nominalen Zeit, die nach Meetings, Support und Unterbrechungen für zugesagte Sprint-Arbeit verfügbar ist. Verwenden Sie 0.7 für 70 % Fokus — nicht 70. Werte müssen zwischen 0 und 1 inklusive liegen.
Darf die Kopfzahl bruchteilig sein?
Ja. Bruchteilige Kopfzahl modelliert Teilzeitbeitragende oder geteilte FTE (zum Beispiel 4.5). Die Kopfzahl muss weiterhin strikt größer als null sein.
Ersetzt dies Story-Point-Velocity?
Nein. Kapazitätsstunden sind die Obergrenze des Zeitbudgets. Story-Point-Velocity prognostiziert, wie viel Backlog das Team üblicherweise abschließt; nutzen Sie beides zusammen in der Planung.
Wie berechnet man die Sprint-Kapazität in Stunden?
Multiplizieren Sie Kopfzahl, Arbeitstage, Stunden pro Tag und Fokusfaktor. Fünf Personen, 10 Tage, 8 Stunden und 0,7 ergeben 280 Kapazitätsstunden von 400 Bruttostunden oder 35 Kapazitäts-Personentage.
Gebe ich für 70 % Fokus 70 oder 0,7 ein?
Geben Sie 0,7 ein. Der Fokusfaktor ist ein Anteil zwischen 0 und 1, daher wird 70 abgelehnt, statt als Prozentsatz gelesen zu werden. Die Grenzwerte 0 und 1 sind zulässig.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem 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)Beispiel-Anfrage
{
"headcount": 5,
"working_days": 10,
"hours_per_day": 8,
"focus_factor": 0.7
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "biz.team_capacity_sprint",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Ungültige Eingaben scheitern mit invalid_input und werden nicht abgerechnet.
Eingabevertrag, Antwortform und Fehlerverhalten
Ein Fokusfaktor außerhalb von null bis eins scheitert ebenfalls — senden Sie nicht siebzig für siebzig Prozent. Kombinieren Sie das numerische Ergebnis mit eigenen Story-Point-Schätzungen und WIP-Limits außerhalb dieses Endpunkts; der Rechner liefert nur das Stunden- und Personentag-Budget und erzeugt keine Jira-Tickets, Board-Commits oder Burndown-Diagramme. Senden Sie per POST einen JSON-Body mit vier erforderlichen endlichen Zahlen: headcount (Personen oder FTE, strikt positiv), working_days (positive Anzahl Arbeitstage im Sprint, ohne Wochenenden und bekannte Feiertage), hours_per_day (positive nominale produktive Stunden pro Person und Tag, üblicherweise sechs bis acht) und focus_factor (Verfügbarkeit oder Fokus als Bruch im geschlossenen Intervall von null bis eins). Jedes Feld darf als JSON-Zahl oder numerische Zeichenkette ankommen; fehlende Felder, leere Strings, nicht endliche Werte sowie nicht positive headcount, Arbeitstage oder Stunden pro Tag scheitern mit invalid_input und benennen das Feld. Bei Erfolg spiegelt der Body die vier Treiber und liefert person_days, gross_hours, capacity_hours, capacity_person_days, overhead_hours sowie eine Formelzeichenkette, die capacity_hours gleich headcount mal working_days mal hours_per_day mal focus_factor festhält. Halten Sie Einheiten über eine Planungsserie konsistent: wenn Sie hours_per_day als sechs für Deep-Focus-Engineering-Tage modellieren, verwenden Sie dieselbe Konvention, wenn Sie später capacity_hours mit den verbleibenden Schätzstunden vergleichen.
Wo ein Team-Sprint-Kapazitätsrechner seinen Nutzen entfaltet
Weil die Implementierung reines Parse-Tier-A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Basispreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz. Halten Sie Anfragen klein, pinnen Sie gerundete Kapazitätsfelder in Tests, und Sie erhalten reproduzierbare Sprint-Budgets für Planungszeremonien, Edge Worker und CI-Checks, ohne einen vollständigen Projektportfolio-Stack aufzubauen.
Technische Fragen
Wie wird die Team-Sprint-Kapazität berechnet?
capacity_hours = headcount × working_days × hours_per_day × focus_factor. Senden Sie positive headcount, Arbeitstage und Stunden pro Tag sowie einen Fokusfaktor zwischen 0 und 1; die API liefert auch Personentage, Bruttostunden und Overhead-Stunden.
Was kostet der Team-Sprint-Kapazitätsrechner?
Das Browser-Tool ist kostenlos. API-Anfragen nutzen Prepaid-KIT-Guthaben zu $0.002 pro erfolgreichem Aufruf; ungültige Eingaben werden nicht abgerechnet.