Product-Owner müssen gut „Nein sagen“ können und klare Aussagen treffen.

Klare Aussagen treffen und „Nein-Sagen“ können das sind zwei Hauptanforderungen die ein gute Product-Owner können sollte. Leider passiert in der Praxis oft das Gegenteil und Product-Owner lassen sich von der Innovationskraft des Teams mitreißen, von Stakeholder steuern und planen Feature nach Feature oder verschleiern oder verschweigen Projektfortschritte oder planen diese nicht richtig. Doch warum ist es so wichtig Nein sagen zu können? Dieser Artikel beschäftigt sich mit diesem Thema und mit dem Product-Backlog und seinem Auf- und Abbau.

Nein sagen

Scrum begeistert all jene, die aus der Wasserfallmethodik kommen und zum ersten Mal erleben, wie schnell es möglich ist brauchbare Ergebnisse zu liefern. Bereits nach dem ersten oder zweiten Sprint sind vorzeigbare Ergebnisse greifbar und können erprobt und getestet werden. Das Team setzt einige Stories um und Stakeholder und Product-Owner freuen sich über den Fortschritt. Nach kurzer Zeit und den ersten Präsentationen lassen sich dann oft Stakeholder, User, und Product-Owner von der agilen Welt verführen. Die Möglichkeit Produktinkremente regelmäßig zu testen und „anzugreifen“, bringt alle beteiligten dazu ihre Phantasie laufen zu lassen und „ein Wünsch dir was“ zu spielen.  Das mag kurzfristig ein sehr positives Gefühl sein, kann aber mittel und langfristig zu einem Problem führen. Wenn das Team jeden Sprint nur vier mittlere Stories schafft, sich die beteiligten Stakeholder und der Product-Owner aber jeden Sprint 10 neue Stories ausdenken und im Backlog aufnehmen, so baut sich schnell ein großer Stapel an geplanten Stories auf. So entsteht ein Backlog der Monate oder sogar Jahre zurück reicht.

Die Frage hier ist:

  • Wie agil ist das dann noch?

Der Product-Owner muss „Nein sagen“ können. Er muss abwägen zwischen jenen Ideen und Features der Stakeholder die Wertvoll und Notwendig sind, und jenen die als Veredelung gesehen werden können. Er muss zu unwichtigen Features „Nein sagen“ und wichtige ins Product-Backlog aufnehmen. Genau hier ist aber auch die Schwierigkeit. Herauszufinden welche Features wirklich sinnvoll und wertvoll sind und welche nicht ist eine große Herausforderung die der Product-Owner alleine nicht schafft. Der Product-Owner kann nur durch Kommunikation und durch Befragungen der Stakeholder, des Teams und der User, den Bau von Prototypen und das Durchführen von Akzeptanztests die Aufgabe bewältigen. Dazu braucht es Zeit und es muss viel Energie investieren. Um den Wert und die Größe von Stories einzuschätzen geht Kommunikation über alles. In gemeinsamen Meetings werden Schätzungen vom Team und von Stakeholder gemacht. Dabei wird nicht absolut geschätzt, sondern immer in Relation. Man muss nicht wissen wieviel ein Stück Torte im Vergleich zu einem Obstkorb wiegt. Man muss nur abschätzen und sagen: „Der Obstkorb wiegt circa 10mal so viel wie das Stück Torte, und die Torte schmeckt mir obendrein noch besser, also esse ich als nächstes das Tortenstück.

Schreitet der Product-Owner nicht ein und baut sich ein zu großes Backlog auf, so kann es passieren, dass das Team unter Druck gerät. Wenn es jetzt den Fehler macht und mehr Stories anfängt als es eigentlich abarbeiten kann, so kommt es zu Multitasking, Überforderung, Demotivation und letzten Endes zu schlechterer Produktqualität, weniger fertigen Stories und steigenden Projektrisiken. Eine Situation in der es keine Gewinner und viele Verlierer gibt. Damit dies nicht passiert muss der Product-Owner „Nein sagen“ und das Backlog schön kompakt halten.  Der Scrum-Master und das Team müssen den Prozess, die Kapazität und ihre Arbeit im Auge behalten und ihre Grenzen kennen, wahrnehmen und kommunizieren. Seine Velocity und sein WIP-Limit (Work in Progress – Limit) nicht zu kennen und mehr Stories pro Sprint zu bearbeiten ist sonst so als wenn man mehr Kaffeebohnen in die Maschine kippt um schneller mehr Kaffeetassen zu bekommen, oder den Anfang, die Mitte und das Ende eines Films gleichzeitig auf einen Monitor zu schauen um schneller den ganzen Film gesehen zu haben. Das funktioniert einfach nicht.

Klare Aussagen treffen

Stories sind oft in verschiedenen Größen im Backlog vorhanden. Um oft und früh auszuliefern müssen Stories aber immer in kleinen mundgerechten Happen beim Team im Sprint eingeplant werden. Sonst entsteht wieder relativ schnell eine Überforderung im Team mit Multitasking, Erfolgsdruck und Demotivation. Man kann auch nicht eine Torte mit einem Bissen essen, auch wenn sie noch so gut schmeckt. Der Product-Owner muss dafür sorgen, dass User Stories klein und aussagekräftig sind. Einige Tage groß und für alle Verständlich können Sie dann in Sprints eingeplant werden. Diese Zerlegung und Spezifikation geschieht Just in Time. Dadurch profitiert der Product-Owner und das Team von dem aufgebauten Wissen, den neuesten Erkenntnissen von dem Produkt und der aktuellen Kommunikation über die Bedürfnisse der User. Diese Just-In-Time Zerlegung passiert ständig beispielsweise jede Woche Donnerstag in einem eigenen Meeting dem Refinement Meeting gemeinsam mit dem Team, dem Product-Owner und ggf. Stakeholdern Scrum-Master User.

Der Product-Owner muss aber nicht nur für klare Spezifikationen sorgen. Er muss auch die Erwartungshaltungen der Beteiligten managen und für klare Erwartungshaltungen sorgen. Wenn also Fragen von Stakeholdern entstehen, so muss der Product-Owner klare Aussagen treffen können und diese Fragen klar beantworten können. Eine dieser Fragen könnte sein, bis wann mit einer gewissen Funktionalität gerechnet werden kann. Die Antwort auf diese Frage ist gar nicht so schwer, wenn einige Parameter bekannt sind und konstant gehalten werden.

Einer der wichtigsten dieser Parameter ist die Velocity.

Die Velocity ist wie oben bereits erwähnt schon alleine wegen dem WIP-Limit und der Teamzufriedenheit relevant. Wenn sie konstant und bekannt ist und die Stories in Form eines BurnUp-Graphen vorhanden sind, können mit ihrer Hilfe aber auch sehr gute Vorhersagen und Aussagen gemacht werden.

Wichtig dabei ist, dass der Product-Owner einerseits die Parameter konstant hält. Schätzungen und Velocity müssen über lange Zeit konstant, und plausibel sein. Der Product-Owner darf sich nicht dazu hinreißen lassen aus dem Bauch heraus Zusagen zu machen, da dies nur unnötig Druck auf das Team ausübt und wiederum in schlechter Qualität und Unzufriedenheit gipfelt. Es müssen BurnUp-Graphen gepflegt werden um auf etwaige Fragen der Stakeholder kompetent antworten zu können.

Beispiele Velocity und BurnUp-Graphen

Umfang fix – Zeit variabel Frage

Typ Umfang fix – Zeit variabel Frage
Beispielfrage: Bis wann werden alle diese Features fertig sein?
Antwort
Product-Owner:
Höchstwahrscheinlich zwischen März und Juni nächsten Jahres.
Umgang mit BurnUp-Graphen in Scrum. Hilfestellung für Product-Owner bei Umfang fix und Zeit variabel Fragen um Vorhersagen machen zu können wann, in welchem Zeitraum etwas fertig wird.
Umgang mit BurnUp-Graphen in Scrum. Hilfestellung für Product-Owner bei Umfang fix und Zeit variabel Fragen um Vorhersagen machen zu können wann, in welchem Zeitraum etwas fertig wird.

Umfang variabel– Zeit fix Frage

Typ Umfang variabel– Zeit fix Frage
Beispielfrage: Was können wir bis Weihnachten liefern
Antwort
Product-Owner:
Alle grünen fix, einige von den blauen und keine von den roten.
Umgang mit BurnUp-Graphen in Scrum. Hilfestellung für Product-Owner bei Umfang variabel und Zeit fix Fragen um Vorhersagen machen zu können wie viele Features ab einen gewissen Zeitpunkt fertiggestellt werden können und wie viele teilweise oder gar nicht fertig werden können.
Umgang mit BurnUp-Graphen in Scrum. Hilfestellung für Product-Owner bei Umfang variabel und Zeit fix Fragen um Vorhersagen machen zu können wie viele Features ab einen gewissen Zeitpunkt fertiggestellt werden können und wie viele teilweise oder gar nicht fertig werden können.

Umfang fix– Zeit fix Frage

Typ Umfang fix– Zeit fix Frage
Beispielfrage: Was können wir diese Features bis Weihnachten liefern
Antwort
Product-Owner:
Das geht sich leider nicht aus. Wir können diese Features bis Weihnachten schaffen und wir brauchen dann noch 2 Monate länger um den Rest zu schaffen.
Umgang mit BurnUp-Graphen in Scrum. Hilfestellung für Product-Owner bei Umfang fix und Zeit fix Fragen um Vorhersagen machen zu können wann, in welchem Zeitraum etwas fertig wird. Ob sich die Implementierung zu einen gewissen Zeitpunkt ausgeht, und wenn nicht, wieviel Zeit zusätzlich voraussichtlich benötigt wird.
Umgang mit BurnUp-Graphen in Scrum. Hilfestellung für Product-Owner bei Umfang fix und Zeit fix Fragen um Vorhersagen machen zu können wann, in welchem Zeitraum etwas fertig wird. Ob sich die Implementierung zu einen gewissen Zeitpunkt ausgeht, und wenn nicht, wieviel Zeit zusätzlich voraussichtlich benötigt wird.

Dieser Artikel gehört zur Artikelreihe Tipps für Product-Owner

Tipps für Product-Owner

Buchempfehlungen:

 

Mehr zum Thema Digitalisierung

https://www.facebook.com/Digitalisierung Täglich zwischen 20 und 100 Beiträge aus über 200 verschiedenen Fachquellen

https://www.facebook.com/DerDigitalisierungsCoach/ Der DigitalisierungsCoach auf Facebook, Infos, Termine und mehr.

Zum Autor:

David Theil aus Linz Oberösterreich ist Digitalisierungs-Coach, Software-Entwickler und als Head of Software-Development für über 30 Softwareentwickler verantwortlich. Beruflich beschäftigt er sich bereits jahrelang mit der Digitalisierung und hat bereits bei vielen Digitalisierungs-Projekten in der Wirtschaft federführend mitgewirkt. Er bewegt sich in Themen wie Digitalisierung, IoT, oder Industrie 4.0 sowohl beratend als auch praktisch mit echten Lösungen.

https://medium.com/@david.theil

https://www.xing.com/profile/David_Theil

https://www.linkedin.com/in/david-theil-1a4190148/

https://www.linkedin.com/groups/8678887

https://twitter.com/DavidTheil

Ein Kommentar zu „Product-Owner müssen gut „Nein sagen“ können und klare Aussagen treffen.

Gib deinen ab

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: