Product Owner

Der Product Owner trifft die Entscheidungen über die Produktausrichtung und definiert zusammen mit dem Scrum Development Team die Aufgaben. Er stellt sich heroisch den kritischen Stakeholdern, kennt sein Produkt In- und Auswendig und ist über alle Zweifel erhaben.

Der Product Owner ist für die Übersetzung der Visionen in Aufgaben zuständig. Er hat direkten Kontakt mit den Kunden und erarbeitet, mit Unterstützung des Scrum Masters, ein Produkt-Backlog. Aufgaben werden durch den Product Owner ausgearbeitet, Anforderungen formuliert und Abnahmekriterien aufgestellt. Ferner erfolgt durch den Product Owner eine Priorisierung der Aufgaben im Produkt-Backlog und die Abnahme der erledigten Aufgaben fällt in dessen Aufgabenbereich am Sprint-Ende.

Eine (nicht ganz vollständige) Auflistung seiner Aufgaben:

  • bereitstellen/vermitteln der Vision
  • vorbereiten des Sprint-Inhaltes
  • Priorisierung der Aufgaben
  • erstellen einer Roadmap
  • Pflege des Backlogs
  • Verantwortlich für das Produkt
  • Inhaltliche Verantwortung
  • Beratung des Kunden
  • Kundenkontakt
  • Übersetzer (von den Anforderungen des Kunden in die Entwicklersprache)
  • erstellt User Stories
  • beschreibt Anforderungen
  • hat Budget-Verantwortung
  • für die Abnahme am Sprint-Ende durch / Produkt-Abnahme
  • holt Kundenfeedback ein

Projekt-Retrospektive mit mehreren Teams

Im letzten Kundenprojekt stand ich (Patric Eid) zusammen mit meinem Kollegen Jan Breitschuh (https://www.xing.com/profile/Jan_Breitschuh2) vor der Herausforderung, eine Retrospektive in über 20 Areas gleichzeitig durchzuführen.

Das Projekt-Setup

Die Projekt-Organisation ist nach LeSS ausgerichtet mit 20 bis 25 Areas und insgesamt ca. 35 Teams. Die Retrospektive fand im Rahmen der Cadence Change Days (CCD) statt, an denen das Review der vergangenen 3 Monate und die Planung der nächsten 3 Monate besprochen worden sind. An den CCDs nahmen die Area Produce Owner, der Führungskreis der Organisation und einige Team-Mitglieder statt.

Ablauf der Retrospektive

Die Retrospektive wurde in 2 Teilen durchgeführt: 1. sammeln von Feedback und 2. Generierung von Maßnahmen zur Optimierung. Wir haben uns Gedanken gemacht, wie ein wertvolles Feedback aus der großen Teilnehmergruppe von über 50 Personen mit unterschiedlichen Interessen (Führungskräfte, Product Owner, Team-Mitglieder) erhalten. Wir haben uns schnell darauf geeinigt, dass wir die Product Owner und die Führungskräfte in zwei verschiedene Gruppen unterteilen, um von beiden Gruppen ein eigenes Bild zum aktuellen Projektstatus zu erhalten. Für das Einholen des Feedbacks haben wir auf die Liberating Structures-Methode 1-2-4-All zurückgegriffen.

1-2 wurde dabei in den beiden Gruppen durchgeführt, anschließend wurden beide Gruppen für das Bilden der 4er-Paare und dem Zusammenführen der Erkenntnisse vereint. Im Nachfolgenden der genaue Aufbau und Ablauf der Retrospektive.

Vorstellung des Ablaufs der Retrospektive

Ausgangssituation: in der großen Gruppe wurde der Ablauf der Retrospektive erklärt und der zeitliche Ablauf skizziert.

Vorstellen der Agenda in der großen Gruppe

Aufteilung in zwei Teilgruppen

Anschließend wurden die beiden Gruppen „Product Owners und Team“ und „Führungskreis“ gebildet.

„Product Owner“ und „Führungskreis“

Schritt 1: Einzelarbeit zur Beantwortung der Retro-Fragen

In Einzelarbeit sollte sich jeder 5 Minuten Gedanken zum Projekt machen. Die beiden zu beantworteten Fragen lauteten:

  • Was ist gut gelaufen?
  • Wo besteht Optimierungsbedarf?

Die Timebox dieser Einheit wurde auf 5 Minuten gestellt. Zielvorgabe: bis zu 5 Punkte pro Person, zu notieren auf Moderationskarten.

Schritt 2: 2er-Gruppen bilden

Nachdem jeder für sich die beiden Fragen beantwortet hat, sollten zweier Teams gebildet werden. In den zweier Gruppen wurden die zuvor notierten Erkenntnisse diskutiert und die Kleingruppen einigten sich auf 4 bis 5 Moderationskarten, die für beide wichtig waren. Als Timebox galt hierfür 10 Minuten.

Zusammenfassen in Kleingruppen

Schritt 3: Get Together

Beide Teilgruppen wurden aufgelöst und im großen Raum wieder zusammengeführt. Es wurden anschließend 4 große Gruppen gebildet, in denen die zweier Teilgruppen aus dem Schritt zuvor ihre Erkenntnisse untereinander vorstellten. Diese 4 Gruppen hatten zur Aufgabe, aus den gesammelten Moderationskarten der zweier Teilgruppen 4 bis 5 Punkte herauszusuchen, die für alle Teilnehmer wichtig waren. Die Timebox wurde auf 10 Minuten gestellt.

Zusammenführen der Teilergebnisse

Schritt 4: Kurze Vorstellung und Priorisierung

Die 4 Gruppen stellten ihre Ergebnisse kurz vor, in dem jede Gruppe ihre 4 bis 5 Moderationskarten an eine gemeinsame Metaplanwand hefteten. Dabei wurden gleiche Punkte bereits geclustert. Als Timebox galt 2 Minuten pro Gruppe.

Anschließend erfolgte die Priorisierung. Dazu bekam jeder Teilnehmer 2 Aufkleber, die er auf frei auf die verfügbaren Moderationskarten aufkleben konnte.

Daraus wurden die 5 Modearationskarten/Themengebiete herausgesucht, die die meisten Votes erhalten haben.

Schritt 5: gemeinsame Überschrift finden

Für die 5 Themen wurden Gruppen gebildet. Dabei wurde darauf geachtet, dass in jeder Gruppe mindestens 3 Teilnehmer sind. Ansonsten war jedem die Einteilung zur jeweiligen Gruppe frei überlassen.

Die Aufgabe: jede Gruppe sollte für sich eine Überschrift des Themas finden. Dabei sollte das Thema in wenigen Worten umschrieben werden. Als Timebox wurden 10 Minuten vorgegeben.

Maßnahmen ableiten

Die in Schritt 5 zusammengestellten Gruppen wurden am nächsten Tag damit beauftragt, Maßnahmen zur Optimierung der aufgekommenen Punkte herauszuarbeiten.

Schritt 1: Maßnahmen ableiten

Jede Gruppe sollte 2 bis 3 Maßnahmen ableiten und ihrem Punkt an eine Metaplanwand anbringen. Dazu wurde eine Timebox von 20 Minuten vorgegeben.

Wichtig dabei: jede Maßnahme wurde mit RAS ergänzt.

  • R = Responsible -> an wen die Maßnahme adressiert wird
  • A = Accountable -> wer die Maßnahme beauftragt (standardmäßig die jeweilige Gruppe und evtl. weitere Personen)
  • S = Support -> von wem Support erwartet werden kann (aus dem Rahmen der Gruppe) und wer darüber hinaus Support leisten muss

Schritt 2: Vorstellen

Jede Gruppe bekam als Timebox 2 Minuten, um ihre Maßnahmen allen anderen Gruppen vorzustellen. Anschließend wurde ein gemeinsames Commitment abgegeben, dass alle an der Umsetzung der Maßnahmen arbeiten werden und die Umsetzung „überwacht“ wird.

Fazit

Das Unterteilen der großen Gruppe in der Retrospektive in zwei Teilgruppen hat sehr gut funktioniert. Zwei Moderatoren waren in beiden Gruppen parallel und konnten dort die aufkommenden Fragen beantworten und die unterschiedlichen Gruppen daher gut begleiten.

Da der Führungskreis vom Rest der Teilnehmer getrennt war, wurden auch kritische Punkte wie zum Beispiel die genaue Aufgabe des Führungskreis im Projekt angesprochen. Anschließend hat eine offene Diskussion über die Optimierungspunkte und den abgeleiteten Maßnahmen stattgefunden.

Es wurde vereinbart, dass die Maßnahmen (bzw. deren Erfüllung) der Retrospektive in den Overall Reviews überprüft werden. Außerdem wurde sich geeinigt, dass solche Retrospektiven häufiger durchgeführt werden sollten.

Estimation Meeting als Sprint-Vorbereitung

Das Estimation Meeting wird ein- oder zweimal pro Sprint durchgeführt. Bei dem Meeting kommt das Scrum Development Team mit dem Product Owner zusammen, um User Stories zu besprechen. Bei dem Meeting geht es weniger um eine Aufwandsschätzung mit Story Points, als vielmehr eine Grundlage für zukünftige Sprints zu legen.

Unklarheiten beseitigen

Der Product Owner wird in diesem Meeting User Stories präsentieren, die mit dem Scrum Development Team zusammen diskutiert werden. Das Team fragt Fragen und der Product Owner wird die User Story verbessern, in dem er alle Fragen beantwortet und die Ergebnisse in der User Story notiert. Ggf. wird das Team feststellen, dass eine User Story zu komplex für einen Sprint ist. In dem Fall wird es zusammen mit dem Product Owner die User Story in mehrere kleinere User Stories herunter brechen.

Schätzungen anpassen

Von Zeit zu Zeit wird der Product Owner nicht nur neue User Stories mit dem Team besprechen, sondern bereits bekannte User Stories erneut diskutieren. Gründe hierfür können neue Erkenntnisse mit Auswirkungen auf die Aufwandsschätzung sein, oder auch der Aufbau von Erfahrungen im Team. Durch das wiederholte Betrachten der User Stories werden die Schätzungen im Product Backlog kontinuierlich optimiert, was zu einer besseren Vorhersagbarkeit bei der Roadmap-Gestaltung führt.

Vorbereitung auf das Sprint Planning

In der Anfangsphase eines neuen Projekts wird der Fokus auf der Planung des nächsten Sprint Plannings liegen. Product Owner und Team besprechen dann bereits bekannte User Stories, bei denen die Rückfragen bereits geklärt sind. Dadurch kann die benötigte Zeit im Sprint Planning 1 reduziert werden. Das Sprint Planning wiederum kann sich dann darauf konzentrieren zu ermitteln, welche User Stories im nächsten Sprint umgesetzt werden können, anstatt zusätzlich noch die Inhalte zu diskutieren.

Voraussetzung für eine Roadmap

Im weiteren Projektverlauf wird der Product Owner auch User Stories diskutieren, die erst in der Zukunft relevant sein werden; vielleicht im übernächsten Sprint, nächsten Monat oder auch in drei Monaten. Wenn zusätzlich die User Stories auch geschätzt werden (z.B. mit Hilfe von Story Points) und die Velocity bekannt ist, dann hat der Product Owner alles zur Hand, um daraus eine Roadmap zu generieren.

Die Aufgaben von Scrum Master und Product Owner

Wenn Scrum oder andere Prozesse in einem Unternehmen eingeführt werden, dann ist es sehr hilfreich, wenn die Rollen klar definiert werden. Es muss klar herausgestellt werden, wer für was verantwortlich ist und zu wem jemand gehen muss, um eine(n) Lösung/Antwort/Denkanstoß zu erhalten. In Scrum gibt es im Wesentlichen drei Rollen: Scrum Team (oder auch Scrum Developer genannt), Product Owner und Scrum Master.
Hier eine kurze Auflistung der Aufgaben von Scrum Master und Product Owner, die typischerweise von diesen Rollen übernommen werden.

Product Owner:

  • bereitstellen/vermitteln der Vision
  • vorbereiten des Sprint-Inhaltes
  • Priorisierung der Aufgaben
  • erstellen einer Roadmap
  • Pflege des Backlogs
  • Verantwortlich für das Produkt
  • Inhaltliche Verantwortung
  • Beratung des Kunden
  • Kundenkontakt
  • Übersetzer (von den Anforderungen des Kunden in die Entwicklersprache)
  • erstellt User Stories
  • beschreibt Anforderungen
  • hat Budger-Verantwortung
  • für die Abnahme am Sprint-Ende durch / Produkt-Abnahme
  • holt Kundenfeedback ein

Scrum Master:

  • sorgt dafür, dass Scrum funktioniert
  • setzt sich für die Organisationsentwicklung ein
  • hilft bei der Organisation im Team
  • führt eine kontinuierliche Prozess-Optimierung durch
  • stimmt sich mit anderen Scrum Mastern ab
  • sorgt für die Abstimmung mit anderen Teams
  • pocht auf Regeln und Meetings
  • unterstützt den Product Owner bei Bedarf
  • moderiert Meetings
  • Schutzschildfunktion (schützt das Team vor äußeren Störfaktoren)
  • Bindeglied zum Product Owner
  • das gute Herz des Teams
  • fordert Dokumentation ein und erstellt ggf. Meeting Minutes
  • beseitigt Hindernisse (und deckt sie ggf. auf)
  • beschafft Informationen/Räume/Material