Grooming und Refinement — eine kurze Einordnung
Die Aktualisierung 2020 des Scrum Guide ersetzte „Backlog Grooming“ durch Product Backlog Refinement als offiziellen Begriff und beschrieb es als laufende Tätigkeit statt einzelner Zeremonie. Praktisch bleibt „Backlog Grooming“ in Jira-Workflows, Stellenanzeigen und Teamgesprächen verbreitet — deshalb verwendet dieser Artikel beide Begriffe.
Die Empfehlung des Scrum Guide: Refinement sollte höchstens 10 % der Sprintkapazität des Teams beanspruchen. Bei einem zweiwöchigen Sprint und fünf Personen sind das ungefähr vier Stunden pro Sprint — weniger als eine Stunde pro Person. Wenn deine Termine regelmäßig länger dauern, zeigt die folgende Checkliste normalerweise den Grund.
Definition of Ready (DoR): Eine gemeinsame Vereinbarung der Mindestbedingungen für die Aufnahme eines Vorgangs in einen Sprint. Die zwölf Punkte unten sind für die meisten Jira-Teams ein guter Ausgangspunkt. Passe sie an deinen Kontext an — ein Start-up und ein Unternehmensteam gewichten sie unterschiedlich.
Die Checkliste mit zwölf Punkten zur Jira-Backlog-Pflege
Jeder Punkt ist nach Wichtigkeit gekennzeichnet: Pflicht -Punkte sind Voraussetzung für die Sprintaufnahme; Empfohlen -Punkte verursachen bei Auslassung Nacharbeit; Optional -Punkte verbessern langfristig die Qualität, blockieren aber selten die Lieferung.
| Prüfpunkt | Was zu prüfen ist | Priorität | |
|---|---|---|---|
| ☐ | Klarer Titel | Der Titel beschreibt, was sich verändert, statt nur ein vages Label zu sein. „CSV-Export für gefilterte Board-Ansicht hinzufügen“ ist gut; „CSV-Export“ nicht. | Pflicht |
| ☐ | Beschreibung vorhanden | Mindestens: Hintergrund, erwartetes Ergebnis und profitierende Personen. Ein Beschreibungsabsatz verhindert zwanzig Minuten Klärung in der Sprint-Planung. | Pflicht |
| ☐ | Akzeptanzkriterien definiert | Konkrete, überprüfbare Bedingungen für „fertig“. Format: „Gegeben / Wenn / Dann“ oder Aufzählung. Ohne sie ist Fertigstellung eine Ermessensfrage — und das führt zu Streit im Sprint-Review. | Pflicht |
| ☐ | Story Points geschätzt | Das Team hat sich auf eine relative Größe geeinigt. Ungeschätzte Stories machen Sprintkapazitätsplanung unmöglich. Ist ein Vorgang zu groß zum Schätzen, teile ihn zuerst auf. | Pflicht |
| ☐ | Prioritätswert gesetzt | Ein RICE-, WSJF- oder ICE-Wert ist vorhanden — nicht nur „Hoch / Mittel / Niedrig“. Zahlen machen Priorisierungsentscheidungen nachvollziehbar und über das Backlog vergleichbar. | Pflicht |
| ☐ | Zuständige Person oder Team festgelegt | Eine konkrete Person oder ein Teamlabel ist gesetzt. Vorgänge ohne Verantwortung schaffen Unklarheit in der Sprint-Planung und verzögern die Einordnung bei Blockaden. | Empfohlen |
| ☐ | Richtiger Vorgangstyp | Story, Bug, Aufgabe, Epic — jeder hat andere Folgen für die Definition of Done. Ein als Story verkleideter Bug umgeht Ursachenanalyse. Ein Epic, das eine Story sein sollte, bläht das Backlog künstlich auf. | Empfohlen |
| ☐ | Labels und Komponenten gesetzt | Mindestens ein Label oder eine Komponente. Das ermöglicht Filter, Bereichsplanung und Berichte. Ohne Labels können Teams nicht beantworten: „Wie viel Arbeit ist Infrastruktur und wie viel sind neue Funktionen?“. | Empfohlen |
| ☐ | Nicht veraltet | Der Vorgang wurde in den letzten 90 Tagen aktualisiert. Ältere Vorgänge ohne Aktivität sollten hinterfragt werden: Ist das noch relevant? Sollte es archiviert oder gelöscht werden? | Empfohlen |
| ☐ | Kein Duplikat | Eine kurze Suche bestätigt, dass kein offener Vorgang für dieselbe Arbeit existiert. Duplikate verteilen Diskussion und Stimmen und verschwenden Schätzzeit für möglicherweise bereits laufende Arbeit. | Empfohlen |
| ☐ | Abhängigkeiten verknüpft | Wenn der Vorgang andere blockiert oder von ihnen blockiert wird, ist die Verknüpfung in Jira gesetzt. Unverknüpfte Abhängigkeiten bleiben in der Planung unsichtbar und überraschen mitten im Sprint als Blockaden. | Optional |
| ☐ | Fälligkeit gesetzt (falls relevant) | Bei Compliance-Arbeit, externen Zusagen oder SLA-gebundenen Bugs ist eine realistische Fälligkeit gesetzt. Nicht jeder Vorgang braucht eine — existiert sie, gehört sie aber nach Jira und nicht nur in einen Kopf. | Optional |
Die Checkliste als Definition of Ready nutzen
Eine Definition of Ready (DoR) bremst Teams nicht, sondern beschleunigt die Sprint-Planung als gemeinsame Vereinbarung. Erfüllt jeder Sprint-Eintrag denselben Mindeststandard, wird Planung zum Organisationsgespräch („Wer übernimmt was?“) statt zur Klärungsrunde („Was wird hier überhaupt verlangt?“).
Für die meisten Teams sind die fünf Pflicht -Punkte die passende Mindest-DoR. Ein Vorgang ohne Beschreibung, Akzeptanzkriterien oder Schätzung sollte unabhängig von seiner gefühlten Dringlichkeit nicht in einen Sprint. Die beim Refinement „gesparte“ Zeit fällt während des Sprints mit Zinsen an: durch Rückfragen, wiedereröffnete Vorgänge oder erst bei der Umsetzung erkannte Missverständnisse zum Umfang.
Punkt 5: Warum ein Prioritätswert mehr zählt als ein Label
Der von den meisten Teams übersprungene oder falsch umgesetzte Prüfpunkt ist der Prioritätswert. Jiras integriertes Prioritätsfeld (Höchste, Hoch, Mittel, Niedrig, Niedrigste) liefert eine Kategorie, keine Bewertung. Bei zwei „Hoch“-Vorgängen helfen Kategorien nicht: Beide sind wichtig, aber welcher wichtiger ist, bleibt offen.
Ein numerischer Prioritätswert aus RICE, WSJF oder ICE liefert eine Rangfolge. Wird Sprintkapazität knapp, verhandelt das Team nicht, sondern arbeitet die Rangliste von oben ab. Das beseitigt die größte Reibungsquelle vieler Sprint-Planungen.
Falls dein Team noch kein Bewertungsverfahren hat, siehe die Entscheidungshilfe: RICE, WSJF oder ICE — welches Verfahren passt zu deinem Team? ICE lässt sich am schnellsten einführen und braucht keine Analyseeinrichtung — ein guter Einstieg für Teams ohne bisheriges Verfahren.
Punkt 9: Das Problem veralteter Vorgänge
Veraltete Vorgänge sind das häufigste Gesundheitsproblem im Backlog — und manuell am schwersten zu verfolgen. Ein vor 18 Monaten angelegter Funktionswunsch, einmal aktualisiert und nie geschlossen, liegt noch im Backlog, beansprucht Raum in Planungsdiskussionen und ist wahrscheinlich nicht mehr relevant.
Die 90-Tage-Grenze ist eine praktische Faustregel, keine feste Vorgabe. Manche Vorgänge warten berechtigt länger — eine Compliance-Anforderung auf rechtliche Freigabe oder eine bekannte Einschränkung mit späterem Behebungstermin. Entscheidend ist, dass der Vorgang bewusst behalten wurde und ein aktueller Kommentar den Grund erklärt. Ein seit sechs Monaten ungesehener Vorgang ist etwas anderes als ein bewusst zurückgestellter.
Führe beim Refinement eine JQL-Abfrage für veraltete Kandidaten aus:
project = PROJ AND status != Done AND updated <= -90d ORDER BY updated ASC
Arbeite die Liste vom ältesten zum neuesten Eintrag durch. Schließe jeden Vorgang, ergänze aktuellen Kontext oder stelle ihn ausdrücklich mit einem Kommentar zum erneuten Prüfzeitpunkt zurück.
Von der Checkliste zur automatischen Gesundheitskennzahl
Vor jedem Refinement zwölf Punkte manuell zu prüfen, ist bei großen Backlogs aufwendig. Bei über 150 offenen Vorgängen wird die Checkliste etwas, das Teams nutzen möchten, aber selten vollständig durchgehen.
Priority Scoring for Jira verwandelt diese Checkliste in eine aktuelle Kennzahl zur Backlog-Gesundheit (Board Health Score) — einen Wert von 0–100 für die Erfüllung von bis zu acht konfigurierbaren Gesundheitskriterien. Statt zwölf Punkte manuell zu prüfen, siehst du den Wert sofort und erkennst in der Aufschlüsselung die belastenden Kriterien.
Die acht Gesundheitskriterien entsprechen direkt den Prüfpunkten:
- Fehlende Beschreibung → Prüfpunkt 2
- Fehlende Story Points → Prüfpunkt 4
- Unbewertete Vorgänge → Prüfpunkt 5 (kein Prioritätswert)
- Fehlende Zuständigkeit → Prüfpunkt 6
- Veraltete Vorgänge → Prüfpunkt 9
- Fehlende Labels → Prüfpunkt 8
- Fehlende Priorität → Prüfung des kategorischen Prioritätsfelds
- Überfällige Vorgänge → Prüfpunkt 12
Konfiguration der Backlog-Gesundheit — Kriterien pro Projekt ein- oder ausschalten, mit Scrum- und Kanban-Voreinstellungen
Du konfigurierst die aktiven Kriterien je Projekt — ein Kanban-Projekt deaktiviert die Story-Points-Prüfung, ein Projekt mit vielen Compliance-Anforderungen gewichtet Überfälligkeit stärker. Der Wert aktualisiert sich automatisch bei Vorgangsänderungen; manuelles Aktualisieren ist nicht nötig.
Wie häufig Refinement stattfinden sollte
Der Scrum Guide 2020 behandelt Refinement als laufende Tätigkeit und nicht als einmaliges Sprint-Meeting. Praktisch finden die meisten Teams einen kombinierten Rhythmus:
- Ein Refinement-Termin in der Sprintmitte (~60–90 Minuten) — wichtigste Backlog-Einträge mit der Checkliste prüfen, ungeschätzte Stories schätzen und veraltete Einträge bereinigen.
- Kontinuierliches asynchrones Refinement — neue Vorgänge erhalten sofort Beschreibung und Akzeptanzkriterien durch ihre Ersteller. Labels und Story Points werden ergänzt, bevor sie im Backlog nach oben kommen.
Die Gesundheitskennzahl zeigt objektiv, wie gut das kontinuierliche Refinement funktioniert. Sinkt sie zwischen Terminen stark, werden neue Vorgänge ohne ausreichenden Kontext erstellt — ein Prozessproblem für das Team, nicht nur ein Checklistenproblem.
Häufig gestellte Fragen
Was ist Backlog-Pflege in Jira?
Backlog-Pflege — im Scrum Guide 2020 offiziell Product Backlog Refinement — prüft und klärt Backlog-Einträge für die Sprint-Planung. In Jira bedeutet das klare Titel, Beschreibung, Akzeptanzkriterien, Story-Point-Schätzung, Prioritätswert und keine veralteten oder doppelten Einträge. Der Scrum Guide empfiehlt höchstens 10 % der Sprintkapazität für Refinement.
Was gehört auf eine Checkliste zur Backlog-Pflege?
Mindestens: klarer Titel, Beschreibung, definierte Akzeptanzkriterien, geschätzte Story Points, Prioritätswert. Zusätzliche Prüfungen gegen Nacharbeit: Zuständigkeit, richtiger Typ, Labels, keine veralteten Vorgänge (90+ Tage ohne Aktualisierung) oder Duplikate. Optional: verknüpfte Abhängigkeiten und relevante Fälligkeiten.
Wie häufig sollte Backlog-Pflege stattfinden?
Der Scrum Guide 2020 betrachtet Refinement als laufende Tätigkeit statt feste Zeremonie. Die meisten Teams kombinieren einen Termin in der Sprintmitte mit kontinuierlicher asynchroner Klärung neuer Vorgänge. Insgesamt sollte Refinement unter 10 % der Sprintkapazität bleiben. Bei regelmäßig längeren Terminen zeigt die Checkliste oben normalerweise die Ursache.
Was unterscheidet Backlog-Pflege und Sprint-Planung?
Pflege (Refinement) bereitet Vorgänge für künftige Sprints vor — klären, schätzen und ordnen. Sprint-Planung wählt aus dem vorbereiteten Backlog und sagt ein Sprintziel zu. Pflege sollte über den Sprint hinweg erfolgen, damit die Planung Auswahl und Zusage fokussiert statt erst die Bedeutung von Tickets zu entdecken.
Wie automatisiere ich Prüfungen der Backlog-Gesundheit in Jira?
Priority Scoring for Jira enthält eine Kennzahl zur Backlog-Gesundheit (0–100), die acht konfigurierbare Kriterien automatisch überwacht — fehlende Beschreibungen, Story Points, Zuständigkeit, Priorität und Labels sowie veraltete, unbewertete und überfällige Vorgänge. Sie aktualisiert sich bei Änderungen automatisch, sodass du ohne manuelle Checkliste immer einen aktuellen Wert hast. Mehr dazu: Jira-Backlog-Gesundheit: Deine Projektqualitätskennzahl messen.
Diese Checkliste mit einer aktuellen Gesundheitskennzahl automatisieren
Priority Scoring for Jira prüft dein Backlog automatisch auf acht Gesundheitskriterien — damit sich Refinement auf Entscheidungen statt fehlende Felder konzentriert.
Im Marketplace kostenlos testen →