Ein agiles Burndown-Chart ist ein einfaches Diagramm, das die verbleibende Arbeit über die Zeit abbildet. Das ist alles. Sieh es nicht als komplexes Reporting-Tool, sondern als Vitalzeichen-Monitor deines Sprints – es zeigt dir live und ehrlich, ob ihr auf Kurs seid, pünktlich fertig zu werden.
Dein Sprint auf einen Blick
Machen wir es konkret. Dein Team startet einen zweiwöchigen Sprint. Ihr habt ein Backlog mit Tickets, jedes mit einer Schätzung in Story Points. Die Summe dieser Punkte ist die Arbeit, zu der ihr euch verpflichtet habt. Das Burndown-Chart ist einfach ein Bild davon, wie dieser Arbeitsberg Tag für Tag schrumpft.
Sobald dein Team Tickets auf „Done“ schiebt, ist diese Arbeit „verbrannt“. Das Chart bildet genau diesen Fortschritt ab. Es geht nicht um Mikromanagement; es geht darum, dem Team einen gemeinsamen Blick auf den eigenen Fortschritt zu geben und eine Single Source of Truth zu schaffen, die sich nicht falsch deuten lässt.
Das Grundprinzip verstehen
Im Kern beantwortet ein Burndown-Chart eine einzige Frage, und zwar schonungslos ehrlich: „Schaffen wir alles bis zur Deadline?“ Dafür reichen zwei Linien, die die ganze Geschichte erzählen.
- Die Ideallinie: eine gerade Diagonale, die ein perfektes, gleichmäßiges Arbeitstempo abbildet. Sie zeigt, wie der Fortschritt aussähe, wenn dein Team jeden einzelnen Tag exakt gleich viel erledigen würde. Sie ist der Maßstab.
- Die Ist-Linie: Das ist die Realität. Sie verläuft im Zickzack, je nachdem, ob dein Team Arbeit abschließt, auf Hindernisse stößt oder neuen Scope hereinholt. Diese Linie verfolgt die tatsächlich noch offene Arbeit.
Wenn deine Ist-Linie an der Ideallinie entlangläuft oder darunter liegt, steht ihr gut da. Liegt sie dauerhaft darüber, ist das dein Frühwarnsignal – ein Zeichen, dass ihr in Verzug geratet und das Team darüber reden muss, warum.
Ein Burndown-Chart macht Fortschritt greifbar. Es verwandelt abstrakte Begriffe wie „Velocity“ und „verbleibende Arbeit“ in ein konkretes Bild, das alle – vom Dev-Team bis in die Chefetage – in etwa fünf Sekunden verstehen.
Deshalb setzen Teams, denen Transparenz und Planbarkeit wichtig sind, so stark darauf. Statt auf ein wöchentliches Meeting zu warten, um von einem Problem zu erfahren, bekommst du mit dem Chart tägliches Feedback. Es stößt die richtigen Gespräche jetzt an, solange noch Zeit zum Gegensteuern ist. Damit ihr das Beste aus diesen Charts herausholt, braucht ihr natürlich ein gemeinsames Vokabular.
Die wichtigsten Bestandteile eines agilen Burndown-Charts
Hier ein kurzer Überblick, was du auf jedem gängigen Burndown-Chart siehst und was dir jedes Element verrät.
| Bestandteil | Beschreibung | Was es dir sagt |
|---|---|---|
| X-Achse (Zeit) | Die horizontale Achse zeigt die Dauer des Sprints, meist in Tagen. | Wie viel Zeit verbraucht ist und wie viel noch bleibt. |
| Y-Achse (Arbeit) | Die vertikale Achse zeigt die verbleibende Arbeit, gemessen in Story Points oder Stunden. | Die gesamte Arbeitslast zu jedem Zeitpunkt im Sprint. |
| Ideallinie | Die gerade Linie zeigt ein perfektes Abschlusstempo, mit dem die Deadline gehalten wird. | Dein Maßstab für idealen, ungestörten Fortschritt. |
| Ist-Linie | Eine Linie, die die tatsächlich verbleibende Arbeit verfolgt, während das Team Aufgaben abschließt. | Ob ihr vor dem Plan, dahinter oder genau im Plan liegt. |
Diese vier einfachen Bestandteile ergeben zusammen einen aussagekräftigen Statusbericht auf einen Blick, ohne dass jemand ein einziges Wort schreiben muss.
Was ein Burndown-Chart wirklich zeigt
Ein Burndown-Chart ist weit mehr als nur ein weiteres Diagramm im Projektmanagement-Dashboard. Es ist die lebendige Geschichte deines Sprints: Es verwandelt abstrakte Größen wie „verbleibende Arbeit“ in eine konkrete, sichtbare Kennzahl, die tägliche Entscheidungen lenkt und alle auf dasselbe Ziel ausrichtet.
Seine Stärke liegt in seiner Einfachheit. Indem es die offene Arbeit (auf der vertikalen Achse) gegen die Zeit (auf der horizontalen Achse) aufträgt, liefert es dir sofort eine Prognose. Es geht nicht darum, Erledigtes zu tracken; es ist ein Werkzeug mit Blick nach vorn, das die wichtigste Frage jedes Sprints beantwortet: „Schaffen wir es bei unserem aktuellen Tempo?“
Dieses einfache Bild erzeugt ein starkes Gefühl gemeinsamer Dringlichkeit. Wenn das ganze Team sieht, wie die Ist-Linie von der Ideallinie abweicht, erzwingt das vorausschauende Gespräche. Es ist der Unterschied zwischen einem Team, das seine Kapazität rät, und einem Team, das seine Velocity wirklich versteht.
Ein Frühwarnsystem für dein Projekt
Sieh das Burndown-Chart als Frühwarnsystem deines Projekts. Lange bevor jemand eine „Wie ist der Stand?“-Mail schicken muss, signalisiert das Chart bereits Probleme. Zwei Tage am Stück eine flache Linie? Das ist kein Datenfehler, sondern ein Warnsignal. Es bedeutet, dass es ein Hindernis oder eine massiv unterschätzte Aufgabe gibt, die im Daily Stand-up angegangen werden muss, und zwar jetzt.
Genau wegen dieser diagnostischen Funktion wurde es zu einem Grundpfeiler agiler Praktiken.
Die Hauptaufgabe des Burndown-Charts ist es, Probleme sichtbar zu machen, bevor sie einen Sprint entgleisen lassen. Es ist ein Werkzeug für laufendes, datengestütztes Gegensteuern, kein Reporting im Nachhinein.
Wenn Teams das verinnerlichen, wechseln sie von einer reaktiven zu einer vorausschauenden Haltung. Probleme sind dann keine Überraschungen am Sprintende mehr, sondern Dinge, die das Team erkennt und gemeinsam angeht, während sie entstehen.
Von den Scrum-Anfängen zum unverzichtbaren Werkzeug
Das Burndown-Chart tauchte Anfang der 2000er als echter Durchbruch auf, als Teams begannen, das Scrum-Framework einzuführen. Ken Schwaber und Jeff Sutherland stellten es um 2001 vor, um Teams einen denkbar einfachen Weg zu geben, ihren Fortschritt sichtbar zu machen. Ein Team, das sich in einem 5-tägigen Sprint 80 Story Points vornimmt, sieht damit sofort, dass seine ideale Burn-Rate bei 16 Punkten pro Tag liegt. Diese Sichtbarkeit zahlte sich aus: Eine wegweisende Studie von 2015 ergab, dass Teams mit Burndown-Charts schon in ihren ersten drei Iterationen eine 25 % bessere Termintreue bei Sprints erreichten.
Diese Geschichte ist wichtig, weil sie den eigentlichen Zweck des Charts zeigt: Klarheit und Planbarkeit. Das Chart ist nur eine von vielen Kennzahlen, die Teams besser machen. Um die Leistung deines Teams wirklich zu verstehen, lohnt sich ein Blick auf weitere, ergänzende Kennzahlen für agile Softwareentwicklung, die echte Verbesserungen bringen.
Letztlich zeigt das Chart den Lieferrhythmus eines Teams. Es hilft einem Team, seine eigenen Muster zu erkennen, seine echte Kapazität zu verstehen und beim nächsten Mal klügere Zusagen zu machen. Es geht weniger um die Linie im Diagramm als um die Gespräche und das Verhalten, die sie anstößt.
Ein Burndown-Chart ist mehr als ein simples Diagramm; es ist eine Geschichte über deinen Sprint, die sich in Echtzeit entfaltet. Damit es dir etwas bringt, musst du lernen, diese Geschichte zu lesen – den Fortschritt, die Hindernisse und den Schwung des Teams. Wer die typischen Muster erkennt, macht aus ein paar Linien in einem Chart ein echtes Gespräch, das den Sprint auf Kurs hält.
Die ganze Geschichte läuft auf zwei Linien hinaus: die Ideallinie und die Ist-Linie. Die Ideallinie ist der gerade, berechenbare Weg zu „Done“ und zeigt ein perfektes, gleichmäßiges Tempo. Die Ist-Linie zeigt, was Tag für Tag wirklich passiert. Der Abstand zwischen beiden – oder sein Fehlen – sagt dir alles.
Diese Übersicht zeigt, wie ein Burndown-Chart Zeit, verbleibende Arbeit sowie Ideal- und Ist-Linie miteinander verbindet.
Wie du siehst, entsteht seine eigentliche Stärke aus dem Vergleich des perfekten Plans (ideal) mit der unordentlichen Realität der Entwicklung (tatsächlich), um zu sehen, wohin es geht.
Szenario 1: Das Team hinkt hinterher
Dieses Muster wirst du am häufigsten sehen. Wenn die Ist-Linie dauerhaft über der Ideallinie liegt, ist das ein klares Signal, dass dein Team in Verzug gerät.
- So sieht es aus: Die blaue Ist-Linie liegt länger als ein, zwei Tage hartnäckig über der grauen Ideallinie.
- Was es bedeutet: Das Team schließt Arbeit nicht im geplanten Tempo ab. Vielleicht wurden Aufgaben unterschätzt, jemand ist blockiert, oder Leute werden in ungeplante Arbeit hineingezogen.
- So reagierst du: Keine Panik. Das ist ein Anlass, im nächsten Daily Stand-up Fragen zu stellen. Ist eine Aufgabe viel schwieriger als gedacht? Wartet jemand auf ein Code-Review? Das Chart ist dein Stichwort, genauer hinzusehen und den Engpass zu beseitigen, bevor es zu spät ist.
Wer das ignoriert, lässt Sprints scheitern. Das Chart ist kein Urteil, sondern ein Gesprächsanlass.
Szenario 2: Der gefürchtete Scope Creep
Ihr kommt gut voran, und plötzlich springt die Ist-Linie nach oben. Das ist kein Fehler. Das ist Scope Creep in sichtbarer Form.
Scope Creep entsteht, wenn neue Arbeit in den Sprint aufgenommen wird, nachdem er schon begonnen hat. Der plötzliche Ausschlag der Ist-Linie zeigt, dass die gesamte Arbeitsmenge gerade gestiegen ist – deine Ziellinie rückt weiter weg.
Wenn du das siehst, ist das ein kritischer Moment für Product Owner und Scrum Master. Es erzwingt ein sofortiges und notwendiges Gespräch: Wenn wir das Neue hinzunehmen, was lassen wir dafür weg? Ein Burndown-Chart macht es unmöglich, diesen Zielkonflikt zu übersehen.
Szenario 3: Der plötzliche Steilabfall
Ein steiler, senkrechter Abfall der Ist-Linie ist meist ein gutes Zeichen. Er bedeutet, dass eine große Aufgabe oder ein Bündel kleinerer Aufgaben auf einmal auf „Done“ gesetzt wurde.
- So sieht es aus: Ein flaches Plateau, gefolgt von einer steilen Klippe in der Ist-Linie.
- Was es bedeutet: Das Team hat gerade einen wesentlichen Teil der Sprint-Zusage erledigt, oft eine große User Story, an der tagelang gearbeitet wurde.
- Aber Achtung: Auch wenn es sich gut anfühlt, kann eine riesige „Klippe“ ganz am Ende des Sprints ein Warnsignal sein. Oft heißt das, dass das Team Arbeit nicht in ausreichend kleine Stücke zerlegt, was am letzten Tag zu einem riskanten Alles-oder-nichts-Endspurt führt.
Genau wegen dieser Muster lohnt es sich, konsequent zu tracken. Die Sichtbarkeit zahlt sich aus. Eine Umfrage von 2022 ergab, dass Teams mit Burndown-Charts 42 % weniger Scope-Änderungen mitten im Sprint hatten, weil diese Muster sofortiges Gegensteuern erzwangen. Und den 65 % der agilen Fortune-500-Unternehmen, die Tools wie Jira nutzen, erlauben diese historischen Daten, künftige Sprint-Zusagen mit gutem Gewissen um bis zu 20 % zu erhöhen. Mehr Details findest du in Atlassians Auswertung zu diesen agilen Erkenntnissen.
Dein erstes Burndown-Chart Schritt für Schritt
Dein erstes Burndown-Chart zu bauen ist keine komplizierte Data-Science-Übung. Es geht eigentlich nur um diszipliniertes, tägliches Tracken. Ob du eine einfache Tabelle oder ein schickes Projektmanagement-Tool nutzt, die Grundlagen sind dieselben. Gehen wir es durch.
Es geht darum, ein Bild zu schaffen, das sofort nützlich ist. Sieh es nicht als Kennzahl, sondern als Anzeigetafel für deinen Sprint – sie ist nur dazu da, dem Team zu zeigen, ob es gerade gewinnt.
Schritt 1: Die Arbeit festlegen und schätzen
Bevor du irgendetwas tracken kannst, musst du wissen, woran du dich misst. Alles beginnt mit einem soliden Sprint-Backlog.
Zuerst muss sich das Team auf den gesamten Scope des Sprints einigen. Das ist die Sammlung aller User Stories, Aufgaben und Bugfixes, die ihr euch gemeinsam vorgenommen habt. Die Best Practices für die Sprint-Planung sind hier Pflicht; sie sorgen für ein realistisches, erreichbares Ziel.
Als Nächstes braucht jeder einzelne dieser Einträge eine Schätzung. Die meisten Teams nutzen Story Points, um Aufwand, Komplexität und Risiko zusammen zu erfassen. Andere arbeiten mit Idealstunden. Die konkrete Einheit ist weniger wichtig als Konsistenz. Zähle alle Schätzungen zusammen, um deinen Startwert zu erhalten. Wenn du 10 Aufgaben mit zusammen 50 Story Points hast, startet dein Chart bei 50.
Schritt 2: Die Achsen anlegen
Jetzt legst du das Grundgerüst an. Jedes Burndown-Chart hat zwei einfache Achsen, die du in Excel, Google Sheets oder jedem PM-Tool schnell anlegen kannst.
- Die horizontale X-Achse (Zeit): Das ist einfach die Länge deines Sprints. Beschrifte sie mit Tagen, beginnend bei Tag 0 bis zum letzten Tag (z. B. Tag 10 bei einem zweiwöchigen Sprint). Lass arbeitsfreie Tage wie Wochenenden oder Feiertage weg.
- Die vertikale Y-Achse (verbleibende Arbeit): Sie zeigt die noch offene Arbeit. Ganz oben steht dein Startwert (unsere 50 Story Points), ganz unten null.
Sobald die Achsen stehen, hast du den Grundrahmen für die Geschichte deines Sprints.
Die Stärke eines Burndown-Charts liegt in seiner Einfachheit. Es ist eine transparente Vereinbarung zwischen Team und Stakeholdern darüber, welche Arbeit auf dem Tisch liegt und wie viel Zeit dafür noch bleibt.
Schritt 3: Ideal- und Ist-Linie einzeichnen
Mit dem fertigen Rahmen kannst du die beiden Linien zeichnen, die dir verraten, was wirklich los ist.
- Die Ideallinie einzeichnen: Das ist eine perfekte, gerade Diagonale. Sie beginnt an Tag 0 bei deiner gesamten Arbeit und endet am letzten Sprinttag bei null. Sie steht für ein makelloses, gleichmäßiges Abschlusstempo. Eine kurze Rechnung hilft: Bei 50 Punkten und 10 Arbeitstagen liegt deine ideale Burn-Rate bei 5 Punkten pro Tag.
- Die Ist-Linie einzeichnen: Auch diese Linie beginnt am selben Punkt. Jeden Tag aktualisierst du sie, indem du die Story Points aller Aufgaben, die auf „Done“ geschoben wurden, vom Vortageswert abziehst. Diese neue Zahl ist dein Punkt für den Tag. Die Linie wird unweigerlich im Zickzack verlaufen und die chaotische, ungleichmäßige Realität der Softwareentwicklung zeigen.
Das Chart lebendig zu halten ist eine tägliche Gewohnheit, meist verbunden mit eurem Daily Stand-up. Erst dieser tägliche Check macht das Burndown-Chart zu einem nützlichen Werkzeug statt zu einem bloßen historischen Artefakt. Wenn das Schreiben von Specs von Hand dein Engpass ist: Die Loops von Tekk.coach schreiben Specs aus dem, was sich in deinem Code geändert hat, und bringen sie dir als Proposals, die du mit Greenlight freigibst oder ablehnst.
Typische Fehler mit dem Burndown-Chart, die du vermeiden solltest
Ein Burndown-Chart ist ein schonungslos ehrlicher Spiegel. Es ist ein großartiges Werkzeug für Transparenz, aber nur, wenn du es diszipliniert nutzt. Wenn Teams nachlässig werden, ist das Chart kein Fortschrittsbericht mehr, sondern schnell eine irreführende Vanity Metric.
Wenn du weißt, wie diese Charts typischerweise schiefgehen, kannst du deins ehrlich – und wirklich nützlich – halten.
Selbst ein Chart, das perfekt aussieht, kann ernste Probleme im Team verbergen. Gehen wir die häufigsten Fehler durch, die dein Burndown-Chart ruinieren, und wie du sie behebst, bevor sie deinen Sprint entgleisen lassen.
Nicht erfassten Scope Creep ignorieren
Das ist die gefährlichste Falle. Sie entsteht, wenn neue Arbeit still und leise in einen Sprint rutscht, ohne dass jemand das Chart aktualisiert. Ein Stakeholder hat eine „kleine“ Bitte, ein „schneller“ Bugfix kommt dazu, aber nichts wird geschätzt oder erfasst.
Die Arbeit kostet das Team trotzdem Zeit und Energie, aber weil sie nie im Chart stand, zeigt die Linie weiter nach unten. Das Chart sieht großartig aus, doch das Team fühlt sich völlig überlastet und verfehlt seine offiziellen Zusagen. So entsteht eine schmerzhafte Kluft zwischen Daten und Realität.
- So behebst du es: Führe eine strikte Regel ein: Was nicht erfasst ist, wird nicht gemacht. Jede neue Anfrage, egal wie klein sie scheint, geht zur Prüfung an den Product Owner. Ist sie kritisch, wird sie geschätzt und ins Sprint-Backlog aufgenommen. Das erzeugt einen sichtbaren Ausschlag nach oben im Burndown-Chart, macht die Kosten der Änderung deutlich und erzwingt ein echtes Gespräch über Prioritäten und Zielkonflikte.
Inkonsistente oder überhastete Schätzungen
Dein Burndown-Chart ist nur so gut wie die Schätzungen, die es speisen. Wenn Story Points ohne echte Diskussion verteilt werden, wird das Ganze instabil. Zu optimistische Schätzungen lassen das Team ständig wie gescheitert aussehen. Aufgeblähte, absichtlich großzügige Schätzungen erzeugen eine falsche Sicherheit.
Diese Inkonsistenz macht es unmöglich, eine verlässliche Velocity aufzubauen – und genau die ist einer der wichtigsten langfristigen Vorteile eines Burndown-Charts. Du kannst künftige Sprints nicht prognostizieren, wenn deine bisherigen Daten auf Ratespielen beruhen.
Beim Schätzen geht es nicht darum, auf die Stunde genau zu sein, sondern darum, konsequent relativ zu schätzen. Eine Story mit 5 Punkten sollte sich immer etwa halb so komplex anfühlen wie eine mit 10 Punkten. Bricht diese Konsistenz weg, verschwindet die Vorhersagekraft des Charts.
Vergessen, das Chart täglich zu aktualisieren
Das klingt selbstverständlich, ist aber ein überraschend häufiger Grund, warum es schiefgeht. Ein Burndown-Chart ist ein Diagnosewerkzeug in Echtzeit, kein historisches Artefakt, das man später ausfüllt. Aktualisiert dein Team es nur zweimal pro Woche – oder schlimmer, kurz vor dem Sprint-Review –, verliert es seinen ganzen Wert als Frühwarnsystem.
Schon ein oder zwei Tage Verzögerung können ein kritisches Hindernis verbergen, bis es zu spät ist, noch etwas zu tun. Das Chart wird dann zum Werkzeug für die Sprint-Nachbetrachtung statt zum täglichen Wegweiser. Das ist schlicht Disziplin – und die muss im ganzen Team zur Gewohnheit werden.
- So behebst du es: Mach das Aktualisieren des Burndown-Charts zu einem festen Bestandteil eures Daily Stand-ups. Zeig das Chart auf einem großen Bildschirm und lass das Team es gemeinsam aktualisieren, während ihr den Fortschritt durchgeht. Dieses kleine Ritual dauert weniger als eine Minute und verankert die Praxis direkt im täglichen Rhythmus des Teams.
Die Daten falsch deuten
Der letzte Fehler ist, das Chart als Leistungszeugnis zu behandeln, um Leute zu loben oder zu bestrafen. Eine Linie, die über der Ideallinie verläuft, ist kein Zeichen für ein „schlechtes“ Team, sondern ein Anlass, Fragen zu stellen. Vielleicht seid ihr auf ein unerwartetes technisches Problem gestoßen, wartet auf ein anderes Team, oder eine Aufgabe war von Anfang an schlecht definiert.
Sobald das Management das Chart nutzt, um Schuld zu verteilen, lernen Teams, das System „auszutricksen“. Sie zerlegen Aufgaben auf unnatürliche Weise oder hetzen durch die Arbeit, nur damit die Linie sinkt – meist auf Kosten der Qualität. Ein gutes Backlog-Management schafft die nötige Klarheit, um das zu verhindern, und ein eigenes Tool für Backlog-Management kann diese Struktur liefern.
Wenn du diese typischen Fehler vermeidest, bleibt dein Burndown-Chart ein ehrlicher und wertvoller Wegweiser, um Arbeit planbar zu liefern.
Häufige Fragen zu Burndown-Charts
Burndown-Charts wirken auf den ersten Blick einfach, aber wer sie gut nutzen will, stößt in fast jedem Team auf dieselben Fragen. Klären wir die häufigsten Unklarheiten, damit du sie mit Zuversicht einsetzen kannst.
Das sind die Fragen, die wir von Teams, die gerade anfangen, am häufigsten hören.
Was ist der Unterschied zwischen einem Burndown- und einem Burnup-Chart?
Gute Frage. Beide verfolgen den Fortschritt, aber sie beantworten unterschiedliche Fragen und eignen sich für unterschiedliche Blicke auf die Arbeit.
- Ein Burndown-Chart verfolgt die verbleibende Arbeit. Die Linie geht nach unten. Es ist perfekt für die Frage: „Schaffen wir diesen Sprint pünktlich?“ Es ist fokussiert, einfach und ideal für den festen Scope eines einzelnen Sprints.
- Ein Burnup-Chart verfolgt die erledigte Arbeit. Die Linie geht nach oben. Es beantwortet: „Wie viel haben wir geschafft?“ Seine eigentliche Stärke ist aber eine zweite Linie für den gesamten Scope. Dadurch eignet es sich hervorragend, um Scope Creep über ein längeres Release oder Projekt sichtbar zu machen.
Merk es dir so: Burndown für den Sprint, Burnup für das Release.
Sollten wir Story Points oder Stunden verwenden?
Das ist die klassische Debatte. Stunden zu erfassen fühlt sich konkreter an, ist aber oft eine Falle. Komplexe Softwarearbeit in Stunden zu schätzen ist notorisch unzuverlässig, weil dabei unerwartete Probleme, Abstimmungsaufwand oder die schiere kognitive Last einer Aufgabe nicht berücksichtigt werden.
Die meisten erfahrenen agilen Teams landen bei Story Points. Story Points sind ein relatives Maß für Aufwand, Komplexität und Risiko – nicht für Zeit. Genau diese Abstraktion sorgt auf lange Sicht für eine stabile und berechenbare Velocity. Ist dein Team ganz neu in der agilen Arbeit, fühlen sich Stunden zum Einstieg vielleicht leichter an, aber das Ziel sollte sein, mit wachsender Erfahrung auf Story Points umzusteigen.
Wichtige Erkenntnis: Story Points messen die Größe des Problems, nicht die Zeit, die es braucht, um es zu lösen. Dieser Perspektivwechsel ermöglicht genauere langfristige Prognosen und hilft Teams, ihre echte Kapazität zu verstehen.
Warum ist mein Burndown-Chart am Anfang des Sprints flach?
Eine flache Linie in den ersten ein, zwei Tagen eines Sprints ist völlig normal. Sie bedeutet nur, dass das Team fleißig arbeitet, aber noch nichts auf „Done“ geschoben wurde.
Das ist besonders häufig, wenn ihr größere User Stories habt, die ein paar Tage dauern. Entscheidend ist, es im Blick zu behalten. Ist die Linie zur Sprintmitte immer noch flach, ist das ein Warnsignal. Es kann auf ein verstecktes Hindernis hindeuten, auf eine Story, die viel zu groß für einen Sprint ist, oder darauf, dass jemand im Team feststeckt. Genau das richtige Thema für euer Daily Stand-up.
Kann ich ein Burndown-Chart für ein persönliches Projekt nutzen?
Auf jeden Fall. Ein Burndown-Chart ist ein fantastisches Werkzeug für Freelancer, Solo-Founder oder alle, die ein Projekt mit klaren Aufgaben und einer Deadline angehen.
Der Ablauf ist derselbe. Liste alles auf, was zu tun ist, schätze den Aufwand für jede Aufgabe (du kannst sogar einfache T-Shirt-Größen nehmen: S, M, L), lege dein Enddatum fest und halte jeden Tag deinen Fortschritt fest. Du bekommst dieselbe starke Visualisierung und Motivation und bleibst ehrlich zu dir selbst, was deinen Fortschritt angeht.
Ein Burndown-Chart ist nur so ehrlich wie eure Definition of Done. In Tekk.coach ist eine Spec abgeschlossen, wenn der Pull Request, der sie schließt, gemergt und ihre Checkliste erledigt ist – „Done“ auf dem Board heißt also gemergt. Sechzehn Loops lesen, was sich in deinem Code geändert hat, und bringen dir Proposals; gibst du eines mit Greenlight frei, wird daraus eine Spec, die dein Coding-Agent baut. Sieh dir an, wie es funktioniert: https://tekk.coach.