Backlog Refinement Technik: Tickets schneiden wie ein Pro

Survival-Kit für Entwickler Teil 4 von 8 Zur Übersicht

Kennst du das? Das Sprint Planning beginnt, der Product Owner zieht das erste Ticket, und die nächsten sechzig Minuten diskutiert ihr darüber, was mit „Benutzerprofil optimieren“ eigentlich gemeint ist. Am Ende geht ihr frustriert in den Sprint, ohne einen blassen Schimmer, wie die Architektur dafür aussehen soll.

Das ist das Resultat von fehlendem oder schlechtem Backlog Refinement.

Viele Teams behandeln das Refinement als optionales Laber-Meeting. Für den pragmatischen Entwickler ist es das wichtigste Event im ganzen Prozess. Denn hier entscheidet sich, ob du im Sprint im Flow codest oder alle zwei Stunden die IDE schließt, um Unklarheiten zu klären.

Warum Refinement wichtiger ist als das Planning

In einem gut laufenden Team ist das Sprint Planning nach dreißig Minuten vorbei, weil die harte Arbeit im Refinement erledigt wurde. Das Planning ist der Moment, in dem ihr euch festlegt. Das Refinement ist der Prozess, der euch bereit macht.

Es ist weniger ein Meeting als eine Tätigkeit, und ihr Zweck ist, „Shit in, shit out“ zu verhindern. Ein Ticket, das nicht ready ist, darf den Sprint nicht betreten. Punkt.

INVEST aus technischer Sicht

Du hast wahrscheinlich schon von INVEST gehört. Vergessen wir die Theorie und schauen, was das für deinen Code bedeutet.

• Independent: Kannst du das Ticket bearbeiten, ohne auf ein anderes Team zu warten? Wenn nein, schneide so, dass Mocks oder Interfaces reichen.
• Negotiable: Ein Ticket ist kein Lastenheft. Ist die Anforderung technisch absurd, verhandelst du die Lösung. Du bist Experte für die Umsetzung, der PO für den Value.
• Valuable: Wenn du nicht erklären kannst, warum ein User das braucht, ist es Gold-Plating oder technischer Selbstzweck.
• Estimable: „Ich kann das nicht schätzen“ heißt meistens „Ich habe das Problem noch nicht verstanden“. Das ist das Signal für einen Spike.
• Small: Ein Ticket sollte in zwei bis drei Tagen durch die Pipeline sein. Große Tickets sind Verstecke für Bugs und Unklarheiten.
• Testable: Wenn du nicht weißt, wie du beweist, dass es funktioniert, ist das Ticket nicht gut definiert.

Vertical Slicing mit SPIDR

Einer der größten Schmerzpunkte ist horizontales Schneiden: ein Ticket für die DB, eines für die API, eines fürs UI. Am Sprintende habt ihr viel Code und nichts, was funktioniert.

Wir wollen einen dünnen Schnitt durch alle Layer. Mike Cohn hat dafür das SPIDR-Framework entwickelt.

S wie Spikes

Ist die Story zu komplex, zieh einen Spike heraus. Recherchiere die Library, bau einen Prototyp. Erst danach wird die eigentliche Story geschätzt.

P wie Paths

Schneide nach dem Happy Path und seinen Alternativen. Story eins: Anmeldung per E-Mail. Story zwei: Passwort vergessen. Story drei: OAuth.

I wie Interfaces

Schneide nach Endgeräten und UI-Komplexität. Erst steht die API, die andere Teams schon nutzen können. Dann das CLI-Tool. Das schicke Web-Interface kommt zuletzt.

D wie Data

Schneide nach Datentypen. Am YouTube-Beispiel: erst nur MP4-Uploads, danach Support für .mov und .webm.

R wie Rules

Schneide nach Business-Logik. Erst kann der User einen Kommentar posten. Dann kommt die Validierung gegen SQL-Injection und Schimpfwörter dazu.

Der Vorteil: Nach jedem Ticket lebt etwas, statt dass am Sprintende ein Trümmerhaufen aus nicht integrierten Layern liegt.

Spikes: erst forschen, dann schätzen

Wenn der PO fragt, wie lange die Migration auf die neue GraphQL-API dauert, ist die ehrlichste Antwort oft: „Keine Ahnung, ich hab das noch nie gemacht.“

Es kann sein, dass du trotzdem gezwungen wirst, eine Zahl zu nennen. Erfolgreicher für alle ist ein Spike: ein zeitlich begrenztes Ticket von vier bis acht Stunden, dessen Ziel nicht Code in Produktion ist, sondern Wissen. Was haben wir gelernt, welche technischen Risiken gibt es, und wie schneiden wir die eigentliche Story jetzt sinnvoll? Danach ist die Unsicherheit weg, und das Planning wird zur Formsache.

Umgang mit unklaren Anforderungen

Manchmal kommen POs mit User Stories, die wie epische Gedichte klingen. Oder, schlimmer, wie ein einziger kryptischer Satz. Dein Job im Refinement ist, der Türsteher für dein Team zu sein.

Dafür braucht ihr eine Definition of Ready, den Gegenpart zur Definition of Done. Sie ist euer Qualitätsstandard für eingehende Arbeit. Wenn ein PO ein unklares Ticket in den Sprint drücken will, lautet deine Antwort:

„Wir würden gerne helfen, aber ohne Klarheit produzieren wir nur Waste. Lass uns jetzt zehn Minuten investieren, um es nach SPIDR zu schneiden, statt nächste Woche drei Tage in die falsche Richtung zu laufen.“

Checkliste: Definition of Ready

Nutzt diese Liste als Leitplanke im Refinement. Wenn ein Ticket bei mehr als zwei Punkten ein Nein oder Vielleicht bekommt, ist es nicht ready. Dann geht es zurück in die Werkstatt des Product Owners.

1. Der Business-Kontext, also das Warum

• Value klar: Wir wissen, wer die Zielgruppe ist und welches reale Problem das Ticket löst. Nicht „weil der Chef das will“.
• Erfolg messbar: Es ist klar, woran wir nach dem Release merken, dass das Feature funktioniert, etwa an einem Tracking-Event.

2. Die fachliche Klarheit, also das Was

• Akzeptanzkriterien vorhanden: Es gibt Bedingungen, die erfüllt sein müssen, damit der PO abnimmt.
• Edge Cases bedacht: Was passiert bei Fehlern, leeren Zuständen oder Timeouts? Grobe Klärung reicht.
• UI ready: Bei Frontend-Tickets sind die Designs final und für die Devs zugänglich.

3. Die technische Machbarkeit, also das Wie

• Abhängigkeiten geklärt: Wir müssen nicht auf Team X oder API Y warten, um starten zu können.
• Architektur-Fit: Wir wissen grob, in welche Komponenten der Code fließt. Keine magischen Unbekannten.
• Spike-Check: Wo wir keine Ahnung haben, wurde vorher geforscht.

4. Die Logistik, also das Format

• Vertical Slicing: Das Ticket geht durch alle Layer, es ist kein reines DB-Ticket.
• Small enough: Das Team ist zuversichtlich, dass es in zwei bis drei Tagen durch die Pipeline geht.
• Schätzung erfolgt, oder es wurde bewusst darauf verzichtet, weil das Ticket klein genug ist.

Refinement ist Engineering

Hört auf, Refinement als Meeting-Overhead zu sehen. Es ist der Moment, in dem ihr die Architektur eures Sprints entwerft. Gutes Slicing braucht tiefes technisches Verständnis, es ist echtes Engineering.

Nimm dir für das nächste Refinement eine Sache vor: Nenn bei einem Ticket laut die Schnittlinie, die du nach SPIDR ziehen würdest, bevor jemand über Punkte redet.