Verrottendes Backlog: aufräumen ohne einen ganzen Tag

Warum Ihr Backlog verrottet (und es ist nicht Ihre Schuld)

Ein Backlog beginnt immer sauber. Zwanzig Items, ein Team, das weiß, warum jedes da ist. Dann wächst es. Bei 200 Items wird es mühsam. Jenseits von 500 wird es zu einem Passivposten.

Das Problem ist nicht die Menge. Es ist, dass alles auf derselben Ebene liegt. Eine Authentifizierungs-Migration und eine Button-Farbänderung landen nebeneinander und streiten sich um denselben Prioritätsslot. Wie ein von ProdPad zitierter Head of Product es zusammenfasst, war sein Backlog zu „einem Friedhof mit Suchleiste“ geworden: über 400 Items, die sich über zwei Jahre angesammelt hatten, alle mit dem Tag „Ideen“ versehen.

Wenn alles flach liegt, kehren drei Muster systematisch wieder:

• Priorisierung nach Volumen. Das Item mit den meisten Stimmen oder dem lautesten Fürsprecher gewinnt. Eine geringfügige UI-Reibung, die zehnmal erwähnt wurde, überholt eine Architekturentscheidung, die niemand außerhalb des Engineerings versteht.
• Der Recency-Bias. Worüber zuletzt am meisten gesprochen wurde, erscheint am wichtigsten. Das Backlog wird zu einer Warteschlange, nicht mehr zu einem Strategiewerkzeug.
• Die falsche Gleichsetzung. Man wendet dasselbe RICE-Scoring auf alles an, als ob die „Reach“ einer Plattform-Migration dasselbe bedeutete wie die eines Tooltips. Die Zahl erzeugt eine Illusion von Strenge, aber die Eingaben sind nicht vergleichbar.

Die gute Nachricht: Sie brauchen keine dreistündige Besprechung, um das aufzuholen. Drei kurze Durchgänge, regelmäßig wiederholt, genügen.

Durchgang 1 — Löschen: 20 Minuten, keine Debatte

Ziel: alles entfernen, was nie umgesetzt wird. Einfache Regel: Wenn niemand einen konkreten Nutzer oder ein konkretes Ziel nennen kann, dem dieses Item dient, fliegt es raus.

Konkret löschen Sie:

• Items, die vor mehr als sechs Monaten erstellt, nie priorisiert wurden und an die sich niemand erinnert.
• Ideen, die aus einem Slack-Thread kopiert und eingefügt wurden, ohne Kontext oder identifiziertes Problem.
• Die „vielleicht sollten wir mal …“ ohne Verantwortlichen oder Frist.
• Verkleidete Duplikate (darauf kommen wir in Durchgang 2 zurück).

Versuchen Sie nicht, ordentlich zu archivieren. Löschen Sie. Wenn die Idee gut war, kommt sie wieder — und diesmal mit einem echten Problem dahinter.

In einem Tool wie Ever Earlier ist dieser Durchgang mechanisch: Sie filtern nach Erstellungsdatum und nach fehlender Priorität, Sie löschen in Massen. Keine Besprechung, keine Excel-Tabelle, die gepflegt werden muss.

Durchgang 2 — Zusammenführen: Duplikate erkennen und bündeln

Nach dem Löschen bleiben oft Items übrig, die denselben Bedarf aus drei verschiedenen Blickwinkeln beschreiben. Das ist normal: Drei Personen sind zu drei Zeitpunkten auf dasselbe Problem gestoßen.

Das Zusammenführen geschieht auf der Ebene des Problems, nicht der Lösung. Zwei Items, die unterschiedliche Lösungen für dasselbe Problem vorschlagen, ergeben nur eines.

Konkretes Beispiel. Drei getrennte Items:

• „Sehen können, wer eine Karte geändert hat“
• „Änderungsverlauf einer Aufgabe“
• „Wissen, wann eine Story verschoben wurde“

Ein einziges Problem: die Nachverfolgbarkeit von Änderungen. Eine einzige User Story nach dem Zusammenführen, mit einem klaren Akzeptanzkriterium: „Als Projektleiter sehe ich die chronologische Liste der Änderungen einer Karte, mit Autor und Datum, um zu verstehen, was sich seit meinem letzten Besuch geändert hat.“

In Ever Earlier deckt das Aktivitätsprotokoll diesen Bedarf bereits auf der Tool-Seite ab — aber die Übung gilt für Ihr eigenes Backlog. Eine zusammengeführte Story mit Priorität, Punkten und Akzeptanzkriterien ersetzt drei vage Items. Sie teilen den Lärm durch drei.

Durchgang 3 — Priorisieren: erst Wert, dann Größe

Jetzt bleiben Items übrig, die eine Entscheidung verdienen. Zwei Fragen, in dieser Reihenfolge:

1. Welcher Wert? Wer ist betroffen, wie viele, und wie stark? Wenn Sie das nicht in einem Satz beantworten können, ist das Item nicht bereit — es geht zurück in die Diskussion, nicht in den Sprint.
2. Welche Größe? Eine Story mit 13 Punkten, die seit drei Sprints herumliegt, ist keine Story, sondern ein verkleidetes Projekt. Zerlegen Sie sie.

Hier sparen strukturierte User Stories Zeit. Eine Story mit Priorität, Schätzung in Punkten und Akzeptanzkriterien ist in dreißig Sekunden beurteilt. Eine Story ohne diese Elemente löst bei jedem Planning eine zehnminütige Diskussion aus.

Ein nützliches Prinzip aus der Theory of Constraints: Überlasten Sie nicht den Engpass. Wenn Ihr Team 20 bis 35 Items pro Monat merged oder ausliefert, entspricht ein aktives Backlog von 200 Items einer durchschnittlichen Wartezeit von etwa 6,7 Monaten. Das ist kein temporäres Backlog, das ist das, was das System bei dieser Last produziert. Die Arbeit in Bearbeitung zu reduzieren ist effektiver, als Reviews hinzuzufügen.

Refactoring gehört nicht ins Backlog

Klassische Versuchung nach einer großen Aufräumaktion: „Refactoring-Stories“ hinzufügen, um den technischen Rückstand aufzuholen. Ron Jeffries erklärt, warum das eine schlechte Idee ist: Vom Product Owner Zeit zu erbitten, um zu reparieren, was man selbst beschädigt hat, ist schwer zu verkaufen, und das Ergebnis enttäuscht — man räumt auf, was man sieht, in der Zeit, die man hat, nie genug.

Der richtige Ansatz ist einfacher: Bei jedem neuen Feature räumt man den Code auf, den man durchquert. Man weicht nicht um das Gestrüpp herum, man rodet ein Stück davon. Manchmal dauert das Feature etwas länger. Oft nicht, weil das Aufräumen schon beim ersten Feature hilft, das dort durchkommt.

Konsequenz für Ihr Backlog: Setzen Sie keine „Refactoring“-Zeilen hinein. Setzen Sie Features hinein, und lassen Sie das Aufräumen darin geschehen.

Die Kadenz zählt mehr als die Tiefe

Ein Durchgang von 20 Minuten alle zwei Wochen ist besser als eine dreistündige Sitzung alle sechs Monate. Das Backlog verschmutzt nicht auf einmal, es wird auch nicht auf einmal sauber.

Drei Regeln, um durchzuhalten:

• Ein Durchgang, ein Ziel. Löschen heißt löschen. Man priorisiert nicht, während man löscht.
• Ein Verantwortlicher pro Durchgang. In der Regel der Product Manager oder der Projektleiter, nicht das ganze Team.
• Ein Tool, das keine Reibung hinzufügt. Wenn das Aufräumen des Backlogs mehr Aufwand erfordert als das Füllen, werden Sie es nicht tun.

In Ever Earlier machen User Stories mit Priorität, Punkten und Akzeptanzkriterien diesen Durchgang schnell: Sie sehen sofort, welche Items bereit sind, welche vage sind, welche keinen Sinn mehr ergeben. Backlog und Sprints leben am selben Ort, also duplizieren Sie nichts.