Sprint-Burndown
Bei 80 zugesagten Punkten, 32 erledigten und 6 verbleibenden Tagen braucht das Team 8 Story Points pro Tag, um die offenen 48 zu schaffen. Vergleichen Sie dieses Tempo mit dem, was Ihr Team tatsächlich liefert. 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
- Story Points gesamt
- 80
- Vergangene Tage
- 4
- Verbleibende Tage
- 6
- Abgeschlossene Punkte
- 32
- Verbleibende Punkte
- 48
- Erforderliche tägliche Velocity
- 8
Dieser Sprint-Burndown-Rechner macht aus dem aktuellen Iterationsstand eine konkrete Planungskennzahl: die Story Points, die pro verbleibendem Tag abgeschlossen werden müssen, um den Termin einzuhalten. Geben Sie das ursprüngliche Sprint-Ziel, vergangene und verbleibende Tage sowie bereits abgeschlossene Punkte ein. Das Ergebnis zeigt sowohl den offenen Aufwand als auch die erforderliche Tagesgeschwindigkeit. So können Sie den nötigen Rhythmus mit dem vergleichen, was Ihr Team bis zum Sprintende realistisch liefern kann.
Machen Sie aus dem Burndown-Stand ein klares Tagesziel
Ein Burndown-Diagramm zeigt eine Richtung, beantwortet aber nicht immer die Frage aus der täglichen Abstimmung: Wie schnell muss die restliche Arbeit ab jetzt vorankommen? Der Rechner nimmt die gesamten Story Points des Sprints und zieht die bereits abgeschlossenen Punkte ab. Anschließend teilt er den offenen Aufwand durch die noch verfügbaren Tage.
Die erforderliche Tagesgeschwindigkeit ist damit ein zukunftsgerichtetes Ziel in Story Points pro verbleibendem Tag. Wenn viel Arbeit offen ist und nur wenige Tage bleiben, wird der hohe Zielwert sofort sichtbar, ohne dass Sie eine Trendlinie optisch deuten müssen. Erfassen Sie jeden vergangenen Tag, auch wenn an diesem Tag keine Punkte abgeschlossen wurden, damit die Momentaufnahme den Kalender ehrlich widerspiegelt.
Die verstrichene Zeit erscheint zur Einordnung im Ergebnis; für die Terminberechnung zählen die verbleibenden Tage, weil nur sie noch Liefermöglichkeiten bieten. Nutzen Sie die Kennzahl als Planungssignal und nicht als persönliche Leistungsvorgabe.
Bewerten Sie die nötige Geschwindigkeit im Lieferkontext
Die erforderliche Tagesgeschwindigkeit bezeichnet das rechnerische Tempo, mit dem die offene Schätzung bis zum Termin abgearbeitet werden müsste. Vergleichen Sie sie mit den Story Points, die das Team üblicherweise pro Tag abschließt, mit dem jüngsten Durchsatz, laufenden Arbeiten und bekannten Hindernissen. Liegt der Zielwert deutlich unter einem nachhaltigen Tempo, ist der Sprint rechnerisch weiterhin erreichbar.
Liegt er weit darüber, sollten Sie Menschen nicht zu künstlich höherer Leistung drängen. Prüfen Sie stattdessen, ob sich blockierte Aufgaben lösen lassen, ob Storys ohne Verlust eines wertvollen Ergebnisses geteilt werden können oder ob der Umfang mit der Produktverantwortung neu abgestimmt werden muss. Ein Wert von null bedeutet, dass alle zugesagten Punkte bereits abgeschlossen sind.
Dezimalwerte sind normal: Sie bilden einen Durchschnitt über die restlichen Tage und verlangen nicht täglich den Abschluss eines Story-Anteils. Da Story Points teamspezifisch sind, vergleichen Sie die Kennzahl nur mit Daten desselben Teams und derselben Schätzpraxis.
Verwenden Sie konsistente Angaben und beachten Sie die Termingrenze
Halten Sie die Einheiten in allen Feldern konsistent. Gesamtaufwand und abgeschlossene Arbeit müssen Story Points aus derselben Sprint-Basis verwenden. Für vergangene und verbleibende Zeit muss dieselbe Tagesdefinition gelten, meist geplante Arbeitstage statt Kalendertage.
Aktualisieren Sie abgeschlossene Punkte gemäß der gemeinsamen Definition of Done. Teilweise erledigte Arbeit einzurechnen lässt den Restaufwand kleiner erscheinen, ohne ein lieferbares Ergebnis zu schaffen. Der Rechner weist abgeschlossene Punkte oberhalb des ursprünglichen Gesamtwerts zurück, weil diese Kombination den Restaufwand gegenüber dem angegebenen Ziel nicht beschreibt.
Negative Werte, nicht endliche Zahlen und Tagesbruchteile sind ebenfalls ungültig. Besonders wichtig: Null verbleibende Tage führen zu einem Fehler, da ohne verfügbare Tage keine sinnvolle Tagesrate berechnet werden kann. Bewerten Sie dann direkt das Sprintergebnis, statt eine unendliche oder undefinierte Kennzahl zu verwenden.
Anwendungsfälle
Bereiten Sie das Daily vor
Berechnen Sie das ab heute nötige Tempo und bringen Sie ein konkretes Signal zum Lieferrisiko in die Teambesprechung ein.
Bewerten Sie eine Umfangsänderung
Rechnen Sie nach dem Entfernen oder Teilen von Arbeit erneut und prüfen Sie, ob das neue Ziel zu einem nachhaltigen Tempo passt.
Häufige Fragen
Was bedeutet erforderliche Tagesgeschwindigkeit?
Sie ist der offene Story-Point-Wert geteilt durch die verbleibenden Tage: der durchschnittliche tägliche Abschluss, der für das angegebene Sprint-Ziel nötig ist.
Warum werden vergangene Tage benötigt, wenn die Formel restliche Tage nutzt?
Die vergangenen Tage bewahren im Ergebnis die vollständige Sprint-Momentaufnahme und helfen Ihnen, den eingegebenen Zeitplan zu prüfen. Das künftige Tempo hängt von den noch verfügbaren Möglichkeiten ab.
Was geschieht, wenn kein Tag mehr verbleibt?
Die Berechnung liefert einen Eingabefehler, weil sich offene Arbeit über null Tage nicht in eine sinnvolle Tagesgeschwindigkeit umrechnen lässt.
Dürfen abgeschlossene Punkte den ursprünglichen Gesamtwert überschreiten?
Nein. Der Rechner weist diese Eingabe zurück, weil er Restarbeit gegenüber dem angegebenen Gesamtziel misst. Wurde der Umfang offiziell erweitert, verwenden Sie den aktualisierten Gesamtwert.
Was tun, wenn die erforderliche Tagesgeschwindigkeit zu hoch ist?
Setzen Sie niemanden unter Druck, mehr Output zu erzeugen. Prüfen Sie stattdessen, ob sich ein blockiertes Element lösen lässt, ob Stories sinnvoll geteilt werden können oder ob Sie den Umfang mit dem Product Owner neu verhandeln.
Was passiert, wenn keine Tage mehr übrig sind?
Null verbleibende Tage werden abgelehnt, weil sich dann keine Tagesgeschwindigkeit berechnen lässt: Es gibt keinen Tag mehr, auf den sich die offenen Punkte verteilen könnten.
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/burndown-remaining-estimate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"total_story_points":80,"days_elapsed":4,"days_remaining":6,"points_completed":32}'const res = await fetch("https://api.kit.forhosting.com/biz/burndown-remaining-estimate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"total_story_points": 80,
"days_elapsed": 4,
"days_remaining": 6,
"points_completed": 32
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/biz/burndown-remaining-estimate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"total_story_points": 80,
"days_elapsed": 4,
"days_remaining": 6,
"points_completed": 32
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/biz/burndown-remaining-estimate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"total_story_points":80,"days_elapsed":4,"days_remaining":6,"points_completed":32}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"total_story_points":80,"days_elapsed":4,"days_remaining":6,"points_completed":32}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/biz/burndown-remaining-estimate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"total_story_points": 80,
"days_elapsed": 4,
"days_remaining": 6,
"points_completed": 32
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "biz.burndown_remaining_estimate",
"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
Verwenden Sie konsistente Angaben und beachten Sie die Termingrenze
Für Automatisierungen liefert die API normalisierte Eingaben, offene Punkte und Tagesgeschwindigkeit als stabiles JSON-Objekt. Jeder Aufruf kostet $0.002; dieselbe deterministische Rechnung läuft ohne Netzwerk im Browser.
Integrationsbeispiele
Ergänzen Sie die Sprint-Berichte
Verwenden Sie das deterministische API-Ergebnis in einem Dashboard, Statusbericht oder automatischen Risikotest.
Technische Fragen
Was kostet eine API-Anfrage?
Jede API-Anfrage kostet $0.002. Die Berechnung im Browser verwendet dieselbe deterministische Logik und kann lokal ausgeführt werden.