Unsortiere Backlogs: Warum eine klare Struktur im Backlog kein nice to have ist

Der Product Backlog ist kein Berg aus Zetteln und Notizen, auf dem man seine Gedanken einfach immer weiter abladen kann. Er ist ein strategisches Werkzeug, dass dem Product Owner bei der Umsetzung seiner Vision und der Ziele hilft. Wenn ein Backlog jedoch immer größer wird passieren folgende Dinge:

• Alles erscheint gleich wichtig: Keine klare Priorität der Themen, da alles unsortiert und nicht nach Priorität ausgerichtet ist
• Das Team verliert den Fokus: Eine unklare Priorität und Sortierung der Aufgaben vermittelt kein klares Zielbild und Vision
• Planbarkeit geht verloren: Da es keine klare Struktur gibt, lässt sich auch nur schwer einordnen welchen Themen relevant sind und zu wann diese angegangen werden
• Ineffiziente Meetings: Das Sprint-Planning und das Backlog-Refinement werden zäh und lang, da das Team keine klare Vision hat und unsortierte User-Stories einzeln anschauen muss um einen Überblick zu erhalten

Der Product Backlog ist mehr als nur ein Parkplatz für Ideen und User Stories und Bedarf einer regelmäßigen Pflege, Sortierung und Priorisierung um Vision mit der Roadmap in Einklang zu bringen

Neben dem offensichtlichen Berg an unsortierten Aufgaben führt ein ungepflegter Backlog unweigerlich zu folgenden Punkten:

• Ineffiziente Nutzung von Ressourcen: Das agile Team befasst sich im Worst Case mit veralteten User Stories oder setzt Themen um, die zum jetzigen Zeitpunkt noch keine Relevanz haben.
• Aufbau von technischen oder organisatorischen Schulden: Umsetzung alter, geschätzter User Stories, die potenziell nicht mehr dem aktuellen Zielbild in fachlicher sowie technischer/architektonischer Sicht folgen.
• Beeinträchtigung der Transparenz und Zusammenarbeit: Das agile Team verliert die Orientierung, weil alle Aufgaben gleich wichtig erscheinen, kein Zielbild existiert oder keine klare Vision vorhanden ist.

Als Produkt Owner im agilen Umfeld trägt man die Verantwortung für das entstehende Produkt. Sich der Lage bewusst werden ist der erste und wichtigste Schritt. Darauf folgend sollte man sich anhand der Gesamt-Roadmap orientieren, die eigenen User Stories und Epics in Quartals-Ziele einsortieren und von dort aus den Backlog ausrichten. Dabei kann sich der Product Owner folgender Methoden bedienen: 

• MoSCoW-Methode ->  Must have, Should have, Could have, Won't have 
• WSJF Methode -> Weighted Shortest Job First Diese Methoden helfen eine gewisse Priorität zu vergeben und nicht alles als gleich wichtig zu deklarieren.

Im Kern steht immer der Kundennutzen. Auf keinen Fall darf man den Status Quo walten lassen und auf Besserung hoffen, denn ein ungepflegter Backlog wirkt sich negativ auf das Produkt und am Ende das Kundenerlebnis aus.

Abhilfe schaffen regelmäßige Termine abseits des Refinements mit dem Team. Als Produkt Owner solllte man sich im Idealfall einmal wöchtenl. einen festen Zeitslot nehmen um sein Backlog zu begutachten. Weiterhin gilt:

• Ordnung schaffen -> Anhand der beiden genannten Methoden Priorität und Ordnung herstellen Entstauben -> Veraltete Anforderungen oder solche die obsolet geworden sind löschen
• Rollen festlegen -> Verantwortung, Pflege und Priorisierung des Backlogs und dessen Aktualität liegen klar in der Verantwortung des Product Owners
• Sichtbarkeit und Transparenz -> Regelmäßiger Austausch mit den Stakeholdern und dem agilen Team, helfen beim gemeinsamen Blick auf die Vision und das Zielbild  

Zusammenfassend lässt sich sagen, dass ein Product Backlog kein Abstellgleis für Ideen und Aufgaben sein darf. Es ist ein essentielles Steuerinstrument für den Product Owner, dass ohne Struktur und Aufmerksamkeit schnell zur Bremse wird und nicht mehr den Kundennutzen im Fokus hält.