Roadmaps sind nicht agil!
Product Ownerin bei einem früheren Kunden
Ich arbeite agil. Trotzdem habe ich eine Roadmap. Wie passt das zusammen?
Das und meine drei Schritte zum beherrschbaren Backlog erfährst du in diesem Artikel.
Warum ich als Product Owner arbeite?
Ich habe viele Jahre als Scrum Master, Agile Coach, Kanban Lead und DevOps Experte bei meinen Kunden gearbeitet. Vor allem als Scrum Master und Agile Coach hatte ich immer wieder die Herausforderung, dass ich meine Product Owner coachen musste. Warum?
Sie waren fachlich meistens gut aufgestellt. Methodisch hatten sie aber in der Regel ein paar Schwächen. Ich gab den Product Ownern die gleichen Ratschläge, die man in den einschlägigen Blogartikeln und Podcasts bekommt.
Aber irgendwie fühlte sich das aber nicht richtig an. Ich stand vor einer Entscheidung: Mache ich weiter wie bisher? Oder soll ich mir mal die Seite des Product Owners anschauen?
Das Experiment: Mein Leben als PO
Im November 2021 war es so weit. Ich startete bei einem Kunden als Product Owner. Und stellte fest: Das Leben auf der anderen Seite sieht irgendwie anders aus als vermutet…
Plötzlich war ich mit diversen Problemen konfrontiert. Im Backlog vergammelten die Stories. Da es ein produktives Produkt war, kamen diverse Fehlermeldungen und Support Anfragen rein. Die Priorisierung änderte sich gefühlt stündlich. Wir waren total fremdgesteuert. Außerdem hatten wir einen ziemlich krassen Bus-Faktor. Das Team war ständig blockiert. Was also tun?
In diesem Artikel gehe erfährst du, wie ich das Backlog in den Griff bekommen habe.
Schritt 1: Backlog Tabula-Rasa
Das Erste, was ich tat, war ein Backlog Tabula-Rasa. Was ist das? User Stories und Bugs altern in der Regel schlecht. Eine passende Metapher:
User Stories faulen wie Obst, wenn sie zu lange herumliegen.
Beim Backlog Tabula-Rasa habe ich folgendes Vorgehen für mich entwickelt:
- Ich gehe durch jede User Story. Dabei stelle ich mir folgende Fragen:
- Ist diese Story noch aktuell?
- Liefert diese Story den gewünschten Mehrwert? Welchen Bedarf erfüllt sie?
- Kann das Team sie realistisch in den nächsten 3 Sprints angehen?
- Wenn die Story noch aktuell ist und den gewünschten Mehrwert liefert, dann priorisiere ich sie.
- Wenn die Story nicht mehr aktuell ist, der Mehrwert fraglich ist oder die Story nicht realistisch in den nächsten drei Sprints angegangen werden kann, dann notiere ich mir die Idee der Story und lösche sie (bzw. lehne sie ab, je nach Workflow). Die Idee wird im nächsten Schritt eingeplant
Das ist alles. Danach habe ich ein Backlog, das ich beherrschen kann.
Schritt 2: Roadmap erstellen
Es gibt Themen, die wichtig sind, aber nicht jetzt angegangen werden können. Wie kannst du diese Themen organisieren, ohne dich mit zu vielen Stories zu verzetteln? Und wie kannst du deinen Stakeholdern eine Sicht darauf geben, was sie erwarten können?
Für mich hat sich folgende, einfache Roadmap bewährt:
| Now | Next | Later |
|---|---|---|
| Thema 1.1 | Thema 1.2 | Thema 5 |
| Thema 2.1 | Thema 3 | Thema 2.2 |
| Thema 4 |
Ein wichtiges Detail: In der Roadmap stehen keine Stories, keine Epics oder sonstige „Strukturierungselemente“. Das Einzige, was darin steht sind Themen. Warum?
Der Zweck dieser Roadmap ist es, dass die Themen nicht untergehen und dass allen klar ist, wann an welchem Thema gearbeitet wird. Sie soll mir Arbeit abnehmen, nicht weitere Organisationsarbeit schaffen. Wenn ich die Themen grob strukturiere und weiß, welche Stories auf welche Themen einzahlen, dann reicht mir das. Ein Kollege hat das gleiche Prinzip angewendet, allerdings beinhalteten die Themen in der Roadmap dann auch Links auf Themenseiten, die dann wiederum Stories und Epics referenzierten. Wenn du diese Form der Roadmap nutzen möchtest, kannst du sie beliebig an deine Bedürfnisse anpassen.
Mit dieser Roadmap habe ich drei Probleme gelöst:
- Die Themen sind notiert und werden nicht vergessen.
- Die Stakeholder wissen immer, wann ihre Themen dran sind.
- Das Backlog ist überschaubar und leicht zu priorisieren.
Schritt 3: Zufluss an neuen Stories steuern
Damit ich nicht wieder in die „Vergammelte-Stories-Falle“ stolpere, nutze ich ein Upstream-Kanban-Board für das Refinement der Stories. Wie sieht das aus?
Ich habe ein zweites Board mit drei Spalten:
| Ideen (20) | Im Refinement (5) | Backlog (30) |
|---|---|---|
Ideen: Hier werden alle aktuell vermutlich relevanten Ideen erfasst, die eventuell demnächst interessant werden.
Im Refinement: Wenn Nachschub fürs Backlog benötigt wird oder dringende Themen reinkommen, gehen die in die Spalte Refinement. Alle Stories in dieser Spalte werden, wie der Name schon sagt, refined.
Backlog: Diese Spalte stellt den Übergang zum Sprint-Backlog dar. Alle Stories, die in diesem Board im Backlog liegen, liegen damit im Product-Backlog und ich kann sie in einen der nächsten Sprints einplanen.
Und jetzt kommt die Magie: Jede dieser Spalten hat ein WIP-Limit. Auch Idee und Backlog! Dieses WIP-Limits passe ich sukzessive an. So schaffe ich eine Zufluss-Steuerung, die es mir ermöglicht, nicht wieder in die Backlog-Hölle zurückzufallen und mir die Arbeit für die Tonne einzusparen.
Fazit
Ja, ich mache Kanban im Scrum-Kontext. Ich habe gelernt, dass das Flow-Mindset von Kanban für jeden Product Owner ein notwendiger Skill ist. Damit schaffst du den Schritt von einem verzettelten, herumpriorisierenden Product Owner hin zu einem souveränen und strukturierten Product Owner, der schnell auf Veränderungen reagieren kann. Und: Du wirst viel Zeit sparen, weil du viel weniger für die Tonne arbeitest.
Mein Angebot für dich
Hast du keine Lust mehr darauf, dich zu verzetteln und für die Tonne zu arbeiten? Dann ist mein Kanban-Workshop genau das richtige für dich! In dem Kanban-Workshop erlebst du Kanban live.
Du wirst Kanban so lernen, wie es eigentlich gedacht ist:
Kein stumpfes Zettel-Geschiebe. Stattdessen beherrschst du den Arbeitsfluss und gibst deinem Team genau das, was sie brauchen: Strukturierte und gut vorbereitete User Stories.
Melde dich heute bei meinen Partnern von der Agile Academy zu meinem nächsten Kanban Live-Workshop an:
Hinweis: Keine Angst, der Workshop ist auch für agile Coaches, aber nicht nur.