Das Backlog-Refinement-Board nutzen

Sprint Planning wird zäh, wenn die Hälfte der Issues erst noch erklärt werden muss. Das Refinement-Board ist der Ort davor: Hier wird aus einem Zweizeiler eine Karte, die jemand nächste Woche bauen kann. Es gehört zum Developer-Plan.

Was du brauchst

Den Developer-Plan — siehe Preise.
Ein Backlog mit Issues, die mehr Kontext brauchen.
15–30 Minuten mit dem Team, regelmäßig.

1. Plan prüfen

Das Refinement-Board ist Teil der agilen Ebene des Developer-Plans, zusammen mit Backlog, Poker und Sprints.

2. Refinement-Tab öffnen

Neben dem Backlog der Gruppe liegt der Refinement-Tab. Er ist ein eigenes Board mit einem klaren Zweck: Was hier liegt, wird gerade vorbereitet — nicht gebaut.

3. Unfertige Issues hereinholen

Hole die Issues herein, die ihr in der nächsten Session besprechen wollt. Standard sind die unfertigen; auf Wunsch auch bereits fertige oder eingeplante, wenn sich etwas geändert hat. Der Rest des Backlogs bleibt, wo er ist — das Refinement-Board ist eine Auswahl, kein Umzug.

4. In Arbeitsreihenfolge ziehen

Sortiere die Liste in die Reihenfolge, in der ihr sie durchgehen wollt: das Wichtigste nach oben. Wenn die Zeit ausgeht — und sie geht immer aus —, ist das Wichtigste besprochen statt das zufällig Erste.

5. Karte im Vollbild ausfüllen

Jede Karte öffnet sich im Vollbild, und ihr füllt sie gemeinsam: Beschreibung mit Akzeptanzkriterien, Typ, Priorität, Epic, eigene Felder. Faustregel: Wer die Karte in vier Wochen zieht, darf keine Rückfrage mehr brauchen.

6. Weitergeben

Am Ende der Besprechung verzweigt der Weg:

Nicht-Bugs gehen zum Planning Poker — sie brauchen eine Schätzung.
Bugs gelten direkt als bereit. Ihre Schätzung wäre geraten: Der Aufwand steckt in der Ursache, und die kennt man erst beim Beheben.

„Bereit" entsteht auf vier Wegen: Poker übernimmt eine Schätzung, jemand schreibt Story Points direkt, ein Bug durchläuft das Refinement, oder jemand setzt es von Hand. Zurückgesetzt wird es nur durch die Aufnahme in einen Sprint — sonst nie automatisch. Bereite Karten sammeln sich im Tab „Bereit für Sprint", aus dem das Planning dann schöpft.

Wenn es nicht klappt

Kein Refinement-Tab. Developer-Plan nötig.
Eine Karte gilt als bereit, ist es aber nicht. Jemand hat Story Points geschrieben oder es von Hand gesetzt. Einfach von Hand zurücknehmen und erneut besprechen.
Das Board läuft über. Zu viel hereingeholt. Refinement ist eine Auswahl für die nächste Session, kein zweites Backlog.

Nächste Schritte

Häufige Fragen

Was ist der Unterschied zwischen Refinement und Backlog?

Das Backlog ist der Vorrat — alles, was irgendwann dran sein könnte. Das Refinement-Board ist der Arbeitstisch: die Handvoll Issues, die ihr jetzt besprechen, vervollständigen und schätzen wollt.

Warum überspringen Bugs die Schätzung?

Weil die Schätzung eines Bugs meist geraten ist: Der Aufwand steckt in der Ursache, und die kennt man erst beim Beheben. Ein Bug, der das Refinement durchlaufen hat, gilt darum direkt als bereit.

Wo landet eine Karte, die bereit ist?

Im dritten Tab — „Bereit für Sprint„. Von dort zieht ihr sie beim Planning in den Sprint, einzeln oder als Mehrfachauswahl.

Was macht eine Karte „bereit„?

Vier Wege: Planning Poker übernimmt eine Schätzung, jemand schreibt Story Points direkt, ein Bug durchläuft das Refinement, oder jemand setzt es von Hand. Zurückgesetzt wird es nur durch die Aufnahme in einen Sprint — sonst nie automatisch.

Welcher Plan?

Der Developer-Plan — Refinement ist Teil der Sprint-Ebene.