Wo sehe ich alte Sprints?

In der Sprint-Übersicht der Gruppe. Jeder abgeschlossene Sprint behält seinen Report und seinen Burndown — nichts davon verfällt.

Warum sind manche Punkte im Diagramm hohl?

Weil sie rekonstruiert sind, nicht gemessen. Für Tage vor dem ersten täglichen Schnappschuss stellt Zuuna den Stand aus dem Aktivitätsprotokoll wieder her und markiert diese Punkte als ungefähr — das Diagramm rät lieber sichtbar als heimlich.

Was passiert mit nicht fertigen Karten?

Du entscheidest beim Abschluss: zurück ins Backlog oder direkt in den nächsten Sprint. Nichts geht verloren, nichts wird stillschweigend als erledigt gewertet.

Wird das Board gelöscht?

Nein — archiviert. Der Unterschied ist wichtig: Ein gelöschtes Board würde seine Karten mitreißen; das archivierte behält alles, nur schreibgeschützt.

Wie berechnet ihr Velocity?

Aus dem tatsächlich Erledigten der abgeschlossenen Sprints, in der Einheit, in der ihr plant. Sie ist die Grundlage der Prognose im laufenden Sprint.

Sprint abschließen und den Burndown lesen

Der Abschluss ist der Moment, in dem aus einem Sprint Daten werden: Was wurde fertig, was nicht, und was sagt das über den nächsten Sprint? Zuuna macht daraus einen Report und einen Burndown — und ist dabei an einer Stelle ehrlicher als die meisten Werkzeuge. Sprints gehören zum Developer-Plan.

Was du brauchst

Einen laufenden Sprint, dessen Zeit um ist — oder dessen Arbeit fertig ist.
Zwei Entscheidungen: Welche Spalte gilt als erledigt, und wohin mit dem Rest?

1. Sprint abschließen

Beim Abschluss fragt Zuuna zwei Dinge: die Erledigt-Spalte (was dort steht, zählt als geschafft) und das Ziel für den Übertrag — nicht fertige Karten gehen zurück ins Backlog oder direkt in den nächsten geplanten Sprint. Nichts wird stillschweigend als erledigt gewertet.

2. Wissen, was mit dem Board passiert

Das Sprint-Board wird archiviert, nie gelöscht. Der Unterschied trägt: Löschen würde die Karten mitreißen; das Archiv behält jede Karte, jeden Kommentar und jede Bewegung — nur schreibgeschützt. Ein halbes Jahr später lässt sich noch nachlesen, was in Sprint 9 wirklich passiert ist.

3. Den Burndown öffnen

Zwei Linien: die ideale (gleichmäßiger Abbau von Start bis Ende) und die tatsächliche. Der Abstand zwischen beiden ist die eigentliche Information — dauerhaft darüber heißt zu viel versprochen, dauerhaft darunter zu vorsichtig geplant.

4. Ausschläge nach oben verstehen

Wenn die Restarbeit mitten im Sprint steigt, wurde nicht langsamer gearbeitet — es kam Scope dazu. Der Burndown macht das sichtbar, was im Alltag unsichtbar bleibt: die „nur diese eine Karte noch"-Entscheidungen. Drei solcher Sprünge in drei Sprints sind kein Diagramm-Detail, sondern ein Gesprächsthema für die Retro.

5. Einheit wechseln

Dasselbe Diagramm in drei Sichten: Story Points, Stunden, Aufgabenanzahl. Teams ohne Schätzung nehmen die Anzahl — ein Burndown ohne Story Points ist besser als gar keiner.

6. Velocity und Prognose lesen

Aus den abgeschlossenen Sprints entsteht die Velocity — was das Team pro Sprint tatsächlich schafft. Im laufenden Sprint projiziert Zuuna daraus ein voraussichtliches Ende zum aktuellen Tempo. Und eine Ehrlichkeit, die man kennen sollte: Punkte vor dem ersten täglichen Schnappschuss sind aus dem Aktivitätsprotokoll rekonstruiert und als hohle Punkte markiert — das Diagramm rät sichtbar, nie heimlich. Genauso gilt: Für Karten, die beim Abschluss auf dem archivierten Board standen, ist der Stand exakt; für übertragene ist er es naturgemäß nur bis zum Übertrag.

7. Vergangene Sprints nachlesen

Jeder abgeschlossene Sprint behält Report und Burndown. Drei davon nebeneinander beantworten die Frage, die Planning wirklich braucht: Wie viel schaffen wir ehrlich?

Wenn es nicht klappt

Das Erledigte wirkt zu niedrig. Die falsche Spalte war als erledigt gewählt. Beim nächsten Abschluss korrigieren.
Der Burndown beginnt erst mitten im Sprint durchgezogen. Kein Fehler: Die Tage davor sind rekonstruiert (hohle Punkte), gemessen wird ab dem ersten Schnappschuss.
Die Prognose fehlt. Sie braucht abgeschlossene Sprints als Grundlage — nach dem ersten Sprint gibt es noch keine Velocity.

Nächste Schritte

Den nächsten Sprint planen — jetzt mit echter Velocity.
Sprint-Kapazität planen.
Projektmanagement für Entwickler.