Kapitel 2

Der Product Owner

In diesem Kapitel

Die Rolle des Product Owners

Backlog, Stakeholder und Release Management

Arbeiten mit dem Development-Team

Eigenschaften eines Product Owners

Ein Tag im Leben eines Product Owners

In diesem Kapitel beschreiben wir die Rolle des Product Owners, die erste der Rollen in Scrum. Wir erklären seine Aufgaben und beschreiben die Unterschiede zu verschiedenen traditionellen Rollen. Außerdem geben wir einige Hinweise, um einen Product Owner zu finden.

Die Rolle des Product Owners

Die Bezeichnung Product Owner trifft es ziemlich genau. Der Product Owner übernimmt das Eigentum an diesem Produkt und ist verantwortlich für die erfolgreiche Umsetzung: rechtzeitig, im Kostenrahmen und mit zufriedenen Kunden. Alles drei, jawohl. Wenn einer dieser Aspekte fehlt, ist das Produkt nicht erfolgreich.

Scrum lehrt Einfachheit und Transparenz, und die Rolle des Product Owners ist ein gutes Beispiel dafür. Es gibt nämlich nur einen Product Owner und das ist genau eine Person. Auf diese Art weiß jeder, wer die Entscheidungen trifft; die Entscheidungen über die Richtung des Produkts, um genau zu sein.

Darüber hinaus betreut jeder Product Owner nur ein Projekt, und das ist alles, was er tut. Schön klar, mit vollem Commitment, 100 Prozent der Zeit, jede Woche, jeden Monat, bis das Produkt fertig ist. Wahrscheinlich sind Sie die Hälfte der Zeit mit den Stakeholdern beschäftigt und die andere Hälfte mit dem Team. Product Owner ist man 40 Stunden pro Woche, es ist ein Vollzeitjob.

Dieser letzte Punkt ist eher umstritten, und vielleicht sind diese 100 Prozent auch ein bisschen viel. Aber der Arbeitsbereich eines Product Owners ist umfassend. Der Product Owner ist nicht nur mit dem Team beschäftigt, und vielleicht müssen noch mehr Dinge entwickelt werden, nicht nur Software. Sie sind einen großen Teil der Zeit mit den Stakeholdern beschäftigt. Dazu gehören allerlei Aufgaben wie Besprechungen mit Partnern, Abstimmung mit dem Marketing, Anfertigen von Skizzen, um ein genaueres Bild der Zielgruppe zu bekommen, Abstimmung des Etats mit dem Management. Und so weiter. Wenn Sie es so betrachten, sind Sie schnell bei 100 Prozent.

Der Product Owner darf nicht zum Engpass werden. Dann muss ein sehr wertvolles Team warten; es beginnt, mit Annahmen zu arbeiten, und das Produkt wird nicht so gut, wie es sein könnte. Daher ist es wichtig, dass der Product Owner genug Zeit hat, anwesend zu sein, den Weg zu weisen, Menschen für das Produkt zu motivieren und die Vision immer wieder herauszustellen. Das geht nicht so einfach nebenbei.

Der Product Owner ist dafür verantwortlich, alle, die ein Interesse an dem Produkt haben, zu vertreten, die Interessen all dieser Menschen und Parteien abzuwägen und ständig zu entscheiden, was am wichtigsten ist. Ich betone ausdrücklich »ständig«, weil, wie jeder weiß, die Anforderungen und Wünsche der Stakeholder sich immer wieder ändern. Der Product Owner hält diese Wünsche in einer Liste fest, im sogenannten Product Backlog. In den Gesprächen mit interessierten Parteien geht es unter anderem um die Frage: »Was in welcher Reihenfolge?«

Der Product Owner ist außerdem verantwortlich dafür, sich mit dem Development-Team über die Implementation der Anforderungen und Wünsche der Stakeholder auseinanderzusetzen. Das Development-Team hat meist mehrere Möglichkeiten, einen Wunsch zu interpretieren und zu implementieren. Die Kosten können daher recht unterschiedlich ausfallen, und der Product Owner muss verstehen, wie hier Abwägungen getroffen werden. In den Gesprächen mit dem Development-Team geht es unter anderem um die Frage: »Wie mit welchen Kosten?«

Mit diesen beiden Aspekten (was und wie) der Wünsche überlegt der Product Owner, in welcher Reihenfolge die Items realisiert werden. Oft, indem er in mehreren Sitzungen den Stakeholdern die Schätzungen des Development-Teams vorlegt, wodurch »quick wins« nach vorn rücken und manche Wünsche wegen der Kosten unter den Tisch fallen.

Setzen Sie erst Prioritäten, fragen Sie dann nach den Kosten. Kostenschätzungen fressen relativ viel Zeit; deshalb sollten Sie den wichtigsten Dingen mehr Zeit widmen. Es ist Ihre vorrangige Verantwortung, einen Gegenwert für Ihr Geld (Return on Investment, ROI) zu bekommen.

Sie können als Product Owner natürlich auch scheitern; die Entwicklung neuer Produkte ist ein unsicheres Unterfangen. Deshalb verwenden wir schließlich Scrum. Scrum ist nicht der garantierte Weg zum Erfolg, Scrum ist die garantierte Methode, alle Probleme, Chancen und Möglichkeiten so schnell wie möglich ans Tageslicht zu bringen. Dabei können natürlich sehr unangenehme Erkenntnisse auftreten. Das ist keine Schande. Manchmal ist der Business Case nicht wirklich wasserdicht, und Sie kommen recht bald dahinter – ebenfalls keine Schande. Viele erfolgreiche Unternehmen verwenden Scrum sogar, um schnell zu starten und den Business Case zu testen. Wenn es gut geht, haben Sie dabei auch noch Zeit gewonnen. Wenn es nicht gut geht, zum Beispiel, weil Sie nicht rechtzeitig fertig werden, sind Sie sehr wahrscheinlich viel früher als auf traditionellem Weg an den Punkt gekommen, wo Sie stoppen. So gelingt auch das Scheitern mit Scrum viel besser!

Backlog-Management

Es ist die wichtigste Aufgabe des Product Owners, die Items im Product Backlog ständig (neu) zu priorisieren, sodass die wertvollsten Items ganz oben stehen. Das sind die Items mit dem höchsten Wert und den relativ niedrigsten Kosten. Alle Anforderungen und Wünsche im Product Backlog müssen jederzeit vom Product Owner anhand des Geschäftswerts priorisiert und mit einer Schätzung des Arbeitsaufwands durch das Development-Team versehen sein.

Das nennt sich Backlog Refinement oder auch Backlog Grooming. Das Backlog ist ständig in Bewegung, vor allem, weil das Development-Team so oft wertvolle, produktionsreife Software demonstriert und die interessierten Parteien dann meist auf andere, neue Ideen kommen. Aber auch Faktoren wie der Etat, der Markt und die tatsächliche Nutzung von Teilprodukten haben Einfluss.

Sorgen Sie als Product Owner dafür, dass Sie wertvolle Dinge im Product Backlog haben, die alle verstehen. Das Product Backlog ist vor allem ein Kommunikationsmittel.

Das Product Backlog ist für viele Menschen interessant. Es regt zu Fragen und Diskussionen an. Das ist prima. Verstecken Sie das Backlog also nicht in der Schublade oder einer abgelegenen Datei. Hängen Sie es an die Wand, sichtbar für alle, die Fragen haben.

Ein Backlog voller Technosprech wird nicht verstanden und führt oft zu Problemen, zum Beispiel mangelnder Akzeptanz beim Anwender und wenig Gegenwert fürs Geld. Es gibt schon genügend Unternehmen mit unnötig teurer IT-Infrastruktur, die sich als Nachteil für das Unternehmen erweist. Setzen Sie nur für Anwender erkennbare und nützliche Punkte auf die Liste, formuliert in den Worten der Anwender.

Gehen Sie so schnell wie möglich und so oft wie möglich zur Produktion über (also live!). Nichts belegt deutlicher die Richtigkeit Ihrer Entscheidungen (stehen die richtigen Dinge oben?) als die Anwendung der Software durch echte Menschen.

Stakeholder-Management

Es ist zwar keine offizielle Rolle in Scrum, aber die interessierten Parteien werden allgemein »Stakeholder« genannt. Wir behalten diesen Ausdruck bei, er passt so schön zu einem Scrum-Projekt.

Inventarisieren der Stakeholder

Es gibt im Allgemeinen viel mehr Stakeholder, als man auf den ersten Blick annimmt. Ein Interesse an einem Produkt kann nämlich auf unterschiedliche Weise entstehen. Es gibt Menschen und Parteien, die an Ihrem Produkt interessiert sind, zum Beispiel die Abteilungen Vertrieb und Marketing, oder aber Endverbraucher. Andererseits gibt es Menschen und Parteien, die sich zwar nicht für Ihr Produkt interessieren, die Ihnen aber eventuell in die Quere kommen können, zum Beispiel die Softwarearchitekten, die Geschäftsleitung, der Gesetzgeber oder die Konkurrenz.

Versuchen Sie, so früh wie möglich (also bevor es losgeht) und so oft wie möglich, einen Überblick zu bekommen, wer ein Interesse an Ihrem Produkt hat und wer bei der Realisierung des Produkts Einfluss auf dessen Erfolg nehmen kann.

Setzen Sie in jedem Fall zu Beginn der Realisierung ein kurzes Brainstorming mit einigen Stakeholdern und möglichst auch dem Team an, um Ihr Bild aller interessierten Parteien zu vervollständigen.

Sorgen Sie dafür, dass Sie vor allem die Menschen mit großem Interesse, die zudem noch viel Einfluss haben, bevorzugt bedienen.

Vergessen Sie dabei aber nicht, die Menschen mit geringem Interesse und großem Einfluss regelmäßig zu bedienen. Diese Gruppe kann die eine oder andere Überraschung bereithalten. Lassen Sie sich nicht überraschen, sondern kommunizieren Sie offen, zum Beispiel mit der...