In Scrum ist der Product Owner dafür verantwortlich, den höchsten Kundennutzen zu erzeugen. Er ist leidenschaftlicher “Owner” seines Produkts, vertritt und vermittelt seine Vision. Verantwortlich für den höchsten Kundennutzen muss er immer wieder überprüfen, wie erfolgreich sein Produkt bei seinen Kunden ankommt.
Neben seiner Hauptaufgabe, mit Kunden, Stakeholdern und seinem Team zu kommunizieren, organisiert er seine Arbeit in einem Backlog. Das Backlog ist eine Liste von Wünschen, Ideen und Wetten auf ein kontinuierlich verbessertes Produkt. Dabei ist es ganz natürlich, dass die Menge der Wünsche, Ideen und Wetten viel mehr sind, als die Entwicklerteams umsetzen können. Es entsteht also eine lange Schlange von Wünschen, die der Product Owner priorisiert unter Berücksichtigung seiner Vision vom Produkt und dem zu erwartenden Kundennutzen.
Hierbei hilft ihm zu überlegen, welche Themen den höchsten Nutzen haben und dabei den kleinsten Umsetzungsaufwand haben (WSJF – weighted shortest job first), denn um möglichst viel zu erreichen hilft es, mit jedem Thema möglichst wenig Aufwand zu haben. Aber auch wenn jede Umsetzung so klein wie möglich ausgestaltet wird, wird die Schlange der Wünsche, Ideen und Wetten auf ein besseres Produkt immer länger. Nach kürzester Zeit entsteht so eine Liste, die Aufgaben für 6-24 Monate beinhaltet. Diese Liste abzuarbeiten hat mit agiler Arbeitsweise und der Möglichkeit, schnell auf Veränderungen und neue Erkenntnisse zu reagieren, nichts mehr zu tun. Die Liste aufzubauen und damit einen langen Plan zu machen in dem Unwissen, ob der Plan so Bestand haben wird, ist unnötige und damit verschwendete Arbeit.
Was kann also ein Product Owner machen, um sich ein hohes Maß an Agilität zu bewahren, um schnell auf neue Erkenntnisse reagieren zu können und nur die notwendigen Pläne zu erstellen? Es ist ebenso einfach wie schwer: Er muss lernen “Nein” zu sagen. Er muss die Freiheit und Fähigkeit haben, auch gute Ideen auch von wichtigen Stakeholdern oder eigene Wünsche abzulehnen, ohne sie dabei auf die lange Bank zu schieben. Natürlich kann das freundlich passieren, aber es muss ebenso deutlich sein.
Entscheidungen raus zu schieben, Stakeholder zu beschwichtigen mit Aussagen wie “Die Idee ist gut, aktuell haben wir keine Zeit, wir machen das später” ist einfacher, aber nicht hilfreich. Eine solche Aussage ist weder ehrlich, noch sorgt sie für Transparenz. Ob ein auf “irgendwann in sechs Monaten” geschobener Wunsch wirklich in sechs Monaten umgesetzt wird, das hängt von den neuen Ideen ab, die bis dahin in das Backlog eingeflossen sind. Insofern kann und sollte in einem agilen Umfeld eine solche Zusagen nicht gemacht werden.
Product Owner müssen “Nein” sagen zu Themen, die nicht innerhalb der nächsten Wochen und wenigen Monaten umgesetzt werden, auch damit ein “Ja” das richtige Gewicht bekommt. Dabei ist es gleichzeitig wichtig, einen groben Plan und die eigene Vision immer vor Augen zu haben. Das hilft zum Beispiel Stakeholdern, statt zu warten andere Lösungen für ihr Problem zu suchen, mit denen sie ihr Ziel erreichen. Themen, die heute nicht wichtig genug sind, sind wahrscheinlich morgen auch nicht wichtig genug und wenn sie irgendwann wichtig genug werden, werden sie zu dem Zeitpunkt innerhalb weniger Wochen eingeplant und umgesetzt.
(Das verwendete Bild ist von Abi Ryan – vielen Dank!)
11 Comments
Leave a CommentSchönes Zitat dazu von Esther Derby @estherderby
“If you can’t say No, your Yes doesn’t mean much.”
Ich finde es sogar außerordentlich wichtig, dass man in der Rolle des POs auch die Macht hat zu sagen “dieses Feature braucht das Produkt nicht”. Als PO sollte man dieses Recht einfordern – sonst stellt sich doch relativ ketzerisch die Frage: Wenn man sowieso alles macht, was jemand anders (in dem Fall die Stakeholder) will, warum braucht man dann noch einen PO?
Der PO kennt die Produktvision und weiß – im Idealfall – am besten, was das Produkt braucht und wo die Reise hingeht.
Manchmal muss auch ein Stakeholder oder eine Gruppe von Menschen akzeptieren, dass eventuelle Extrawüste einer Altsoftware nicht in eine Software übernommen werden. Weil es noch mehr Menschen gibt, die diese Extrawurst nicht brauchen. Und weil es meistens besser ist, ein Produkt schlank zu halten und nicht mit vielen kleinen Extra-Features für eine kleine Personengruppe zu überladen.
Bei der Priorisierung von User Stories nutze ich ganz gerne das MuSCoW-Schema: Must, Should, Could und Won’t. Die Won’t-Liste ist, genau wie die Must-Liste eine Liste, die nachträglich auch nicht mehr neu diskutiert wird. Wenn das Feature nochmal gewünscht wird (solche Spezialisten gibt es auch) wird das Ticket dazu mit Verweis auf die Entscheidung geschlossen. Ist das Produkt fertig und alle arbeiten damit, dann ist Zeit um die bisherigen Entscheidungen noch einmal anzuschauen und abzuwägen, ob man eventuell doch noch etwas dazu baut. Erstmal plädiere ich aber für “weniger ist mehr” – damit hat man in der Regel mehr als genug zu tun.
Und auch bei einer kontinuierlichen Weiterentwicklung stellt sich die Frage: Bedeutet Weiterentwicklung, dass immer neue Features dazu kommen oder könnte es nicht auch eine Entwicklung zu sein, einzelne Features zu verschlanken oder Dinge, die nicht genutzt werden, zu deaktivieren um zu schauen, ob es jemand vermisst?
Detlef
Vielen Dank für deinen Beitrag. Grundsätzliche stimme ich dir zu, dennoch beschreibst du in den ersten drei Absätzen aus meiner Sicht eine Idealwelt, die zumindest ich bisher so nicht erlebt habe. Anders gesagt: so sollte es sein, ist es aber nicht 😉
Einen schönen Artikel zum Thema “viele Wünsche” auf “immer zu wenig Umsetzungszeit” (auch im Sinne von beschränkte Kapazitäten in der Entwicklung) hat Rick Mironov geschrieben: Four Laws Of Software Economics (Part 1)
Danke für den Beitrag und das wichtige Thema!
Mir hilft folgender Gedanke:
“Backlog Items sind ein Versprechen, über diese Dinge mit den Stakeholdern zu sprechen.”
Im praktischen Umgang mag folgende Unterscheidung helfen:
– JA: das Backlog enthält diejenigen Items, über die man (vor Projektende oder innerhalb von xy Wochen/Monaten) sprechen wird (je ferner, desto Epic)
– VIELLEICHT: eine andere Liste enthält diejenigen Items, die man als Wünsche/Ideen registriert hat, aber über die man zeitnah wohl nicht sprechen wird
– NEIN: diejenigen Items, bei denen der PO (begründet) dagegen entschieden hat
Damit ist für Stakeholder transparent, ob sie ein Ja, Nein oder Vielleicht erhalten haben. Und den PO ermutigt es, hier eine klare Entscheidung zu treffen.
Je nach technischer Umsetzung sind es drei Listen oder eben Filter auf dieselbe Liste. Das offizielle Product Backlog repräsentiert aber nur den ersten Teil.
Hallo Christian. Das finde ich eine gute Idee für den operativen Umgang mit der Herausforderung, vor der Product Owner stehen. Auch hierbei ist es wichtig aus meiner Sicht, die Liste “Vielleicht” klein zu halten und in den einzelnen “Vielleicht-Punkten” zu erwähnen, was eintreten muss, damit “Vielleicht” zu “Ja” wird oder wann aus “Vielleicht” ein “Nein” wird.
Anregender Artikel, danke. Aus meiner Sicht liegt ein Teil der Verantwortung für das unproduktive Backlog-Wachstum auch bei den Stakeholdern, die das Backlog gerne zum “Abkippen” von Ideen missbrauchen. Ein PO kann auch nur so gut sein, wie es die Stakeholder zulassen und dafür ihre eigenen Hausaufgaben auch erledigen. Sonst besteht die Gefahr, dass der PO wirklich gute Ideen übersieht.
Vielen Dank, Uwe, für den guten Input. Der Product Owner ist zum Glück nicht nur Owner des Product Backlogs, sondern auch verantwortlich für das Stakeholder-Management. Je besser die Stakeholder mitspielen, um so einfacher wird es für den Product Owner (um so einfacher wird es auch, “nein” zu sagen) und um so besser ist es für das Produkt.
Dass ein Product Owner zwar nur so gut sein kann, wie es die Stakeholder zulassen, würde ich so nicht formulieren, weil es mir den PO zu sehr in eine passive Rolle drängt. Diese Stakeholder zu managen, ist eine wichtige Aufgabe, die abhängig von Unternehmensstrukturen manchmal vielleicht sogar kaum möglich ist – das ist für mich aber ein anderes, oft strukturelles Problem oder hängt schlichtweg damit zusammen, dass Verantwortung nicht vollumfänglich übergeben wird.
Hey Daniel,
interessanter Bericht 🙂 Das Bild spiegelt vor allem gut das Gefühl wieder, welches ich als PO fortlaufend habe. Was mich zu den Fragen bringt: Wie nehmen meine Stakeholder mein Ja/Nein wahr? Bringe ich mein Nein überhaupt verständlich rüber? Wie erziele ich darüberhinaus auch Einverständnis beim Stakeholder für das ungeliebte Nein? Wie vermeide ich, dass mein Stakeholder trotz der vielen Neins nicht völlig frustriert endet und die Weiterentwicklung schließlich aufgibt?
LG Chantal
Hallo Chantal. Zu den guten Fragen versuche ich ein paar Antworten zu finden – spontane Ideen:
Wie nehmen meine Stakeholder mein Ja/Nein wahr?
Bringe ich mein Nein überhaupt verständlich rüber?
Das hängt sicherlich von den eigenen Argumenten und dem jeweiligen Stakeholder ab. Die Art der Formulierung bzw. ein Verständnis für die Argumente hilft auch. Meiner Erfahrung nach ist es gut, für umfangreichere Entscheidungen möglichst alle Stakeholder gemeinsam (z.B. in einer Etappenplanung) an einen Tisch zu bekommen, damit sie die Vielschichtigkeit der Themen kennenlernen und ein besseres Verständnis für die Gesamtsituation bekommen.
Wie erziele ich darüberhinaus auch Einverständnis beim Stakeholder für das ungeliebte Nein?
Ein Verständnis oder gar ein Einverständnis würde es natürlich leichter machen. Du brauchst aber kein Einverständnis, weil du als PO über dein Produkt entscheidest. Und wenn der Stakeholder mehr Entscheidungskompetenz haben sollte, dann könnte/müsste er diese Macht ausspielen und dann schlägt ober unter, unabhängig von den unterschiedlichen Meinungen.
Wie vermeide ich, dass mein Stakeholder trotz der vielen Neins nicht völlig frustriert endet und die Weiterentwicklung schließlich aufgibt?
Wenn die Ideen des Stakeholders kein Gehör finden und vom Entscheider (PO) immer wieder als weniger wichtig erachtet werden, wird die frustrierte Aufgabe für das Produkt erst mal keine negative Auswirkung haben. Dieses Problem liegt dann beim Stakeholder und nicht bei dir. Dein Fokus als PO ist der Erfolg des Produkts, nicht die Zufriedenheit von einem Stakeholder. Und wenn die Zufriedenheit eines Stakeholders relevant für den Erfolg des Produkts ist, dann wird der PO die Themen des Stakeholders entsprechend priorisieren.