Rollen
Process Owner
Bei Scrum gibt es drei klar voneinander abgegrenzte Rollen: Den Scrum Master, den Product Owner und das Entwicklungsteam. Hierbei ist der Product Owner für die Wertsteigerung verantwortlich, nicht nur was das Produkt angeht, sondern auch in Bezug auf das Projektteam. Es handelt sich also um eine anspruchsvolle Rolle. Doch was macht ein Product Owner eigentlich genau? Welche wichtigen Eigenschaften und Verantwortlichkeiten hat ein Product Owner? Im Folgenden finden Sie eine Auflistung der fünf vorrangigsten Aufgaben und Verantwortlichkeiten des Product Owners.
1. Vertretung der Interessen des Kunden
Beim Product Owner handelt es sich immer nur um eine Person, die auch der Kunde oder der Auftraggeber selbst sein kann. Die wichtigste Aufgabe ist eine gute Vertretung der Interessen des Kunden. Die Zusammenarbeit mit den unterschiedlichen Stakeholdern ist daher sehr wichtig. Es liegt in der Verantwortung des Product Owners, mit jedem Stakeholder in regelmäßigem Kontakt zu stehen.
2. Zusammenarbeit mit dem Entwicklungsteam und dem Scrum Master
Die Zusammenarbeit und die Kommunikation mit dem Entwicklungsteam und dem Scrum Master ist von entscheidender Bedeutung. Wenn Sie die Rolle des Product Owners einnehmen, legen Sie nämlich fest, „was“ getan werden muss, jedoch lassen Sie dem Entwicklungsteam völlig freie Hand, „wie“ dies umgesetzt wird. Beim Entwicklungsteam handelt es sich also um ein sich selbst organisierendes Team. Der Product Owner kann diesem Team (im Gegensatz zum Scrum Master) daher zu keinem Zeitpunkt angehören. Dies ist für den Product Owner sehr gewöhnungsbedürftig, vor allem wenn er zuvor selbst als Projektleiter tätig war. Ein Projektleiter bestimmt nämlich nicht nur, „was“ getan werden muss, sondern auch „wie“ dies zu erfolgen hat und wer welche Aufgaben ausführt. Es ist wichtig, dass sowohl das Unternehmen als auch die externen Beteiligten respektieren, dass der Product Owner die Entscheidungen trifft. Indem die Entscheidungen von einer Person getroffen werden, ist die Richtung klarer und man sorgt dafür, „das Ding am Laufen zu halten“. Es wird nicht endlos darüber diskutiert, wer was wichtig findet und welche Folgeentscheidungen letztendlich getroffen werden müssen.
3.Verwaltung des Product Backlogs
Der Product Owner erstellt den Product Backlog und legt fest, in welcher Reihenfolge die Items bearbeitet werden sollen. Die wichtigsten Vorstellungen stehen immer ganz oben auf der Liste, weil sie für den Benutzer des Endprodukts den größten Wert liefern. Die Verwaltung des Product Backlogs besteht nicht nur aus der Einordnung nach Prioritäten, sondern auch und vor allem aus der eindeutigen Beschreibung der Items. Eine gute Beschreibung der Items im Product Backlog gewährleistet, dass das Projektteam sie versteht und bearbeiten kann. Die Items des Product Backlogs werden im „User Story“-Format geschrieben.
4. Überwachung der Fortschritte
Ein zeitlich nicht unwesentlicher Aspekt der Arbeit des Product Owners besteht daraus, Feedback zu geben. In dieser Hinsicht ist das Review Meeting am Ende eines Sprints für den Product Owner sehr wichtig, weil dort die Ergebnisse der geleisteten Arbeit vorgestellt werden. Der Product Owner legt die meisten Themen des Review Meetings fest und ist auch für die Einladung der wichtigsten Stakeholder verantwortlich. Bei dieser Gelegenheit übermittelt der Product Owner dem Entwicklungsteam sein Feedback. In diesem Meeting werden die gelieferten Items genehmigt oder abgelehnt. Auf Grundlage dieser „Endabrechnung“ wird ein Burndown Chart erstellt. Diese Grafik zeigt die Entwicklung an und soll die Prognose vereinfachen, wann ein Projekt vollständig abgeliefert werden kann. Das Feedback aus diesem Meeting dient zugleich auch als Input für die nächste Sprint Planning.
5. Entwicklung einer Vision des Endprodukts
Der Product Owner beschäftigt sich zudem mit der Entwicklung einer Vision des Endprodukts. Zu diesem Zweck müssen alle Entwicklungen auf dem Markt beobachtet werden. Das Erforschen, Beobachten und Analysieren des Marktes ist daher auch ein wichtiger Bestandteil seiner/ihrer Arbeit. Es ist wesentlich, dass der Product Owner weiß, was abläuft, weil verschiedene Interessen gegeneinander abgewogen werden müssen. Zudem ist es Aufgabe des Product Owners, dem Scrum-Team wichtige Informationen und Erkenntnisse in Bezug auf das Produkt mitzuteilen. Dies macht der Product Owner in jedem Fall bei der Sprint Planning.
Scrum Master
Die Scrum Master Rolle unterstützt den Prozess für das Team. Sie oder er begleitet das Team und sogt dafür, dass der richtige Prozess zum Einsatz kommt. Wenn sich zusätzlicher Schulungsbedarf ergibt, ist es der Scrum Master, der ein entsprechendes Training organisiert. Der Scrum Master ist auch für alle Meetings verantwortlich. Selbiges gilt für das Organisieren praktischer Dinge wie des Arbeitsplatzes, Software und Hardware. Damit ist er derjenige, der sicherstellt, dass das Team ungestört arbeiten kann. Dass andere sich mit zusätzlichen Anforderungen oder Aufgaben einmengen, hat der Scrum Master zu vermeiden.
Allerding ist der Scrum Master kein Projektmanager. Um Offenheit und Zusammenarbeit zu fördern, beschäftigt er sich nicht mit Personalangelegenheiten. Mit der Auswahl, Beurteilung und Entlohnung der Teammitglieder hat er nichts zu tun.
Team Member
User Story
Bei einer User Story handelt es sich um eine einfache Beschreibung einer Eigenschaft (eines sogenannten Features). Sie wird aus Sicht des Endnutzers verfasst. Also aus der Perspektive einer Person, die ein neues Produkt bzw. eine neue Dienstleistung oder einen Teil davon braucht. In der Regel handelt es sich um den (End-)Kunden. Eine User Story hat den folgenden simplen Aufbau:
Wer? Was? und Warum?
Als (Kunde) brauche ich (Beschreibung dessen, das entwickelt werden soll), damit ich (Beantwortung der Frage, weshalb das Produkt/ die Dienstleistung angeboten werden soll).
Was ist eine User Story?
Die einzelnen User Stories werden auf Zettel (z.B. PostIts) geschrieben. Dann hängt man sie auf das sogenannte Product Backlog. Hier kann sich das gesamte Team jede einzelne User Story anschauen. Zweck des Ganzen: Es wird deutlich, welche Arbeiten zu erledigen sind, wieviel Zeit sie jeweils in Anspruch nehmen und in welcher Reihenfolge die Aufgaben angegangen werden sollen.
Product Backlog
Der Scrum Product Backlog ist einer der wichtigsten Bestandteile eines jeden Scrum-Projektes. Sind Sie Product Owner, und von Ihnen wird erwartet, dass Sie einen Product Backlog erstellen? Oder sind Sie Scrum Master, und der Product Owner hat Sie gebeten, in Sachen Product Backlog Hilfestellung zu leisten? Dann werden Sie in diesem Blogartikel einige praktische Dinge erfahren, die Sie sich zunutze machen können.
Wie erstellen Sie die erste Fassung des Scrum Product Backlog?
Die erste Version davon wird oft auch als “Initial Product Backlog” bezeichnet. Diese erste Fassung ist das Ergebnis der Kombination von Informationen aus verschiedenen Quellen:
Die Produktvision: Ein guter Product Owner hat vorab eine Produktvision definiert. Von ihr alleine schon kann er viele Product Backlog Items ableiten. Eine Product Roadmap: Wenn ein bestehendes Produkt weiterentwickelt werden soll, gibt es oft eine Product Roadmap. Ein gutes Beispiel sind das iPhone 4, 5, 6, 7 usw. Die Roadmap liefert Input für den Product Backlog. Das Minimum Viable Product (MVP): Ein MVP ist das minimale Produkt, mit dem eine Organisation dem Kundenwunsch entsprechen kann. Ein Scrumteam hat i.d.R. zuerst diese erste Produktversion im Blick. Denn anhand des MVP bekommt es Feedback auf sein Arbeitsergebnis. Stakeholder: Benutzer und Käufer des zu entwickelnden Produktes sind vielleicht die wichtigste Quelle für Input für den Product Backlog. Sie können genau angeben, was sie benötigen. Wer das Scrum-Projekt gut angeht, hört genau zu, was die Stakeholder zu sagen haben. Das Entwicklerteam: Viele Scrum-Projekte erfordern viel Fachwissen. Deshalb wird in multidisziplinären Teams gearbeitet. Seine Mitglieder sind Spezialisten auf ihrem Gebiet. Auch sie liefern oft wertvolle Ergänzungen für den Product Backlog, die ein Product Owner oder auch Stakeholder schnell vergessen würden. All diese Quellen zusammen genommen bilden einen umfassenden Ausgangspunkt für die Definition von User Stories, mit denen Sie anfangen können.
Wie sieht ein guter Product Backlog aus?
Ein guter Backlog zeichnet sich durch vier Elemente aus. Eine praktische Eselsbrücke: Ein guter Product Backlog ist „DEEP“. Das sind die Anfangsbuchstaben der vier Elemente:
- Detailed (detailliert): ein guter Backlog besteht aus genügend Backlog Items (User Stories), um mindestens einen Sprint zu füllen. Im Idealfall reichen die Items für zwei Sprints. User Stories mit einer niedrigeren Priorität brauchen nicht allzu detailliert dargestellt zu werden. Items, die in Kürze angegangen werden sollen, müssen jedoch „fertig für den Sprint“ sein. Damit ist gemeint, dass das Entwicklerteam die Items genau versteht, sie klein sind und die Akzeptanzkriterien sowie eine Definition of Done deutlich definiert sind.
- Emergent (entwickelt sich nach und nach): Ein Product Backlog wird im Verlauf des Projektes (gemeinsam) nach und nach entdeckt. Vor dem ersten Sprint streben wir also nicht nach einem vollständigen Backlog. Stärker noch: Wir wissen es eben gerade zu schätzen, wenn noch kein vollständig ausgearbeiteter Plan vorliegt.
- Estimated (abgeschätzt): Die User Stories sind abgeschätzt. Oft geschieht das in einer Planning Poker Session mittels Story Points.
- Prioritized (mit Prioritäten versehen): Die User Stories im Product Backlog hat der Product Owner mit Prioritäten versehen. Die untenstehenden Faktoren sind bei der Priorisierung durch den Product Owner entscheidend.
Was ist “Backlog Grooming”?
Bei Backlog Grooming (manchmal auch als Backlog Refinement bezeichnet) handelt es sich um ein Meeting, das kein fester Bestandteil des Scrum-Prozesses gemäß der Definition im Scrum Guide ist. Tatsächlich hat sich dieses Meeting in der Praxis aber als eines der wertvollsten erwiesen. Denn in ihm wird der Product Backlog für das nächste Sprint Planning Meeting vorbereitet. Eine Backlog Grooming Session wird mit dem Entwickelteam abgehalten:
- User Stories gemäß neuester Erkenntnisse aktualisieren
- User Stories mit Prioritäten versehen
- Detail in User Stories anbringen und sie aufteilen
- Abschätzen von User Stories durch das Entwicklerteam
Product Backlog Grooming fällt unter die Verantwortlichkeit des Product Owners. Denn der Product Owner ist für den Product Backlog zuständig. Aber auch vom Entwicklerteam wird Input benötigt. Manchmal wird ein Teil des Entwicklerteams an dem Prozess beteiligt. Der Product Owner reserviert während des Sprints 10% ihrer oder seiner Zeit für das Grooming.