Verantwortung von Markt und Business durch den Product Owner

Das P4-Framework gliedert seine Organisations- und Managementstruktur der Produktentwicklung in drei Bereiche:

Markt und Business

Die Product-Owner-Rollen der verschiedenen Ebenen tragen die Verantwortung für die Produkte und deren Märkte. Dabei kommunizieren sie mit den Stakeholdern dieses Bereichs: Benutzer, Kunden und der (meist interne) Vertrieb.

Die Rolle des Product-Owners

Product, Product Backlog und Product Owner sind im P4-Framework generische Begriffe, d.h. sie existieren ausschließlich in spezifischen Ausprägungen. So hängen sowohl die generischen Artefakte „Product“, „Product Backlog“ als auch die generische Rolle „Product-Owner“ von der Art des jeweiligen Teams und der Ebene innerhalb der Organisation ab.

Der Product-Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Working-Teams entsteht. Wie dies geschieht, kann je nach Organisation, Cluster oder Team und Einzelpersonen stark variieren. Der Product-Owner ist die einzige Person, die für das Management des Product-Backlogs verantwortlich ist. Das Management des Product-Backlogs umfasst:

  • Die Product-Backlog-Einträge klar zu formulieren;
  • Die Reihenfolge der Einträge im Product-Backlog so anzuordnen, dass Ziele und Missionen optimal erreicht werden können;
  • Den Wert der Arbeit zu optimieren, die das Working-Team durchführt;
  • Sicherzustellen, dass das Product-Backlog sichtbar, transparent und für alle klar ist und zeigt, woran das Team als nächstes arbeiten wird;
  • Sicherzustellen, dass das Working-Team die Product-Backlog-Einträge im erforderlichen Maße versteht; und
  • Die Ergebnisse des Working-Teams zu begutachten und abzunehmen.

Der Product-Owner kann die oben genannten Arbeiten selbst durchführen oder sie durch das Working-Team oder einzelne Mitglieder durchführen lassen. Der Product-Owner bleibt jedoch immer rechenschaftspflichtig (accountable).

Der Product-Owner ist eine einzelne Person, kein Komitee. Er kann zwar die Wünsche eines Komitees im Product-Backlog wiedergeben, aber diejenigen, die einen Eintrag des Product-Backlogs in seiner Priorität verändern möchten, müssen sich an den Product-Owner wenden. Damit der Product-Owner erfolgreich sein kann, muss die gesamte Organisation seine Entscheidungen respektieren. Die Entscheidungen des Product-Owners sind in Inhalt und Reihenfolge des Product-Backlogs sichtbar. Niemand anderer darf dem Working-Team Anforderungen oder Arbeit zuordnen.

Die Product-Owner im P4-Framework

Im P4-Framework wird die generische Rolle des Product-Owners auf allen drei Ebenen konkretisiert und erweitert: Wichtig dabei ist, dass die Product-Owner auf  jeder Ebene sich untereinander innerhalb der jeweiligen PO-Gruppe abstimmen und dabei die Prioritäten für ihre Teams aus dem übergeordneten Backlog ableiten. (Mehr zu dem Überlappungsprinzip)

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

.

Cluster-Planning

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospektive

.

Portfolio-Planung

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospektive

Team-System-Engineer

Team-Scrum-Master

.

Cluster-System-Engineer

Cluster-Scrum-Master

.

Portfolio-Architekt

Organisations-Scrum-Master

Team-Product-Owner-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Typen von Backlog-Einträgen

„Das Backlog ist die einzige Quelle der Arbeiten.“ Die allgemeine Beschreibung eines Backlogs und seiner Eigenschaften ist hier zu finden.

Backlog-Einträge bzw. Backlog-Items sind die Einzelbausteine von Backlogs. Sie werden innerhalb der Backlogs eindeutig nach Rang geordnet, also eindeutig priorisiert. Je weiter oben ein Backlog-Eintrag steht, desto wichtiger ist er und desto früher wird er bearbeitet.

Gemeinsamkeiten

Alle Backlog-Einträge haben folgende Eigenschaften und Attribute:

  • Einen eindeutigen Kurznamen oder eine sonstige Identifikation (z.B. eine Nummer)
  • Eine möglichst kurze, aber aussagekräftige Beschreibung
  • Einen Hinweis darauf, wer die Quelle bzw. der Verfasser des Backlog-Eintrags ist. Damit soll klar werden, wen man bei Unklarheiten fragen kann.
  • Zur Konkretisierung und Abgrenzung sind Akzeptanzkriterien definiert
  • (Optional) Auf Portfolio- und Systemebene schätzen die jeweiligen Product-Owner den  Nutzwert von Applikationen und Features ab. Hierfür werden Nutzwerte verschiedener Appikationen/Features relativ gegeneinander bewertet, wobei die Product Owner dazu z.B. Planning Poker verwenden.
  • Um anzuzeigen, dass das betreffende Team eine Analyse und Abschätzung durchgeführt hat, wird der geschätzte Aufwand auf dem Backlog-Eintrag notiert

Unterteilung von Backlog-Items nach Typ, Ebene, Größe und Format

Formate

In der Software-Entwicklung hat sich das Spezifizieren von Backlog-Items im Format von User-Stories etabliert. Hierbei wird eine Benutzer-Anforderung in Form eines Satzes beschrieben (Wer möchte Was, Warum). P4 bevorzugt hier den Begriff der Stakeholder-Story, da die Benutzer des Systems nur einen Teil der Anforderer darstellen.

Zur weiteren Ausarbeitung werden häufig Use-Cases genutzt, die in verschiedene Szenarien aufgeteilt werden können.

Mittels Prosa-Anforderungen können einzelne Komponenten, Schnittstelle und deren Fähigkeiten und Eigenschaften beschrieben werden.

Größe

Zur Bearbeitung einer Story durch ein Team, muss diese so klein sein, dass sie in eine Iteration passt. Größere Stories sind per Definition Epics, wobei Epics wiederum in mehrere Stories geteilt werden müssen.

Typ und Ebene

Jede Backlog-Item-Ebene stellt in der Summe ihrer Einträge, den Gesamtaufwand der Produktentwicklung bzw. einer auslieferbaren System-, Markt- oder Applikationsvariante dar.

Dies ist auch die Idee von Epics, Stories und Tasks, die viele Teams bei der Verwendung von Scrum nutzen. Die Summe des Aufwands in allen Epics entspricht der Summe des Aufwands in allen Stories. Dies basiert auf der (theoretischen) Annahme, dass eine Story fertig ist, wenn alle Tasks fertig sind und ein Epic fertig ist, wenn alle enthaltenen Stories fertig sind. Genauso verhält es sich mit dem Gesamtaufwand.

Wenn ein Applikationsteam oder die Cluster-System-Engineer-Gruppe in der Lage ist, alle Backlog-Einträge auf Basis der System-Anforderungen & Funktionen mit den limitiernden Quality Attributes & Constraints, zu schätzen, ist der Gesamtaufwand einer Applikation komplett geschätzt. Da dies meist nicht einfach möglich ist, müssen die Anforderungen weiter auf die Lösungsebene der Systemkonzepte, Architektur und Fähigkeiten herunter gebrochen werden. Auch auf dieser Ebene wird es meist nicht möglich sein, alle Konzeptelemente genau genug zu schätzen, da noch viele Unbekannte und Unsicherheiten (in P4: Wissenslücken) bezüglich der Machbarkeit und der Art der Umsetzung bestehen.

Das Konzept der Wissenslücken basiert auf der Annahme, dass nach dem Schließen aller Wissenslücken die Produktentwicklung erfolgreich beendet ist. Die Summe der Aufwände zum Schließen aller Wissenslücken entspricht also ebenfalls dem Gesamtaufwand der Produktentwicklung. Die Schätzung auf dieser Ebene möglich zu machen erfordert allerdings eine gewisse Zeit, bis die Organisation gelernt hat, dies mit einer genügenden Genauigkeit zu tun.

Normalerweise schätzen Organisationen ihre Aufwände auf Basis der Samples & Integrations, da hierbei die Aufwände zum Schließen der Wissenslücken, deren Randbedingungen und Annahmen wesentlich konkreter definiert sind und die Backlog-Einträge bis auf die Ebene der aufzubauenden Simulationen, Muster und Prototypen verfeinert sind. Wichtig hierbei ist, dass das inkrementelle und ggf. mehrfache Erzeugen und Integrieren von Mustern ausreichend berücksichtigt wird und je nach Innovationsgrad und dem Risikograd der Wissenslücken, mehrere „Prove-of-concepts“ bzw. Wegwerfprototypen nötig werden können.

Ein noch weiteres Herunterbrechen ist auf der Arbeitsebene dann nötig, wenn Samples & Integrations von mehreren Teams realisiert werden. Hierfür werden die Backlog-Einträge gemäß der beteiligten Teams in Team-Ziele aufgeteilt und jedes Team schätzt die bei ihm anfallenden Aufwände. Diese können retrospektiv tatsächlichen Aufwänden zugeordnet werden und damit die relativen Schätzungen normiert oder geeicht werden.

Auf jeder Ebene der Backlog-Typen wird die Produktentwicklung also komplett beschrieben und geschätzt. Bei Nutzung von relativen Punkten zur Abschätzung, wird also auf  jeder Ebene eine eigene „Währung“ verwendet. Die Währungen können ineinander umgerechnet werden, wenn nach einiger Zeit Daten vorliegen, die aufzeigen, welche Arbeitsgeschwindigkeit die Organisation auf den verschiedenen Ebenen entwickelt (Velocity).

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Backlog-Refinement

Team-Review

.

Cluster-Planning

Cluster-Backlog-Refinement

Cluster-Review

.

Portfolio-Planung

Portfolio-Refinement

Portfolio-Review

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

.

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

.

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Working-Team

Community-of-Practice

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Team-Backlog

Team-DoD

Team-Improvement-Backlog

.

Cluster-Backlog

Cluster-DoD

Cluster-Improvement-Backlog

.

Portfolio-Backlog

Organisations-DoD

Organisations-Improvement-Backlog

Benutzer, Kunden und Vertrieb

Dies sind die primären Stakeholder der Produktentwicklung auf allen Ebenen (Organisation, Cluster und Team). Auf der Team-Ebene haben besonders die Applikations-Teams einen engen Kontakt zu Benutzern, Kunden und dem Vertrieb, da sie die ultimativen Anforderungen an die Produkte, Systeme und Applikationen geben, sowie diese bewerten.

Stakeholder werden zu den Reviews eingeladen (also Team-Reviews, Cluster-Review, Portfolio-Review), um dem entsprechenden Team Feedback zu geben.

Stakeholder können zu Refinement-Meetings zur Klärung von Anforderungen eingeladen werden.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Backlog-Refinement

Team-Review

.

Cluster-Backlog-Refinement

Cluster-Review

.

Portfolio-Refinement

Portfolio-Review

Team-Product-Owner

Team-System-Engineer

.

Cluster-Product-Owner

Cluster-System-Engineer

.

Portfolio-Owner

Portfolio-Architekt

Working-Team

Community-of-Practice

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD