Wer sich dafür entscheidet agil zu arbeiten, steht vor der Herausforderung die passenden Strukturen für die reibungslose Zusammenarbeit aller Teammitglieder zu schaffen. Hier kommen agile Frameworks wie Scrum oder Kanban zum Einsatz, die je nach Aufgabenkontext mal mehr und mal weniger stringent verfolgt werden. In der Praxis bietet sich häufig eine Kombination aus beidem an.
Während Kanban grundlegend auf dem Konzept von Boards basiert, auf denen einzelne Aufgaben und deren aktueller Bearbeitungsstand in Spalten abgebildet werden (z.B. als To Do – In Progress – Done) steckt hinter dem Scrum-Framework ein iterativer Ansatz, der sich insbesondere durch das Durchlaufen wiederkehrender Zyklen (Sprints) auszeichnet. Hierbei nehmen die beteiligten Team-Mitglieder unterschiedliche Rollen ein. Eine wesentliche Funktion im Scrum-Prozess fällt dem Product Owner zu, der die fachlichen Anforderungen des (externen) Auftraggebers gegenüber dem Scrum-Team vertritt und für die Priorisierung der einzelnen Aufgaben zuständig ist.
Welche Bedeutung hat die Product Roadmap im Rahmen der Produktentwicklung?
Die Product Roadmap beschreibt einen zeitlichen Rahmenplan, der die Strategie und Vision hinter einem Produkt und seine Entwicklung dorthin zeigt. Dabei fließen sowohl kurzfristige als auch langfristige Ziele ein. Die Product Roadmap bildet also ab, welche Schritte wann erfolgen, um die Produkt-Vision zur Realität werden zu lassen.
Auf der einen Seite dient sie damit als visualisierter Weg der Produktentwicklung für Kunden und Stakeholder. So ist jederzeit nachvollziehbar, welche Features und Meilensteine wann zu erwarten sind und ob das Projekt konsequent in die richtige Richtung läuft.
Auf der anderen Seite ist die Product Roadmap ein klarer Fahrplan für die an der Entwicklung beteiligten Teams, auf dem nicht nur die angestrebten Ziele, sondern auch die Zuständigkeiten für deren Erfüllung abgebildet werden.
Insbesondere in kleineren Unternehmen fällt der Aufbau einer Product Roadmap oft in den Aufgabenbereich des Product Owners. Aber auch in größeren Strukturen ist der Rat des Product Owners bei der Erstellung gefragt. Schlussendlich dient die Roadmap als Grundlage für das Aufgaben-Backlog. Aus ihr werden User Stories abgeleitet, die wiederum in Form von konkreten Anforderungen (Items) ins Backlog aufgenommen werden.
Kann ein Product Owner gleichzeitig Scrum Master eines Teams sein?
Nein. Diese beiden Rollen verfolgen unterschiedliche Ziele die z.T. in Konflikt zueinander stehen können. Daher sollte ein Product Owner niemals gleichzeitig die Position des Scrum Masters einnehmen.
Während es die Aufgabe des Product Owners ist, pro Sprint ein Maximum an Entwicklungsfortschritt im Sinne des Auftraggebers bzw. Produkts zu erzielen, liegt die Verantwortung des Scrum Masters darin, ein möglichst störungsfreies Arbeitsumfeld für das Entwicklerteam sicherzustellen. Der Scrum Master ist also in erster Linie dafür zuständig, das Team organisatorisch im Entwicklungsprozess zu unterstützen, vor ungeplanten Anforderungen von außen zu schützen und bei der Beseitigung von Hindernissen (Impediments) zu helfen.
Im Gegensatz dazu besteht die Hauptaufgabe des Product Owners darin, die Interessen von Kunden oder Stakeholdern zu vertreten und deren Anforderungen an das Produkt möglichst schnell und effizient durch das Scrum-Team umsetzen zu lassen. Dazu organisiert und priorisiert der Product Owner die bestehenden Anforderungen (Items) in einem Product Backlog.
Wie priorisieren Sie das Product Backlog sinnvoll?
Die Betreuung des Product Backlogs ist ein wesentlicher Verantwortungsbereich des Product Owners, da es die Gesamtheit aller projektbezogenen Anforderungen enthält. Es wird laufend gepflegt und bei Bedarf um neue Items ergänzt. Der Product Owner ist außerdem für die Priorisierung der einzelnen Items im Product Backlog zuständig und entscheidet darüber, welche Anforderungen als nächstes umgesetzt werden sollen. Da die Priorisierung einen maßgeblichen Einfluss auf die Produktentwicklung hat, gibt es verschiedene praxiserprobte Techniken, die der verantwortliche Product Owner hierzu nutzen kann:
MoSCoW – Mo (Must be), S (Should be), Co (Could be), W (Won’t be)
Um die geplanten Features eines Produkts sinnvoll zu priorisieren muss man sich zunächst in den Benutzer und seine Anforderungen an das Produkt hineinversetzen. Aus dieser Perspektive heraus werden die Items des Backlogs dann in die folgenden Kategorien eingestuft:
Mo (Must)
Ohne dieses Feature ist das Produkt nicht nutzbar.
S (Should)
Should beschreibt ein Feature, ohne das das Produkt zwar grundsätzlich nutzbar ist, das aber einen immensen Mehrwert liefert.
Co (Could)
Mit Could wird ein Feature bezeichnet, das „nice-to-have“ wäre und beispielsweise eher dem visuellen Erscheinungsbild dient, ohne die grundlegende Funktionalität des Produkts zu beeinflussen.
W (Won´t)
Won´t beschreibt Anforderungen, die zunächst keinen oder nur einen sehr kleinen Mehrwert liefern und deshalb vernachlässigbar sind. Diese Anforderungen können in einem späteren Kontext noch einmal aufgegriffen werden.
Nachdem jedes Item entsprechend der o.g. Kriterien klassifiziert wurde, stellt das Entwickler-Team ein Set an Anforderungen zusammen, die im nächsten Sprint umgesetzt werden können und sollen (Commitment).
Alternativ oder auch ergänzend zu der MoSCoW-Methode kann das Prinzip Weighted Shortest Job First (WSJF) angewendet werden. Hierbei werden die Anforderungen des Product Backlogs anhand ihres jeweiligen Verhältnisses von Wert für das Produkt und dem zeitlichen Aufwand ihrer Umsetzung priorisiert. Der Wert eines Features für das Produkt wird mithilfe einer Formel als sogenannter Cost of Delay ermittelt.
Weitere Methoden die bei der Priorisierung des Product Backlogs zum Einsatz kommen können sind das simple Stack Ranking oder der 100-Dollar-Test, bei dem die Stakeholder gebeten werden fiktive Dollar auf die verschiedenen Items zu verteilen.
Welche Eigenschaften zeichnen einen guten Product Owner Ihrer Meinung nach aus?
Der Product Owner nimmt eine zentrale Rolle im Scrum-Prozess ein, da er eine Art Brücke zwischen den Stakeholdern auf der einen und dem Entwicklerteam auf der anderen Seite schlägt. Dabei ist es unerlässlich, dass er und seine Entscheidungen innerhalb der gesamten Organisation respektiert werden. In dieser Position sind deshalb einige Eigenschaften des Product Owners besonders wichtig:
Fachliches Verständnis
Ausgeprägte Kenntnisse der Domäne und des Marktes sind essentiell für die erfolgreiche Arbeit eines Product Owners. Er muss das Produktumfeld und die dazugehörigen einflussnehmenden Faktoren gut kennen, um die Bedürfnisse des Kunden richtig zu verstehen und die Anforderungen an das Produkt entsprechend einstufen zu können.Kommunikation
Aufgabe des Product Owners ist es nicht nur, das Backlog zu priorisieren, sondern seine Entscheidungen auch verständlich und nachvollziehbar gegenüber dem Team zu kommunizieren. Der Product Owner ist dafür zuständig, die Produkt-Vision, also das große Ganze, zu visualisieren. Er hilft dem Entwicklerteam dabei, nicht den Blick auf den Sinn und Zweck hinter dem Umsetzen von Anforderungen zu verlieren.Technisches Verständnis
Insbesondere in der Zusammenarbeit mit Entwicklerteams ist es ein großer Vorteil, wenn der Product Owner selbst zumindest ein grundlegendes Verständnis für den Entwicklungsprozess mitbringt. So kann er mögliche Hindernisse (Impediments) besser einschätzen und damit zusammenhängende Verzögerungen gegebenenfalls auch in Richtung der Stakeholder fundiert rechtfertigen.Was verstehen Sie unter einer nicht-funktionalen Anforderung und wie integrieren Sie sie in den Entwicklungsprozess?
Als nicht-funktionale Anforderungen (non-functional requirements NFRs) werden Produkt-Eigenschaften beispielsweise in Bezug auf Sicherheit, Zuverlässigkeit, Skalierbarkeit oder auch Usability bezeichnet. Sie spielen eine wichtige Rolle für die Systemarchitektur. Um diese Anforderungen im Entwicklungsprozess abzubilden, gibt es verschiedene Optionen:
Man kann nicht-funktionale Anforderungen ebenso wie funktionale Anforderungen in Form von User Stories verpacken und daraus entsprechende Backlog Items ableiten.
Ebenso können sie in der sogenannten Definition of Done (DoD) erfasst werden, eine Art Liste auf der das Team für alle User Stories festlegt, wann diese als erfolgreich erledigt betrachtet werden können. Die Definition of Done enthält beispielsweise Elemente wie Programmierstandards, Testing und Dokumentationserstellung.
Eine weitere Möglichkeit zum Umgang mit nicht-funktionalen Anforderungen besteht darin, sie als notwendiges Akzeptanzkriterium (Acceptance Criteria AC) für eine User Story aufzunehmen. Erst wenn neben der funktionalen Umsetzung auch alle notwendigen Akzeptanzkriterien erfüllt sind, kann eine Anforderung als vollständig erledigt eingestuft werden.
In diesem Beitrag haben wir Fragen und Antworten zusammengestellt, die Anregungen für das Vorstellungsgespräch eines Product Owners bieten. Über Ergänzungen freuen wir uns natürlich wie immer in den Kommentaren!
Bildquelle: © Depositphotos.com/AndrewLozovyi (Andrew Lozovyi)
