Alle Product Owner, die ich in den letzten Jahren kennengelernt habe, hatten eine Sache gemeinsam: Sie waren mehr oder weniger chronisch überlastet. Primäre:r Ansprechpartner:in für Kund:innen sein, Workshops moderieren, an Scrum Events teilnehmen, Produktstrategien entwickeln und implementieren, den Markt im Blick behalten, beim Marketing und Vertrieb des Produktes unterstützen bzw. dies komplett übernehmen… Wenn man so in die Kalender und Todo-Listen von Product Ownern schaut, kann einem schnell schwindelig werden.
Ach ja, und quasi „nebenbei“ will ja noch das Product Backlog gepflegt, priorisiert, detailliert und kommuniziert werden. Dafür ist dann oft keine oder nur noch wenig Zeit übrig – mit den entsprechenden negativen Konsequenzen für die Produktentwicklung.
Damit diese vermieden werden und sich Product Owner das Leben etwas leichter machen können, stelle ich in diesem Blogartikel drei „Lifehacks“ für Product Owner vor (plus eines „Bonus-Hacks“), die sich in der Praxis bewährt haben.
1. Unterstützung organisieren
Lasst uns einmal im Scrum Guide nachschauen, was der eigentlich zu den Aufgaben des Product Owners sagt: „Der:die Product Owner:in kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren.“[i]
„Moment mal – ich darf mir Hilfe organisieren?“ Schon allein diese Erkenntnis kann für viele Product Owner, die es bisher gewohnt waren, alles allein stemmen zu müssen, eine Erleichterung sein. Die Hilfe kann dabei ganz unterschiedlich aussehen. In einigen Teams unterstützen die Entwickler:innen beim Detaillieren von Backlog Items. In anderen Teams gibt es dafür eine dedizierte Rolle, wie zum Beispiel eine:n Business Analyst:in oder Requirements Engineer. Oder Kolleg:innen aus Querschnittsabteilungen, wie zum Beispiel aus einem unternehmensweiten RE-, UX- oder Testing-Team, unterstützen bei Bedarf.
Und auch wie diese Unterstützung dann genau ausgestaltet wird, kann von Team zu Team variieren. Ein Team von mir fährt sehr gut mit wöchentlichen Pre-Refinement-Terminen. In diesen Termin trifft sich der Product Owner mit ein bis zwei Entwickler:innen, um die Backlog Items für das Refinement in der großen Runde vorzubereiten.
In einem anderen Team schickt der Product Owner eine Woche vor dem Team-Refinement eine Liste mit vorbereiteten Stories an die Entwickler:innen, damit diese ihm vorab schon ihre Fragen dazu mitteilen konnten.
2. Kanban-Board fürs Backlog aufsetzen
Manchmal ist aber vielleicht gar nicht ganz klar, welches Backlog Item als nächstes detailliert werden muss, wo noch eine Rückmeldung vom Kunden aussteht oder welche Stories schon mit dem gesamten Team geschätzt werden können.
Hier kommt der nächste Hack ins Spiel: Den gesamten Lebenszyklus der Backlog Items über ein Kanban-Board abzubilden. Im Sprint-Kontext nutzen die meisten nach Scrum oder verwandten Frameworks arbeitenden Teams schon Kanban, um ihr Sprint Backlog damit zu visualisieren.
Für den besseren Überblick über den Gesamtzustand des Backlogs und die Koordination der Arbeit daran kann es hilfreich sein, hierfür ein separates Kanban-Board anzulegen. Während das Sprint Backlog Kanban-Board den Fortschritt auf Ebene der technischen Aufgaben fokussiert, legt das Product Backlog Kanban-Board den primären Augenmerk auf die Stories im Backlog. Die folgende Abbildung zeigt eine beispielhafte Darstellung eines Kanban- Boards für ein Product Backlog.
Mit dem Board sieht man schnell, ob eine ausreichende Anzahl an vorbereiteten Items für den nächsten Sprint zur Verfügung steht und wo es möglicherweise Engpässe gibt. (Hinweis: Für die grafische Darstellung wurde bewusst ein eher einfacher Prozess ausgewählt, um die Darstellung nicht zu überfrachten. Dieser kann natürlich in der Realität weitere Schritte enthalten.)
3. Regelmäßig aufräumen
Hand aufs Herz: Wie haltet ihr es zuhause mit dem Aufräumen? Habt ihr eine regelmäßige Routine oder räumt ihr erst auf, wenn euch die Unordnung wahnsinnig macht (oder sich Besuch ankündigt)?
Wenn ihr nicht naturgemäß zu den eher ordentlichen Personen auf diesem Planeten gehört, kann eine regelmäßige Aufräumroutine beim Ordnung halten helfen. Wie zum Beispiel immer abends vor dem ins Bett gehen aufzuräumen.
Ähnlich könnt ihr es mit dem Product Backlog halten. Denn genau wie eine Wohnung, in der nicht regelmäßig aufgeräumt wird, kann ein Backlog mit der Zeit ziemlich unordentlich werden. In der Realität haben wir meist mehr Ideen für das Produkt, als letztendlich Zeit und Geld zur Verfügung stehen. Und so kommt es dazu, dass mehr Product Backlog Items erfasst als geschlossen werden und das Backlog wächst und wächst… Parallel dazu veralten die Backlog Items und verlieren dadurch an Wert.
Ein erstes Indiz für den Aufräumbedarf eines Backlogs, liefern in Jira die Berichte „Durchschnittliches Alter“, „Erstellte vs. Erledigte Vorgänge“ und „Kürzlich erstellte Vorgänge“.
Um ein eventuell ausuferndes Backlog in den Griff zu bekommen (und zu behalten), kann dann ein wöchentlicher Aufräumtermin helfen. Product Owner können diesen Termin dazu nutzen, die Priorisierung des Backlogs zu überprüfen und bei Bedarf anzupassen und veraltete Product Backlog Items zu schließen.
Gut eignet sich zum Aufräumen häufig der Freitagnachmittag oder eine andere Uhrzeit, zu der erfahrungsgemäß weniger externe Meetings anstehen. Es hilft, sich diesen Termin im Kalender fest einzuplanen. Und es gilt ihn dann auch gegen andere Anfragen zu verteidigen – womit wir auch zu unserem letzten Hack kommen…
4. Bonus-Hack: Nein sagen
.., und zwar dem „Nein“ sagen. Das muss man als Product Owner nämlich ziemlich häufig.
- „Nein“ sagen zu Feature-Wünschen von Stakeholdern,
- „Nein“ sagen zum Chef/der Chefin die nur mal „ganz eben schnell“ etwas erledigt haben wollen,
- „Nein“ sagen zu Terminanfragen, die zu kurzfristig reinkommen oder in Zeiträume fallen, die für andere dringende Arbeiten benötigt werden
- Und zu noch viel mehr.
Oft fühlt sich das „Nein“ sagen für uns nicht besonders gut an, weil es damit verbunden sein kann, die Erwartungen anderer zu enttäuschen. Als soziale Wesen wollen wir genau das am liebsten komplett vermeiden. Viel lieber wollen wir von anderen gemocht werden und sagen deshalb öfter „Ja“, als es für uns selbst und das Produkt gut wäre.
Etwas leichter kann uns das „Nein“ sagen fallen (und das Hören eines „Neins“ ebenfalls), wenn wir eine Erklärung für unser „Nein“ mitliefern. Die Harvard-Psychologin Ellen Langer hat bereits 1977 in dem sogenannten „Kopiererexperiment“ herausgefunden, dass Bitten und Aussagen leichter akzeptiert werden, wenn sie eine Begründung enthalten[ii].
Falls euch das Nein sagen trotzdem noch schwerfällt, kann auch ein Business Coaching hilfreich sein, um mögliche tiefer liegende Muster aufzudecken und aufzulösen.
Fazit
Es gibt verschiedene Möglichkeiten, sich als PO das Leben leichter zu machen. Einige davon, habe ich euch in diesem Artikel vorgestellt:
- sich Unterstützung zu organisieren,
- ein Kanban Board für das Product Backlog zu nutzen und
- eine Aufräumroutine einzuführen.
Außerdem ging es noch darum, wie wichtig es für eine:n Product Owner ist, gut „Nein“ sagen zu können.
Falls ihr euch noch mehr Hacks und Impulse wünscht, schreibt mir gern oder fragt direkt einen Gesprächstermin an. Ich freue mich, von euch zu hören!
[i] https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf
[ii] https://karrierebibel.de/begruendungseffekt/
Schreibe einen Kommentar