Rollentausch - der Product Owner in Scrum

Das agile Vorgehen bei der Entwicklung von Software hat sich inzwischen weltweit bewährt. Scrum ist eine agile Methode, mit der sich, vor allem in der Softwareentwicklung, Entwickler-Teams selbst organisieren. Scrum setzt mit Hilfe von Regeln und Rollen einen Rahmen, innerhalb dessen sich die Menschen, die an der Entwicklung eines Softwareprogramms beteiligt sind, koordinieren.

Ein Satz Spielregeln steht im Mittelpunkt von Scrum. Diese definieren Feedbackschleifen, Sprints genannt, an deren Beginn geplant und an deren Ende das Ergebnis inspiziert wird. Das Scrum-Team trifft sich zu festgelegten Meetings, um den nötigen Austausch zu gewährleisten. Ein Scrum Master sorgt dafür, dass die Regeln beachtet werden.

Aufgaben des Product Owners

Der Product Owner ist der Geschäftsmann im Scrum Team. Er ist dafür verantwortlich, dass das Produkt einen möglichst hohen Geschäftswert erzielt. Das Bereitstellen der Anforderungen geschieht hierzu auf eine ganz eigene Weise. Diese werden in einem sogenannten Product Backlog geführt. Dieser dient als Input für den nächsten Sprint. So definiert der Product Owner, was das erwünschte Ergebnis des nächsten Produkt-Inkrements ist.

Wo bleibt der Projektleiter in einer agilen Produktentwicklung?

Oft wird die Frage gestellt, wo der klassische Projektleiter in einem Scrum-Projekt bleibt. Er fühlt sich meistens in der Rolle des Product Owners wohl, seltener als Scrum Master.

Ein Projektleiter kümmert sich zusätzlich zur Produktentwicklung auch um Budgetfragen. Der Produktmanager kümmert sich um das Produkt. Auch wenn diese Rollen im Unternehmen zusätzlich zu einem Scrum-Umfeld existieren, hat der Product Owner hier die stärkere Position. Projektleiter und Produktmanager sind aus dem Scrum-Blickwinkel Stakeholder (Interessenvertreter).

Zielorientierung

Da die Summe der Aufgaben im Product Backlog mehr ist als seine Teile, gilt es ein Ziel für einen Sprint zu definieren. Wenn wir einem Team die Aufgabe geben, ein Auto zu bauen, mit dem es möglich ist, von Hamburg nach Zürich zu fahren, dann ist das eine andere Mission, als wenn wir dem Team eine To-do-Liste übergeben, in der die Aktivitäten stehen, wie Schrauben anziehen und Motor einsetzen. Das Bild einer gemeinsamen Vision im Kopf aller Beteiligten motiviert, lässt das Team zusammenarbeiten und jeden sein persönliches Wissen einbringen.

Die Vision wird vom Product Owner getragen. Das Backlog ist sein Hilfsmittel zum Vermitteln von Anforderungen und Ideen. Das Entwickler-Team plant Zeit ein, um ihn dabei zu unterstützen. Vor allem sind die Gespräche miteinander von Bedeutung. Die grösste Wissensweitergabe erfolgt bei persönlichen Gesprächen.

In grösseren Unternehmen arbeitet der Product Owner eng mit anderen Interessenvertretern zusammen. Dazu können beispielsweise Marketing, Vertrieb oder Produktmanagement zählen. Auch wenn der Product Owner hier als Vermittler auftritt, hat er das letzte Wort über die Prioritäten im Product Backlog und darüber, was das Team im nächsten Sprint prioritär umsetzen soll. Der Product Owner hält dabei immer den Geschäftswert und den Nutzen eines Features im Blickfeld. So entsteht das Produkt mit dem höchsten Mehrwert für das Unternehmen.

Zusammenarbeit am Product Backlog

Da das Product Backlog dem Team als Quelle für Anforderungen eines Produktes dient, müssen hier unterschiedlichste Interessen unter einen Hut gebracht werden. Es spiegelt sich sowohl die Innovation wieder, die ein Produkt in der Zukunft tragfähig macht, als auch die dringlichen Anforderungen, die das Tagesgeschäft erfordert. Die Wünsche sind meist grösser als die Möglichkeiten. Hier spielen menschliche Randbedingungen eine grosse Rolle. Jeder möchte gehört werden und versucht seine Interessen gut zu vertreten und seinen Einfluss geltend zu machen. Das Ergebnis ist ein mittelfristiger Plan über mehrere Sprints in Form von einem Meilensteinplan oder einem Releaseplan.

Während des Sprints steht der Product Owner seinem Team jederzeit für Rückfragen zur Verfügung.

Qualitätsansprüche

Um sich über die Qualität des Ergebnisses zu einigen, gibt es eine «Definition of Done». Hier ist dokumentiert, welche genauen Merkmale die Software aufweisen muss, um vom Product Owner am Ende des Sprints abgenommen zu werden. Wie gut muss das Produkt getestet sein? Muss es Barrierefreiheit aufweisen? Gibt es Dokumentationsvorschriften? Für die Abnahme gibt es ein eigenes Meeting, das Review, in dem die lauffähige Software oder das funktionstüchtige Produkt inspiziert wird.

Fazit

Der Product Owner hat eine mächtige Position in einem agilen Umfeld wie Scrum. Er braucht deshalb Verhandlungsgeschick und Unterstützung von seinem Management.