Wachsender Backlog: die Regel für Ein- und Ausgänge

Der wachsende Backlog: drei Symptome, die nicht täuschen

Sie öffnen Ihr Board am Montagmorgen und die erste Spalte zählt 400 Karten. Sie scrollen. Sie schließen. Sie fügen eine weitere hinzu. Das ist das Zeichen, dass Ihr Backlog kein Priorisierungswerkzeug mehr ist, sondern ein Tagebuch.

Drei Symptome kehren wieder:

• Das Planungsritual, das sich endlos zieht. Jeden Sprint geht man die Liste erneut durch, argumentiert, wählt danach aus, wer diese Woche am lautesten gesprochen hat.
• Alte Einträge, die nie sterben. Eine Idee, die vor acht Monaten eingereicht wurde, bleibt „in Wartestellung“, ohne dass jemand weiß, warum.
• Absurde Vergleiche. Man stellt „Authentifizierung migrieren“ und „Farbe des Onboarding-Buttons ändern“ nebeneinander, als handele es sich um dieselbe Art von Entscheidung.

Diese drei Symptome haben dieselbe strukturelle Ursache: einen flachen Backlog. Wenn alles auf derselben Ebene liegt, beginnt jede Prioritätsdiskussion wieder bei null.

Die Ebenen trennen, bevor irgendetwas gemessen wird

Das Modell der Flight Levels beschreibt drei Entscheidungsebenen: strategisch (wo investieren), koordinativ (wie die Arbeit zwischen den Teams fließt) und operativ (wie ein Team ausführt). Jede Ebene hat ihren Rhythmus, ihre Entscheider und ihre Definition von „fertig“.

Wenn eine Organisation alles auf einer einzigen Ebene steuert, werden strategische Entscheidungen in operativen Debatten ertränkt, und taktische Anpassungen erhalten dieselbe Feierlichkeit wie eine Plattform-Wette. Nichts kommt im richtigen Tempo voran.

Konkret: Bevor Sie Ein- und Ausgänge zählen, sortieren Sie:

• Strategisch: „Sollen wir unser Zahlungssystem ersetzen?“ — vierteljährliche Entscheidung, wenige Leute im Raum.
• Koordinativ: „Welche Initiative bearbeitet dieses Quartal welches Kundenproblem?“ — monatliche Überprüfung.
• Operativ: „Welche User Story kommt in diesen Sprint?“ — wöchentliche Entscheidung des Teams.

Ein Eintrag, der nicht zur Ebene des laufenden Meetings gehört, hat dort nichts zu suchen. Dieser einfache Filter eliminiert die Hälfte der sterilen Debatten.

Warum ein gesättigter Backlog exponentiell verlangsamt

Die Warteschlangentheorie auf die Produktentwicklung angewandt liefert ein kontraintuitives Ergebnis: Wenn eine Ressource sich 100 % Auslastung nähert, wächst die Warteschlange exponentiell, nicht linear. Die Formel M/M/1 lautet Wartezeit = Auslastung / (1 − Auslastung). Bei 50 % Auslastung beträgt die Wartezeit 1×. Bei 80 % 4×. Bei 90 % 9×. Bei 95 % 19×.

Anders gesagt: Je stärker Sie Ihre Kapazität ausreizen, desto mehr explodiert die Warteschlange. Eine Exponentialfunktion holen Sie nicht auf, indem Sie mehr arbeiten.

Das Gesetz von Little liefert die andere Hälfte des Bildes: Durchlaufzeit = Arbeit in Bearbeitung / Durchsatz. Ein dokumentiertes Open-Source-Projekt hatte etwa 200 offene Pull Requests und merge-te 20 bis 35 PRs pro Monat: Die durchschnittliche Durchlaufzeit ergab etwa 6,7 Monate. Das ist kein vorübergehender Backlog, das ist das normale Verhalten des Systems bei dieser Last.

Dieselbe Logik gilt für Ihren Backlog: Wenn Sie 180 offene Einträge haben und 6 pro Sprint liefern, beträgt Ihre durchschnittliche Durchlaufzeit 30 Sprints. Diese Zahl, im Meeting gezeigt, verändert die Diskussion oft wirksamer als eine Meinungsdebatte.

Die Tracking-Tabelle für Ein- und Ausgänge, in fünf Spalten

Sie brauchen kein ausgeklügeltes Werkzeug. Eine geteilte Tabellenkalkulation genügt, vorausgesetzt, sie wird jede Woche zur selben Zeit von derselben Person ausgefüllt.

Fünf Spalten:

1. Woche — das Datum der Erhebung.
2. Eingänge — Anzahl der diese Woche zum Backlog hinzugefügten Einträge.
3. Gelieferte Ausgänge — Einträge, die auf „abgeschlossen“ gesetzt und tatsächlich nutzbar sind.
4. Verworfene Ausgänge — Einträge, die ausdrücklich geschlossen wurden, ohne geliefert zu werden.
5. Gesamt offen — der Saldo am Ende der Woche.

Zwei Verhältnisse berechnen sich von selbst:

• Verhältnis Eingänge/Ausgänge = Eingänge ÷ (geliefert + verworfen). Über 1 wächst der Backlog. Unter 1 schrumpft er.
• Medianes Alter der offenen Einträge — die Hälfte der offenen Einträge ist älter als diese Anzahl von Wochen. Wenn sie 12 überschreitet, ist Ihr Backlog eine Archivierung, kein Plan.

Die Zahl, die eine Aktion auslöst, ist das Verhältnis Eingänge/Ausgänge über vier aufeinanderfolgende Wochen. Bleibt es über 1,2, haben Sie ein Problem mit der Obergrenze, nicht mit der Produktivität.

Eine Plattform wie Ever Earlier zeigt ein Aktivitätsprotokoll pro Karte und pro Spalte: Sie können diese Zahlen rekonstruieren, ohne eine parallele Tabelle zu führen, indem Sie die im Zeitraum erstellten und abgeschlossenen Karten filtern.

Eine Obergrenze pro Sprint festlegen (und einhalten)

Eine Obergrenze für Eingänge ist keine Grenze für die Vorstellungskraft. Sie ist eine Grenze für die akzeptierte Arbeit. Der Unterschied ist wesentlich, wenn Sie ihn ankündigen.

Drei einfache Regeln:

• Obergrenze für Eingänge: zum Beispiel 5 neue Einträge pro Sprint und Team. Darüber hinaus geht der Eintrag in eine Liste „zu qualifizieren“, die nicht der aktive Backlog ist.
• Verpflichtende Ausgangsschwelle: Jeder Eintrag, der seit mehr als 8 Sprints offen ist, wird entweder in den nächsten 2 Sprints geplant oder geschlossen. Keine Grauzone.
• Bereinigungsbudget: 10 bis 15 % der Sprint-Kapazität reserviert für Grooming und das Schließen veralteter Einträge. Das ist keine verlorene Zeit, das ist es, was verhindert, dass die Warteschlange explodiert.

Die Obergrenze muss sichtbar sein. Auf einem Kanban-Board genügt eine Spalte „Zu qualifizieren“ mit einem Zähler. Wenn sie voll ist, diskutiert man nicht mehr über das Hinzufügen, sondern darüber, was man entfernt.

Achten Sie darauf, die Obergrenze für Eingänge nicht mit der Obergrenze für laufende Arbeit zu verwechseln. Erstere begrenzt, was in den Backlog gelangt; letztere begrenzt, was in Bearbeitung ist. Beide sind nützlich, aber sie ersetzen einander nicht.

Nein sagen ohne Konflikt: vier Skripte zum Wiederverwenden

Die meisten Konflikte rund um den Backlog entstehen nicht aus Uneinigkeit über den Wert der Idee, sondern aus einem Missverständnis darüber, was „zum Backlog hinzufügen“ bedeutet. Richten Sie das Gespräch auf die Kosten aus, nicht auf den Verdienst.

Skript 1 — Wenn ein Führungskraft im Meeting eine Idee hinzufügt

„Ich notiere die Idee, sie ist berechtigt. Um sie in den laufenden Sprint aufzunehmen, muss etwas anderes heraus: Hier sind die drei Einträge auf derselben Prioritätsstufe. Welchen verschieben wir?“

Sie lehnen nicht ab. Sie machen die Kosten sichtbar.

Skript 2 — Wenn eine Stakeholderin auf der Dringlichkeit beharrt

„Einverstanden, was die Dringlichkeit betrifft. Unsere Eingangsobergrenze für diesen Sprint ist erreicht. Zwei Optionen: Wir behandeln sie im nächsten Sprint mit hoher Priorität, oder wir verschieben Eintrag X, der geplant war. Was bevorzugen Sie?“

Skript 3 — Wenn ein Eintrag seit Monaten schlummert

„Dieser Eintrag ist seit sechs Monaten offen, ohne geplant worden zu sein. Ist er noch aktuell? Wenn ja, planen wir ihn in den nächsten zwei Sprints. Wenn nicht, schließen wir ihn und behalten eine Notiz für die Historie.“

Skript 4 — Wenn man Ihnen vorwirft, „zu allem Nein zu sagen“

„Wir sagen nicht Nein zu den Ideen, wir sagen Nein zum Anhäufen. Jeder Eintrag, den wir hinzufügen, ohne einen anderen zu entfernen, verlängert die Lieferzeit aller anderen. Hier ist die Zahl der Woche.“

Diese vier Skripte funktionieren, weil sie die Entscheidung verschieben: Es geht nicht mehr um „deine Idee gegen meine“, sondern um „welcher Eintrag geht raus, damit dieser reinkommt“.

Und das Refactoring? Es gehört nicht in den Backlog

Klassische Frage: Sollte man Refactoring-User-Stories im Backlog anlegen? Die Antwort, vor langer Zeit von Ron Jeffries formuliert, gilt weiterhin: Es ist eine schlechte Idee.

Ein großes Bereinigungsvorhaben ist schwer zu verkaufen, und wenn es verkauft ist, bringt es nach langer Verzögerung weniger als erwartet. Der richtige Ansatz ist inkrementell: Wenn Sie die nächste Funktionalität bauen, umgehen Sie die problematischen Bereiche nicht, sondern bereinigen Sie den Weg, den Sie durchqueren. Sie ignorieren den Code, den Sie nicht anfassen müssen.

Manchmal dauert die Funktionalität etwas länger. Oft nicht, weil die Bereinigung schon beim ersten Feature hilft, das dort durchläuft. Und beim nächsten Mal ist der Nutzen unmittelbar.

Praktische Konsequenz für Ihren Backlog: Legen Sie keine generischen Einträge „technische Schuld“ an. Fügen Sie stattdessen ein Abnahmekriterium zur laufenden User Story hinzu, etwa „Modul X ist vor dem Produktivgang durch Tests abgedeckt“. Die Bereinigung wird zu einer Eigenschaft des Features, nicht zu einem separaten Vorhaben.

Das wöchentliche Ritual: 30 Minuten, fünf Fragen

Eine Tracking-Tabelle nützt nichts, wenn sie nicht gelesen wird. Blockieren Sie 30 Minuten pro Woche, außerhalb der klassischen agilen Zeremonien, mit der Person, die den Backlog führt.

Fünf Fragen, in dieser Reihenfolge:

1. Wie viele Einträge sind diese Woche eingegangen? Von wem?
2. Wie viele sind hinausgegangen, geliefert oder verworfen?
3. Wie hoch ist das Verhältnis Eingänge/Ausgänge über die letzten vier Wochen?
4. Welche offenen Einträge sind älter als 8 Sprints? Was machen wir mit ihnen?
5. Ist die Eingangsobergrenze des nächsten Sprints bereits erreicht?

Wenn die Antwort auf Frage 5 ja lautet, beginnt das nächste Planungsmeeting mit einer Entscheidung zum Entfernen, nicht zum Hinzufügen. Das unterscheidet einen lebendigen Backlog von einem Friedhof mit Suchleiste.

Auf Ever Earlier können Sie die Karten im Aktivitätsprotokoll nach Erstellungsdatum und Status filtern und die Ansicht für das Meeting exportieren. Der KI-Agent, der User Stories aus Epics generiert, bleibt nützlich, vorausgesetzt, man nutzt ihn nicht, um den Backlog schneller zu füllen, als man ihn leert.