So bleibt euer Product Backlog für euer Team genau richtig dimensioniert

Leider sind die meisten Product Backlogs viel zu groß und verursachen bei unvorbereiteten Product Owners jede Menge Stress und Chaos. Vermeidet dieses Schicksal. Lest weiter und erfahrt, wie ihr feststellen könnt, ob euer Backlog die richtige Größe hat.

Wenn ihr eure optimale Größe kennt, könnt ihr nicht nur die richtigen Einträge in das Backlog aufnehmen, sondern auch die Bereinigung, Prüfung und Refinement-Aktivitäten sicher steuern.

Dadurch liefert euer Team mehr Mehrwert, und euer Arbeitsalltag wird deutlich einfacher.

Wie groß ein Backlog sein sollte

Als Faustregel für die Anzahl der Einträge gilt: Ein Backlog sollte zwischen 50 und 150 Einträge enthalten. Auch hier gilt: Kleiner ist besser. Wenn ihr näher bei 150 liegt, versucht, Einträge aus dem Backlog zu entfernen.

Es gibt außerdem eine Regel für die Kalenderzeit, die das Team benötigen sollte, um alles im Backlog umzusetzen. Strebt dabei einen Arbeitsumfang von zwei bis sechs Monaten an.

Natürlich sind dies allgemeine Regeln. Es kann Situationen und Rahmenbedingungen geben, die längere oder kürzere Backlogs erfordern.

Euer Backlog sollte nicht der einzige Ort für Arbeit sein

Product Owners versuchen oft, die gesamte Arbeit an einem einzigen Ort zu verwalten – im Backlog. Das ist völlig falsch.

Das Backlog sollte nur Arbeit mit hoher Verbindlichkeit enthalten. Arbeit mit geringerer Verbindlichkeit – etwa Ideen und noch nicht genehmigte Anfragen – könnt ihr an anderen Orten verwalten, beispielsweise in Roadmaps oder Wunschlisten.

• Wunschlisten können Arbeit enthalten, die interessant ist, aber noch untersucht werden muss oder weitere Signale erfordert, bevor sie für das Backlog genehmigt werden kann.

• Roadmaps können die Entwicklung des Produkts weiter in die Zukunft abbilden – bis zu mehreren Jahren.

Wenn all diese Arbeit in das Backlog aufgenommen wird, verwirrt das das Team und die Stakeholder. Das Backlog sollte eine kurze, priorisierte Liste von Arbeit mit hoher Verbindlichkeit bleiben.

Wenn ihr als Product Owner Arbeit mit geringerer Verbindlichkeit an anderen Orten verwaltet, lässt sich die Größe des eigentlichen Backlogs leichter steuern.

Signale dafür, dass euer Backlog zu groß ist

Eine einfache Möglichkeit, ein übergroßes Backlog zu erkennen, ist die Anzahl der Einträge. Backlogs sollten unter 150 Einträgen bleiben. Wächst es auf 200, 300 oder 400 Einträge an, ist das Backlog viel zu groß.

Ähnliche Signale liefert die Kalenderzeit. Wenn ihr schätzt, dass das Team mehr als ein halbes Jahr braucht, um die gesamte Arbeit im Backlog abzuschließen, ist es zu groß.

Ein weiteres Signal, auf das ihr achten solltet: Euer Team zögert, das Backlog durchzugehen. Hat das Backlog die richtige Größe, ist es nicht so schwer, das Team dazu zu bewegen. Ist es jedoch zu groß, wird das Team nicht motiviert sein, es durchzugehen, weil es weiß:

• Es wird zu viel Zeit kosten.

• Sie werden Einträge durchsehen, von denen sie wissen, dass sie nie umgesetzt werden.

• Einige Einträge liegen so weit in der Zukunft, dass mit hoher Wahrscheinlichkeit zuerst wichtigere entdeckt werden.

Auch wenn es gut ist, unter 150 Einträgen zu bleiben, solltet ihr ein noch kleineres Backlog anstreben. Ihr und euer Team verbringen bei 150 Einträgen mehr Zeit mit der Verwaltung des Backlogs als bei 50. Auf 50 Einträge zu kommen, ist schwierig, vielleicht sogar unmöglich. Doch der Versuch, es klein zu halten, hilft euch, fokussierter zu bleiben.

Signale dafür, dass euer Backlog zu klein ist

Ein zu kleines Backlog ist zwar weniger häufig als ein zu großes, kann aber ebenfalls problematisch sein.

Wenn euer Team beispielsweise gerade mit der Entwicklung eines Produkts beginnt, ist euer Backlog möglicherweise nahezu leer. Die Frage ist dann: Wie baut ihr während der Entwicklung von Produkt und Architektur das Backlog so auf, dass die Stakeholder eingebunden bleiben, weiterhin Feedback gesammelt wird und sich das Produktkonzept weiterentwickelt?

Ein Signal, auf das ihr achten solltet, ist ein Backlog mit wenigen Einträgen, das sich über die Zeit nicht verändert. Eine geringe Anzahl von Einträgen allein ist kein aussagekräftiges Signal. Wenn sich die Einträge jedoch gleichzeitig nicht ändern, ist das ein klares Zeichen dafür, dass das Backlog nicht funktioniert.

Dafür kann es mehrere Ursachen geben:

• Das Team beginnt möglicherweise mit Arbeit, die nicht im Backlog steht.

• Der Product Owner stimmt sich möglicherweise nicht ausreichend mit Kunden und anderen Stakeholdern ab.

So haltet ihr ein Backlog in der optimalen Größe

Um das Backlog auf der optimalen Größe zu halten, müsst ihr sicherstellen, dass der Zufluss neuer Einträge dem Abfluss abgeschlossener Einträge entspricht. Doch genau hier liegt eine häufige Falle.

Als Product Owner müsst ihr die Velocity kennen. Wenn ihr jedoch versucht, die Geschwindigkeit der Freigaben exakt an die Umsetzungsgeschwindigkeit anzupassen, werdet ihr fast sicher scheitern. Dafür müssten alle Backlog-Anfragen stets einen ähnlichen Wert und eine ähnliche Priorität haben – und das ist in der Regel nicht der Fall.

Besser ist es, das regelmäßige Pflegen und Bereinigen von Einträgen einzuplanen, die aus dem Backlog entfernt werden sollen. Das sollte gemeinsam mit dem Team erfolgen.

Ein guter Ansatz dafür ist die „Scan-and-Plan“-Praxis, die ich in diesem Blogbeitrag beschreibe. In einer der regelmäßigen wöchentlichen Backlog-Refinement-Sessions verfeinert das Team nicht nur die Einträge oben im Backlog, sondern prüft auch den Rest, um Einträge zu bereinigen und neu zu priorisieren. Scan-and-Plan ist eine regelmäßige monatliche Aktivität.

Auf einer übergeordneten Ebene haben die meisten Unternehmen Praktiken für die längerfristige Planung etabliert. Diese können dem Product-Increment-Planning von SAFe ähneln oder ihm folgen.

Solche Planungssessions können alle zwei bis drei Monate stattfinden und bieten ebenfalls Gelegenheit, Einträge aus dem Backlog zu entfernen, die nicht umgesetzt werden. Auch hier könnt ihr den „Scan-and-Plan“-Ansatz in Betracht ziehen.

Die Methode der vier R

In „Scan-and-Plan“-Sessions könnt ihr die Methode der vier R anwenden. Dabei werden Backlog-Einträge in umgekehrter Prioritätsreihenfolge oder nach ihrem Alter – von den ältesten zu den neuesten – überprüft.

Die vier R:

• Remove

• Reprioritize

• Reinvent

• Reduce

Remove bedeutet, dass ihr entscheidet, dass ein Eintrag nicht ins Backlog gehört. Verschiebt ihn in diesem Fall in den passenden Workflow-Status, etwa „abgelehnt“, „verschoben“ oder einen ähnlichen Status.

Es ist besser, einen Backlog-Eintrag zu behalten und seinen Status so zu ändern, dass erkennbar ist, dass er nicht umgesetzt wird, statt ihn zu löschen. Vergesst dabei nicht, den Urheber und interessierte Stakeholder über die Ablehnung zu informieren.

Wenn ihr den Eintrag nicht entfernt, müsst ihr ihn ändern oder neu priorisieren. Sowohl Reinventing als auch Reducing bedeuten, den Eintrag zu verändern. Reinventing bedeutet, zum ursprünglichen Problem zurückzukehren und den Ansatz neu zu überdenken. Reducing bedeutet, den Eintrag zu vereinfachen.

Die richtige Backlog-Größe sorgt für ein motiviertes Team, das Mehrwert schafft

Hat das Backlog die optimale Größe, kann euer Team darauf vertrauen, stets an den wichtigsten Aufgaben zu arbeiten. Das motiviert es auch, das Backlog zu verfeinern, und unterstützt den Product Owner bei dessen Pflege.

Als Product Owner liegt es an euch, die richtige Backlog-Größe für euer Produkt, euer Team und euer Umfeld zu kennen.