Backlog Refinement Technik: Tickets schneiden wie ein Pro

Dieser Artikel ist Teil des Survival-Kits für Entwickler. 

Praktische Lösungen, damit du deine Fokuszeit zurückgewinnst und echte Ergebnisse lieferst, statt nur im „Agile-Theater“ mitzuspielen.

Kennst du das? Das Sprint Planning beginnt, der Product Owner (PO) zieht das erste Ticket und die nächsten 60 Minuten verbringt ihr damit, darüber zu diskutieren, was mit „Benutzerprofil optimieren“ eigentlich gemeint ist. Am Ende geht ihr frustriert in den Sprint, ohne einen blassen Schimmer zu haben, wie ihr die Architektur dafür bauen sollt.

Das ist das Resultat von fehlendem oder schlechtem Backlog Refinement.

Viele Teams betrachten das Refinement als optionales „Laber-Meeting“. Für den pragmatischen Entwickler ist es jedoch das wichtigste Event im gesamten Prozess. Warum? Weil hier entschieden wird, ob du im Sprint im Flow coden kannst oder ob du alle zwei Stunden die IDE schließen musst, um Unklarheiten zu klären.

Hier mein Guide, wie ihr eure Tickets so vorbereitet, dass das Planning zur Formsache wird.

Warum Refinement wichtiger ist als das Planning

In einem perfekt laufenden Team ist das Sprint Planning nach 30 Minuten vorbei. Warum? Weil die harte Arbeit bereits im Refinement erledigt wurde. Das Planning ist der Moment, in dem wir uns committen. Das Refinement ist der Prozess, der uns bereit macht. Wenn ihr erst im Planning anfangt zu verstehen, was gebaut werden soll, ist es zu spät.

Das Refinement ist weniger ein Meeting und mehr eine Aktivität. Es geht darum, „Shit In, Shit Out“ zu verhindern. Ein Ticket, das nicht „Ready“ ist, darf den Sprint nicht betreten. Punkt.

INVEST-Kriterien aus technischer Sicht

Du hast wahrscheinlich schon von INVEST gehört. Aber vergessen wir mal kurz die Theorie und schauen uns an, was das für deinen Code bedeutet:

• Independent (Unabhängig): Kannst du das Ticket bearbeiten, ohne auf ein anderes Team zu warten? Wenn nein, schneide es so, dass du mit Mocks oder Interfaces arbeiten kannst.
• Negotiable (Verhandelbar): Ein Ticket ist kein Lastenheft. Wenn die Anforderung technisch absurd ist, verhandle die Lösung. Du bist der Experte für die Umsetzung, der PO für den Value.
• Valuable (Wertvoll): Wenn du nicht erklären kannst, warum ein User dieses Ticket braucht, ist es vielleicht nur Gold-Plating oder technischer Selbstzweck.
• Estimable (Schätzbar): Wenn du sagst „Ich kann das nicht schätzen“, bedeutet das meistens: „Ich habe das Problem noch nicht verstanden.“ Das ist ein Zeichen für den Spike (siehe unten).
• Small (Klein): Ein Ticket sollte so klein sein, dass es in 2–3 Tagen durch die Pipeline ist. Große Tickets sind Verstecke für Bugs und Unklarheiten.
• Testable (Testbar): Wenn du nicht weißt, wie du beweist, dass es funktioniert, ist das Ticket nicht gut definiert.

Vertical Slicing: Die SPIDR-Methode

Einer der größten Schmerzpunkte für Entwickler ist das „horizontale Schneiden“. Oft verfallen dann Teams darin, ein Ticket für die DB, eines für die API, eines für das UI anzulegen. Das Ergebnis: Am Ende des Sprints habt ihr viel Code, aber nichts, was funktioniert.

Wir wollen Vertical Slicing. Ein dünner Schnitt durch alle Layer. Mike Cohn hat dafür das SPIDR-Framework entwickelt, mit dem ihr jede User Story in handliche Stücke zerlegt:

S – Spikes (Forschung)

Wenn die Story zu komplex ist, zieh einen Spike heraus. Recherchiere die Library oder probiere einen Prototyp. Erst danach wird die eigentliche Story geschätzt.

P – Paths (Pfade)

Schneide nach dem „Happy Path“ und den Alternativen.

• Story 1: User kann sich mit E-Mail anmelden (Happy Path).
• Story 2: Passwort-Vergessen-Funktion.
• Story 3: OAuth Integration.

I – Interfaces (Schnittstellen)

Schneide nach Endgeräten oder UI-Komplexität.

• Story 1: Die API-Schnittstelle steht (nutzbar für andere Teams).
• Story 2: Das CLI-Tool funktioniert.
• Story 3: Das schicke Web-Interface (kommt später).

D – Data (Daten)

Schneide nach Datentypen oder Komplexität der Daten.

• Story 1: Wir unterstützen nur MP4-Uploads (YouTube-Beispiel).
• Story 2: Wir fügen Support für .mov und .webm hinzu.

R – Rules (Regeln)

Schneide nach Business-Logik.

• Story 1: User kann einen Kommentar posten.
• Story 2: Wir fügen eine Validierung gegen SQL-Injection und Schimpfwörter hinzu.

Der Vorteil: Ihr liefert nach jedem Ticket etwas, das „lebt“, anstatt am Ende des Sprints vor einem Trümmerhaufen aus nicht integrierten Layern zu stehen.

Spikes: Wann wir erst forschen müssen, bevor wir schätzen

Ich bin mir sicher, du hasst es, raten zu müssen. Wenn der PO fragt „Wie lange dauert die Migration auf die neue GraphQL-API?“, ist die ehrlichste Antwort oft: „Keine Ahnung, ich hab das noch nie gemacht.“

Es kann sein, dass du (und deine Team-Member) trotzdem gezwungen werdet, eine Story-Point-Zahl zu nennen. Erfolgreicher für alle ist es aber, einen Spike zu benutzen.

Ein Spike ist ein zeitlich begrenztes Ticket (z. B. 4–8 Stunden), dessen Ziel nicht Code in Produktion ist, sondern Wissen.

• Was haben wir gelernt?
• Welche technischen Risiken gibt es?
• Wie können wir die eigentliche Story jetzt sinnvoll schneiden?

Nach dem Spike ist die Unsicherheit weg, und das Planning wird wieder zum Kinderspiel.

Umgang mit unklaren Anforderungen des POs

Manchmal kommen POs mit User Stories, die eher wie epische Gedichte oder (schlimmer) wie ein einziger kryptischer Satz klingen. Dein Job im Refinement ist es, der „Gatekeeper“ für dein Team zu sein.

Nutzt eine Definition of Ready (DoR). Sie ist der Gegenpart zur Definition of Done. Das ist euer Qualitätsstandard für eingehende Arbeit. Ein Ticket ist erst „Ready“, wenn:

• Der fachliche Kontext klar ist.
• Die Akzeptanzkriterien eindeutig sind.
• Technische Abhängigkeiten geklärt sind.
• Das Ticket klein genug ist (Slicing erfolgt).

Wenn ein PO versucht, ein unklares Ticket in den Sprint zu drücken, ist deine Antwort

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

DoR Checkliste

Mit der Definition of Ready hast du eine Checkliste an der Hand, mit der du prüfen kannst, ob eine Story wirklich so weit geklärt ist, dass ihr sie starten könnt.

Nutzt diese Liste als Leitplanke im Refinement. Wenn ein Ticket bei mehr als zwei Punkten ein „Nein“ oder „Vielleicht“ bekommt, ist es nicht ready für den Sprint. Schickt es zurück in die Werkstatt des Product Owners.

1. Der Business-Kontext („Das Warum“)

• Value klar: Wir wissen, wer die Zielgruppe ist und welches reale Problem dieses Ticket löst. (Kein „Weil der Chef das will“).
• Erfolg messbar: Es ist klar, woran wir nach dem Release merken, dass das Feature funktioniert (z.B. Tracking-Event, Metrik).

2. Die fachliche Klarheit („Das Was“)

• Akzeptanzkriterien vorhanden: Es gibt eine Liste von Bedingungen, die erfüllt sein müssen, damit der PO das Ticket abnimmt.
• Edge Cases bedacht: Was passiert bei Fehlern, leeren Zuständen oder Timeouts? (Grobe Klärung reicht).
• UI/UX Ready: Falls das Ticket das Frontend betrifft: Die Designs/Wireframes sind final und für die Devs zugänglich.

3. Die technische Machbarkeit („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ßen wird. Es gibt keine „magischen“ Unbekannten.
• Spike-Check: Wenn wir keine Ahnung haben, wie wir es umsetzen sollen, wurde erst ein Forschungs-Ticket (Spike) erledigt.

4. Die Logistik („Das Format“)

• Vertical Slicing: Das Ticket ist so geschnitten, dass es durch alle Layer geht (kein reines „DB-Ticket“).
• Small enough: Das Team ist zuversichtlich, dass das Ticket innerhalb von 2–3 Tagen durch die Pipeline gehen kann.
• Schätzung erfolgt: Das Team hat das Ticket gemeinsam geschätzt (oder bewusst darauf verzichtet, weil es klein genug ist).

Achtung: Keine Bürokratie-Falle! Die DoR ist kein Gesetzblatt, um den PO zu schikanieren. Sie ist ein Kommunikations-Werkzeug. Wenn ein Ticket fast ready ist und ihr die restlichen 5 % im Sprint klären könnt: Go for it. Wenn das Ticket aber ein schwarzes Loch aus Unklarheiten ist: Finger weg.

Fazit: 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 erfordert tiefes technisches Verständnis – es ist echtes Engineering.

Wer seine Tickets meisterhaft schneidet, reduziert Reibung, eliminiert Überstunden am Ende des Sprints und sorgt dafür, dass das Team sich auf das konzentrieren kann, was es am besten kann: Exzellente Software bauen.

Was kommt als Nächstes?
Gutes Refinement verhindert Überraschungen. Aber was ist mit dem Code, der bereits "stinkt"? Wenn Altlasten euch bremsen, müsst ihr lernen, sie ökonomisch zu verkaufen.

🏗️ Nächster Schritt: Technische Schulden im agilen Prozess abbauen
🏠 Zurück zur Übersicht: Das Agile-Survival-Kit für Entwickler

Hat dir dieser Guide geholfen?
Teile ihn mit deinem Team oder diskutiere mit mir auf Mastodon. Echtes Feedback hilft mir, diese Inhalte für Devs noch besser zu machen!