Burndown-Diagramm

Sind die Sprinttage null, ist die Steigung undefiniert, daher scheitert die Aufgabe mit invalid_input und wird nicht abgerechnet.

Eingabevertrag, Antwortform und Fehlerverhalten

Senden Sie per POST einen JSON-Körper mit drei erforderlichen endlichen Zahlen. total_story_points ist das zugesagte Total zum Start; die Aliasse story_points, points und total zeigen auf dasselbe Feld, damit eine Boardspalte ihren Namen behalten kann. sprint_days ist die Länge der Iteration in Tagen; die Aliasse days, duration und sprint werden akzeptiert. elapsed_days ist, wie viele Tage bereits vergangen sind, null in der Planung; die Aliasse elapsed und elapsed_day werden akzeptiert. Jedes Feld darf als JSON-Zahl oder als numerische Zeichenkette ankommen. Fehlende Felder, leere Zeichenketten und nicht endliche Werte scheitern mit invalid_input und nennen das Feld. Ist sprint_days größer als dreihundertsechsundsechzig, scheitert die Anfrage, damit die remaining_per_day-Reihe begrenzt bleibt. Ist total_story_points oder elapsed_days negativ, scheitert die Anfrage. Diese Fehlschläge werden nicht abgerechnet. Bei erfolgreicher Prüfung wiederholt der Körper die drei Eingaben, meldet daily_burn, remaining_ideal am verstrichenen Tag (nach dem letzten Sprinttag auf null geklemmt), completed_ideal als Komplement, progress_percent als verstrichen durch Sprint skaliert auf hundert und gedeckelt bei hundert, days_remaining, remaining_per_day als Liste von Paaren day und remaining von Tag null bis zum letzten Sprinttag, und eine formula-Zeichenkette, die die Identität wiederholt. Beispiel: einhundert Story Points, zehn Sprinttage und vier verstrichene Tage ergeben daily_burn zehn, remaining_ideal sechzig, completed_ideal vierzig, progress_percent vierzig und elf remaining_per_day-Zeilen von einhundert bis null. Kombinieren Sie das JSON mit Ihrer eigenen tatsächlichen Restreihe, wenn Sie die rote Linie neben der Leitlinie brauchen; dieser Endpunkt berechnet nur die Ideallinie.

Wo ein Burndown-Diagramm-Rechner seinen Nutzen verdient

Scrum Master nutzen einen Burndown-Diagramm-Rechner, wenn das Board bereits zugesagte Punkte und Kalendertage zeigt und dieselbe Leitlinie gebraucht wird, die die Stand-up-Folie drucken wird, ohne ein Projektwerkzeug für eine Drei-Zahlen-Identität zu öffnen. Ungültige Eingabe wird nicht abgerechnet. Programmverantwortliche rechnen remaining_ideal je Squad neu, damit ein Portfolioreview vergleichen kann, wie weit jeder Sprint am selben verstrichenen Tag verbrannt haben sollte, mit einer gemeinsamen Rundungsregel. Finanzpartner, die die Lieferung gegen Story-Point-Burn besetzen, nehmen total_story_points, sprint_days und elapsed_days aus dem Planungsblatt und verankern remaining_ideal in einem Modell, das keine proprietäre Tracker-API aufrufen darf. Das ist eine andere Suche und eine andere Aufgabe als die Berechnung von Velocity, Cycle Time oder Earned Value: jene Kennzahlen brauchen abgeschlossene Historie oder Geldgewichte, während ein idealer Burndown nur das zugesagte Total, die Sprintdauer und die verstrichenen Tage verwendet. Weil die Implementierung reines Parse der Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Grundpreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz. Halten Sie sprint_days streng positiv, das zugesagte Total und die verstrichenen Tage nicht negativ, verankern Sie die remaining_per_day-Reihe in Tests, und Sie erhalten einen reproduzierbaren idealen Burndown für Dashboards, LMS-Plugins und Edge-Worker, ohne eine eigene Projektverfolgungs-Engine aufzustellen.