In dieser Folge dreht sich alles um ein Thema, das viele Product Owner in der Praxis betrifft: Mehrere Backlogs. Obwohl die Regel im agilen Kontext „Ein Produkt, ein Product Backlog“ lautet, zeigt die Realität oft andere Szenarien. Dominique und Tim erklären wie man als Product Owner damit umgehen kann, wenn man gezwungen ist, mehr als ein Backlog zu verwalten.
Bei mehreren Backlogs gibt es einige Herausforderungen. Oft entstehen sie, wenn ein Team an mehreren Produkten oder Services arbeitet, was die Organisation von Prioritäten erschwert. Ein weiteres häufiges Szenario ist die Aufteilung von Aufgaben nach Prozessschritten, etwa ein separates UX-Backlog oder ein Bug-Backlog. Diese unterschiedlichen Quellen und Aufteilungen führen leicht zu einem Verlust der Übersicht. Was ist wirklich wichtig, und welches Backlog hat Vorrang? Product Owner stehen dann oft vor der Frage, wie sie die Transparenz wahren und gleichzeitig strategisch arbeiten können, ohne sich in operativen Details zu verlieren.
Die Lösung liegt häufig in einer besseren Organisation und klaren Strukturen. Statt mehrere Backlogs isoliert zu pflegen, empfiehlt es sich, alle Aufgaben in einem System wie Jira zu bündeln und mit Labels oder Filtern zu arbeiten. Dies erleichtert die Priorisierung und schafft eine „Single Source of Truth“ für alle Beteiligten. Zudem kann es sinnvoll sein, Ideen oder potenzielle Features zunächst außerhalb des eigentlichen Product Backlogs zu sammeln. Diese sollten jedoch nicht als zusätzliche Backlogs betrachtet werden, sondern als unterstützende Tools im Discovery-Prozess. Sobald eine Idee reif genug ist, gehört sie ins Product Backlog, um die Arbeit des Teams zu strukturieren und zu priorisieren.
Ein weiterer Ansatz ist die Visualisierung der Arbeitsprozesse. Indem die Reise von Ideen und Anforderungen durch den Produktentwicklungsprozess sichtbar gemacht wird, können Teams und Stakeholder besser verstehen, wo welche Prioritäten liegen und welche Schritte nötig sind, um Ziele zu erreichen. Gleichzeitig gilt: Mut zur Einfachheit. Nicht jede Idee oder jedes Feedback muss umgesetzt werden. Wer mutig genug ist, Überflüssiges zu eliminieren, schafft Raum für das Wesentliche.
Am Ende gilt vor allem: Für Product Owner, die mit mehreren Produkten und Backlogs arbeiten, ist eine klare Priorisierung entscheidend. Wenn spontane Aufgaben auftreten, hilft eine vorab festgelegte Rangordnung, Konflikte zu vermeiden und die Effizienz zu steigern.
Sie sehen gerade einen Platzhalterinhalt von Podigee. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenWir sind natürlich gespant zu lesen, wie ihr mit solchen Herausforderungen umgeht. Gibt es bei euch überhaupt mehrere Backlogs? Wenn ja, wie geht ihr damit um? Habt ihr Tipps und Tricks, die ihr gerne weitergeben wollt? Wir freuen uns über eure Kommentare, entweder hier oder auf LinkedIn.
1 Kommentar zu „Ein Produktteam, mehrere Backlogs“
Hallo liebe Produktwerker,
danke für eure wie immer hilfreichen Denkanstöße und Tipps für die tägliche Arbeit im agilen Umfeld.
Zum Thema “Ein Produktteam, mehrere Backlogs” erlebe ich gerade in meinem Projekt einen Fall, den ihr in eurer Podcast-Folge nicht diskutiert habt. Daher teile ich ihn hier mit euch und und würde mich natürlich für euren Blick darauf interessieren.
Konkret wird bei uns aktuell versucht aus dem Backlog des einen Entwicklungsteams einzelne Bereiche nach Disziplinen rauszuschneiden und wie folgt in separate Backlogs zu legen:
1. Die Aufgaben des PO bzw. der Requirements Engineers sind sowieso schon immer in einem separaten Backlog gewesen, mit dem Argument, dass die fachliche Spezifikation ja vorgelagert erstellt werden muss (nicht wie im Wasserfall für das ganze System aber für jede neue Funktionalität).
2. Die Aufgaben der Architekten werden nun versucht mit einem ähnlichen Argument herauszuziehen. Dabei wird außerdem darauf verwiesen, dass viele der Architektur-Aufgaben ja langläufig sind und nicht in einen Sprint-Rhythmus (von immerhin 3 Wochen) passen, so dass man hier eher nach Kanban arbeiten müsste.
3. Die Aufgaben der Tester die nicht direkt mit den Tickets im Sprint zusammenhängen, werden ebenfalls mit dem Langläufer-Argument in ein separates Kanban-Board gelegt. Hierbei kommt noch die Idee ins Spiel, dies auch nur temporär so zu handhaben, wie ich weiter unten beschreibe.
Zu den einzelnen Punkten ein paar Details und meine erste Einschätzung:
Zu 1.: Diesen Punkt kenne ich teilweise aus anderen (allerdings v.a. größeren) Setups und empfinde es als nicht so dramatisch, solange diese Rollen trotzdem eng mit dem Entwicklungsteam zusammenarbeiten. Ob dann das separate Backlog wirklich Vorteile bringt ist eine andere Sache aber zumindest ist der Nachteil aus meiner Sicht nicht so groß.
Zu 2.: Hier lassen sich relativ viele Argumente dagegen finden (z.B. Insel-Wissen, Fokus, Langläufer runtergebrechen, etc.). Sofern jedoch in einem Team die Architektur relativ stark an einzelnen Personen hängt, man das vielleicht bewusst so behalten möchte und diesen Personen viel Vertrauen entgegen bringt, könnte ich es in gewissem Sinne nachvollziehen, wenn man diesen Personen auch gewisse Freiheiten in einem selbst verwalteten Backlog zugesteht, um sich mit Themen außerhalb des aktuellen Fokus zu beschäftigen. Das ist aber vermutlich mit Vorsicht zu behandeln und im Sprint Planning zu berücksichtigen.
Zu 3.: Das ist für mich der interessanteste Punkt, vor dem Hintergrund, dass in unserem Fall lange an Testautomatisierung gespart wurde. Nun hat man Kapazitäten aufgebaut und die Erstellung und Pflege von automatisierten Testfällen zu aktuellen Tickets wird auch normal in Sprint mit bearbeitet. Parallel dazu wird versucht die fehlende Test-Automatisierung für die bestehenden Funktionalitäten aufzubauen und genau diese Aktivitäten wurden in ein separates Backlog gelegt.
Hier kann ich den Schritt sogar einigermaßen nachvollziehen, da diese Nachholarbeiten aufgrund der immer noch eher knappen Ressourcen, die dafür eingesetzt werden können, eine lange Zeit in Anspruch nehmen und die einzelnen Aufgaben meist tatsächlich nicht in einem Sprint abgeschlossen werden. Es wird also auch bewusst nicht in den Sprint genommen, damit nicht zu viel Kapazität auf einmal darauf verwendet wird, da das Thema weiterhin (leider) keine hohe Priorität hat.
Selbst wenn man diesem Thema aber eine höhere Priorität geben würde und z.B. bestimmte Personen nur darauf ansetzen würde, könnte dieses “Subteam” mit einer festgelegten Kapazität aus meiner Sicht relativ unabhängig vom Rest des Teams daran arbeiten und der Fortschritt dieses “Subteams” hätte keine Auswirkungen auf den Sprint-Erfolg der eigentlichen Weiterentwicklung des Produktes.
Auch wenn das Schneiden des Backlogs nach Disziplinen der Idee eines cross-funktionales Teams zuwiderläuft, würde mich interessieren, ob ihr dies schon häufiger beobachten konntet, ob ihr dem vielleicht auch etwas positives abgewinnen konntet oder wie ihr damit umgegangen seid.
Gerade der Gedanke eines “temporärer Subteams” im 3. Punkt birgt für mich einen gewissen Charme, ein größeres Seitenthema über einen längeren Zeitraum parallel bearbeiten zu können. Das ist aber vielleicht sogar eine ganz andere Frage, ob und in welcher Art (temporäre) Subteams sinnvoll eingesetzt werden können. Eventuell ist das Thema auch interessant genug für euch, um darüber in einer Podcast-Folge ausführlicher zu sprechen. Mir würden sich da spontan viele Fragen stellen (z.B. Wann sinnvoll / Wie lange / Separater PO / Mitglieder zu 100% im Subteam / Prozess zu Etablierung und Auflösung).
Vielleicht habe ich aber auch deswegen keine Folge dazu gefunden, weil das für euch ein absolutes No-Go in einem guten Scrum-Team ist (Stichwort Fokus).
In jedem Fall wäre ich gespannt auf eure Erfahrungen dazu und freue mich auf eure Antworten.
Viele Grüße
Bernhard