Backlog Grooming in der mobilen Entwicklung: Was es ist, Ziele und der Prozess

Was ist Backlog Grooming?

Backlog Grooming (Verfeinerung) ist der Prozess der Vorbereitung von Product-Backlog-Elementen für zukünftige Sprints. Es ist ein Meeting, in dem der Product Owner und das Entwicklungsteam Aufgaben durchgehen: Anforderungen klären, Acceptance Criteria hinzufügen, Komplexität schätzen, Abhängigkeiten und Risiken identifizieren. Es gibt kein verpflichtendes Ereignis namens „Grooming“ im Scrum Guide — es ist eine zusätzliche Praxis, die Scrum-Teams zur Reduzierung von Unsicherheiten beim Sprint Planning einführen. Die empfohlene Häufigkeit ist einmal pro Sprint mit einer Dauer von maximal 60 Minuten.

Der Begriff „Grooming“ spiegelt das Wesen wider: Das Team „kämmt“ das Backlog, entfernt veraltete Aufgaben, klärt unklare und zerlegt zu große. In der mobilen Entwicklung ist Grooming aufgrund der Plattformspezifika besonders wichtig: Eine Android-Aufgabe kann sich in ihrer Komplexität von der iOS-Version unterscheiden, und targetSdk, compileSdk sowie die Kompatibilität mit API-Leveln müssen berücksichtigt werden. Ohne Grooming wird das Sprint Planning zum Chaos: Das Team sieht die Aufgaben zum ersten Mal und kann sie nicht schätzen, was zu Unvorhersehbarkeit und Terminüberschreitungen führt.

Das Ergebnis des Groomings sind mehrere Aufgaben, die für das Sprint Planning bereit sind: Sie haben eine Beschreibung, Acceptance Criteria, eine Schätzung und entsprechen der Definition of Ready. Der Product Owner sollte Aufgaben in der Reihenfolge ihrer Priorität groomen: Die dem aktuellen Sprint am nächsten stehenden Aufgaben sollten am detailliertesten sein. Aufgaben für 3–4 Sprints voraus sollten nur auf Epic-Ebene bleiben. Progressive-Refinement-Technik: Je näher eine Aufgabe am Sprint ist, desto detaillierter ist ihre Beschreibung. Für Aufgaben im aktuellen Sprint — vollständige Verfeinerung (AC, Design, API-Spezifikation). Für Aufgaben 2 Sprints voraus — Story-Ebene (User Story ohne Implementierungsdetails). Für Aufgaben 3+ Sprints voraus — Epic-Ebene (nur Name und Geschäftswert).

Definition of Ready: Wann ist eine Aufgabe bereit für den Sprint

Definition of Ready (DoR) ist eine Checkliste von Kriterien, die eine Aufgabe erfüllen muss, bevor sie in das Sprint Backlog aufgenommen wird. DoR ist ein Vertrag zwischen dem Product Owner und dem Team: Der PO garantiert, dass alle für die Entwicklung notwendigen Informationen verfügbar sind, und das Team garantiert, dass es die Aufgabe schätzen und abschließen kann. DoR ist nicht universell — jedes Team definiert seinen eigenen Kriteriensatz. Ohne DoR kann eine Aufgabe mit unklaren Anforderungen in einen Sprint gelangen, was zu Nacharbeit und Terminüberschreitungen führt.

Typisches DoR für die mobile Entwicklung: 1) Acceptance Criteria sind beschrieben (Given-When-Then-Format). 2) Das Design-Mockup ist in Figma bereit (für UI-Aufgaben) mit allen Zuständen: Default, Loading, Error, Empty State. 3) Die API-Spezifikation ist genehmigt (OpenAPI/Swagger, Beispiele für Anfragen und Antworten). 4) Eine Schätzung in Story Points liegt vor. 5) Abhängigkeiten von anderen Aufgaben wurden identifiziert. 6) Die Aufgabe hängt nicht von unfertigen externen Komponenten ab. 7) Mobile Spezifika: Ziel-OS-Versionen definiert, Notwendigkeit eines Feature Flags, Unterstützung für alte API-Level.

Schätztechniken für Aufgaben

Planning Poker ist die beliebteste Schätztechnik beim Grooming. Jeder Entwickler erhält ein Kartendeck mit Fibonacci-Zahlen (1, 2, 3, 5, 8, 13, 21). Der PO stellt eine Aufgabe vor und erklärt sie. Nach der Diskussion zeigen alle gleichzeitig ihre Karte. Wenn die Schätzungen stark abweichen (z. B. 3 und 13), erklären die Entwickler ihre Begründung und stimmen erneut ab. Die Iterationen werden wiederholt, bis ein Konsens erreicht ist. Der Sinn von Planning Poker ist nicht die genaue Schätzung, sondern das Aufdecken von Unterschieden im Aufgabenverständnis.

T-Shirt Sizing ist eine vereinfachte Technik für schnelle Schätzungen: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Sie eignet sich für die erste Backlog-Sortierung, wenn viele Aufgaben vorhanden sind und eine grobe Größenordnung benötigt wird. Nach dem T-Shirt Sizing erfolgt eine genauere Schätzung mittels Planning Poker für die Aufgaben des nächsten Sprints. Affinity Estimation ist eine Gruppensortiertechnik, bei der Aufgaben ohne Zahlen auf einem Tisch von der einfachsten bis zur komplexesten angeordnet, dann in Cluster gruppiert werden und jeder Cluster eine Schätzung erhält.

In der mobilen Entwicklung sollte die Schätzung die Plattformkomplexität berücksichtigen. Eine Android-Aufgabe kann mit 5 SP geschätzt werden, während dieselbe Aufgabe für iOS mit 3 SP bewertet wird (oder umgekehrt). Das ist normal: Unterschiedliche Plattformen haben unterschiedliche Implementierungskomplexität. Tipp: Schätzen Sie jede Plattform separat, wenn das Team plattformübergreifend arbeitet. Verwenden Sie eine relative Skala: Eine Basisaufgabe (z. B. ein Bildschirm mit Text und einem Button) = 1 SP. Alles andere wird relativ dazu geschätzt. Laut Scrum.org (2025) erreicht die Schätzgenauigkeit eines Teams nach 3–4 Sprints ±20% der tatsächlichen Komplexität.

Zerlegung: Wie man große Aufgaben aufteilt

Aufgaben größer als 8 SP sollten in kleinere Aufgaben zerlegt werden. Große Aufgaben können nicht in einem Sprint abgeschlossen werden, sind schwer zu schätzen und vermitteln kein Fortschrittsgefühl. Zerlegungstechniken: Teilen Sie die Aufgabe in horizontalen Schichten (UI → ViewModel → Repository → Network/DB) oder in vertikalen Slices (Feature: ein kompletter Bildschirm). Horizontale Zerlegung eignet sich besser für die mobile Entwicklung: Teilaufgabe 1 — UI-Layout (XML/Jetpack Compose/SwiftUI), Teilaufgabe 2 — ViewModel + State, Teilaufgabe 3 — Repository + Network, Teilaufgabe 4 — Unit-Tests.

Vertikale Zerlegung — Aufteilung von User Stories in kleinere Stories mit unabhängigem Wert. Beispiel: Epic „Warenkorb“ → Story 1 „Artikel in den Warenkorb legen“, Story 2 „Warenkorb anzeigen“, Story 3 „Artikel aus dem Warenkorb entfernen“, Story 4 „Kasse“. Jede Story hat ihren eigenen Geschäftswert und kann unabhängig veröffentlicht werden. SPoK (Story Points on Kano): Ordnen Sie Stories nach Geschäftswert (Must-have, Should-have, Could-have) und implementieren Sie sie in der Reihenfolge ihres Werts.

Checkliste für die Zerlegung beim Grooming: 1) Ist die Aufgabe größer als 8 SP? → Zerlegen. 2) Sind Acceptance Criteria definiert? → Wenn nicht, hinzufügen. 3) Hängt sie von anderen Aufgaben ab? → Abhängigkeiten identifizieren und dokumentieren. 4) Enthält sie Unsicherheit? → Einen Spike (Recherche) vor der Hauptaufgabe hinzufügen. 5) Wird Design benötigt? → Bereitschaft der Mockups prüfen. INVEST-Regel: Independent (unabhängig von anderen), Negotiable (verhandelbar), Valuable (wertvoll fürs Geschäft), Estimable (schätzbar), Small (klein), Testable (testbar). Wenn eine Aufgabe INVEST nicht erfüllt, ist sie nicht bereit für den Sprint.

Der Grooming-Prozess: Schritt für Schritt

Schritt 1: Aufwärmen (5 Minuten). Der Scrum Master erinnert das Team an das Ziel des Groomings und das DoR. Das Team schaut auf das Board, und der PO zeigt, welche Aufgaben besprochen werden. Schritt 2: Aufgabenüberprüfung (30 Minuten). Der PO stellt nacheinander Aufgaben vom Ende des aktuellen und vom Anfang des nächsten Sprints vor. Für jede Aufgabe: Name, Beschreibung, Acceptance Criteria (falls vorhanden), Design-Link, API-Spezifikation. Das Team stellt klärende Fragen: „Gibt es ein Mockup für den leeren Zustand?“, „Welche HTTP-Methode?“, „Was ist das iOS-Minimum-Deployment-Target?“

Schritt 3: Schätzung (15 Minuten). Das Team schätzt die Aufgabe mittels Planning Poker oder T-Shirt Sizing. Wenn die Abweichung mehr als 2 SP beträgt, diskutieren sie die Gründe und stimmen erneut ab. Regel: Wenn eine Aufgabe nicht geschätzt werden kann (Anforderungen unklar, kein Design), wird sie zur Überarbeitung an den PO zurückgegeben und kommt mit Klarstellungen zum nächsten Grooming. Schätzen Sie keine Aufgaben mit Unbekannten — dies führt garantiert zu Fehlern im Sprint. Schritt 4: Ergebnisse erfassen (10 Minuten). Der PO erfasst die Schätzungen in Jira/Linear, aktualisiert die Aufgabenbeschreibung und legt Prioritäten fest.

Ergebnisse des Groomings: 3–7 vollständig für das Sprint Planning vorbereitete Aufgaben (mit DoR, Schätzung, Design, API). Der PO aktualisiert das Backlog: entfernt veraltete Aufgaben, führt Duplikate zusammen und verfeinert Prioritäten. Wichtig: Das Grooming beendet die Arbeit des PO nicht — zwischen den Grooming-Sitzungen sollte der PO die nächsten Aufgaben vorbereiten. Empfohlenes Tempo: Der PO bereitet 3–4 Aufgaben für das Grooming vor, und das Team bearbeitet sie. Wenn mehr als 50 Aufgaben im Backlog sind, sollte der PO vor dem Grooming eine Prioritätensetzung (MoSCoW oder Weighted Shortest Job First) durchführen.

Unterschiede zwischen Grooming und Sprint Planning

Grooming ist die Vorbereitung. Es gibt keine Verpflichtungen — die Aufgabe wird lediglich geklärt und geschätzt. Sprint Planning ist eine Verpflichtung. Das Team wählt Aufgaben aus den im Grooming vorbereiteten aus und verpflichtet sich, sie innerhalb des Sprints abzuschließen. Hauptunterschiede: Grooming ist nicht an einen bestimmten Sprint gebunden (allgemeine Backlog-Verfeinerung), es gibt kein Sprint Goal während des Groomings, und Grooming kann zu jeder Zeit des Sprints durchgeführt werden. Sprint Planning ist strikt zu Beginn des Sprints und führt immer zu einem Sprint Goal.

Beim Grooming werden Aufgaben nur geschätzt, aber nicht in den Sprint übernommen. Beim Planning werden Aufgaben aus dem vorbereiteten Pool ausgewählt. Ohne Grooming dauert das Sprint Planning 6–8 Stunden (statt 4), weil das Team die Aufgaben zum ersten Mal sieht und sie nicht schnell schätzen kann. Die 80/20-Regel: 80% der Aufgaben im Sprint Planning sollten vollständig vorbereitet sein (das Grooming durchlaufen haben), 20% können neu sein (dringende Bugs, Hotfixes). Wenn beim Planning mehr als 20% der Aufgaben ungeschätzt sind, war das Grooming unzureichend.

Häufige Grooming-Fehler

Fehler 1: Grooming einmal im Monat. Das Team sammelt Aufgaben für 3–4 Sprints an und versucht, alles in 2 Stunden zu verfeinern. Ergebnis: Die Hälfte der Aufgaben bleibt ungeschätzt, und das Planning dauert den ganzen Tag. Lösung: Grooming sollte regelmäßig stattfinden — einmal pro Sprint, 60 Minuten. Wenn viele Aufgaben anfallen, fügen Sie ein zweites Grooming in der Mitte des Sprints hinzu. Es ist besser, wenige Aufgaben gründlich zu groomen als viele oberflächlich. Tempo: 3–5 Aufgaben pro Grooming-Sitzung, jede mit vollständiger Diskussion und Schätzung.

Fehler 2: Schätzung ohne Kontext. Der PO präsentiert eine Aufgabe „Warenkorb-Bildschirm implementieren“ ohne Design, API oder AC. Das Team schätzt „auf gut Glück“ — 13 SP. Im Planning stellt sich heraus, dass es eigentlich 5 SP sind (weil der Bildschirm einfach ist). Lösung: Eine Aufgabe wird nicht geschätzt, wenn kein Design oder keine API vorliegt. Der PO muss die Materialien vor dem Grooming vorbereiten. Regel: „Kein Mockup — keine Schätzung.“ Ausnahme: Spike-Aufgaben — Unsicherheitsforschung, sie werden separat ohne Design geschätzt (2–5 SP je nach Forschungskomplexität).

Fehler 3: Grooming wird zu Planning. Das Team beginnt, Aufgaben Personen zuzuweisen und zu besprechen, wer was tun wird. Lösung: Daran erinnern, dass Grooming der Klärung dient, nicht der Zuweisung. Die Zuweisung erfolgt im Daily nach Sprint-Start. Grooming beantwortet die Frage „Was tun?“, Planning „Wann tun?“, Daily „Wer tut es?“. Die Vermischung dieser Fragen in einem Meeting verringert die Effektivität jeder einzelnen. Der Scrum Master sollte Planning-ähnliche Diskussionen unterbrechen und den Fokus wieder auf die Aufgabenklärung lenken.

Fehler 4: Ignorieren von Tech Debt. Beim Grooming werden nur neue Features besprochen; technische Aufgaben werden ignoriert. Nach 3–4 Sprints akkumuliert sich die technische Schuld auf ein kritisches Niveau. Lösung: Bei jedem Grooming sollte mindestens eine technische Aufgabe geschätzt werden. Verhältnis: Auf 3 Features kommt 1 technische Aufgabe. Verwenden Sie die Tech-Debt-Ratio-Metrik: Verhältnis von technischen Aufgaben zu Feature-Aufgaben in einem Sprint. Zielwert: 0.25–0.3 (25–30% der Zeit für technische Schulden). Liegt das Verhältnis unter 0.2, sinkt die Entwicklungsgeschwindigkeit in den folgenden Sprints.