Product Owner

Was macht ein Product Owner den ganzen Tag? Er maximiert den Wert des Produktes! Hier ein Überblick über alle Tätigkeiten eines POs, welcher Aufgaben aus dem Scrum Guide, Kerntätigkeiten bei Scrum Events und konkrete Beispiel-Aufgaben umfasst:

Scrum Artefakte

  • ist für ein effektives Product Backlog Management und deren Ergebnisse verantwortlich
  • entwickelt das Produkt-Ziel und kommuniziert dies
  • erstellt PBI (Product Backlog Items) und kommuniziert diese
  • legt die Reihenfolge der PBIs fest
  • stellt sicher, dass das Product Backlog sichtbar, transparent und verstanden ist

Scrum Ereignisse

  • Daily
    Teilnahme optional, empfehlenswert falls inhaltliche Fragen auftauchen oder man den aktuellen Entwicklungsstand erfahren möchte
  • Refinement
    bringt User Stories mit höchster Wirkung für das Unternehmen / die Kunden ein, um diese mit dem Team durchzugehen und ein gemeinsames Verständnis zur Anforderung und zum Aufwand zu bekommen
  • Review
    • bereitet Ereignis vor, indem Stakeholder eingeladen werden von denen man Feedback haben möchte
    • zeigt Sprint Backlog (Team zeigt Ergebnisse)
    • sucht gemeinsames, transparentes Gespräch über neue Markt-Entwicklungen
  • Sprint Planning
    • erklärt wie das Produkt im nächsten Sprint die Wirkung für die User steigern kann
    • zeigt Team das priorisierte Product Backlog (Team entscheidet Umfang und zieht es in den Sprint Backlog)
    • definiert das Sprint-Ziel gemeinsam mit dem Team

1. Wirkung definieren

  • Produkt mit Stakeholder (Unternehmen, Kunden …) diskutieren (5 Whys)
  • Produkt und deren Wirkung kommunizieren (Product Vision Canvas, Business Story, Story Map …)
  • Wirkung beschreiben (Business Storys, Epics, User Storys …)
  • Metriken für diese Wirkung erstellen und aktuell halten

2. Markt erkunden

  • Lean Startup Techniken verwenden (MVP, Fake Landingpage, WireFrames, UX, Video produzieren …)
  • Business verstehen (Business Model Canvas erstellen)
  • Innovatives Denken ermöglichen (Innovation Workshop durchführen, Design Thinking, Design Sprints, Remember the Future …)
  • Prototyp bauen
  • Pitchen üben (Was ist das Produkt in einem Satz?)

3. Product Vision entwickeln

  • Product Vision entwickeln und vermitteln (und ggf. wieder anpassen)
  • Usersicht einnehmen (Personas / Job Stories der PV formulieren)
  • Product Vision Board erstellen und aktuell halten
  • Story Mapping Techniken anwenden (SM Workshop mit Team, Stakeholdern und Usern durchführen)
  • Product Vision regelmäßig pitchen (Findet Nemo, One Word, Moore …)

4. Marktoptionen prüfen

  • Marktanalyse durchführen
  • Gespräche mit Kunden/Usern führen, wie sie das Produkt sehen
  • Feedback von Marketing/Vertrieb holen, um Annahmen über Markt zu prüfen
  • Fachmessen besuchen

5. Stakeholder managen

  • Stakeholder Matrix erstellen
  • Product Backlog transparent machen und verständlich darstellen (SwiftKanban oder LeanKit statt Jira)
  • Berichte aufbauen und aktuell halten (Goal Oriented Roadmap, Parking Lot Diagram)

6. Feedback holen

  • Gemba Walk durchführen (Gemba or Production)
  • Fit for Purpose Umfrage durchführen
  • Product Review durchführen
  • Feedback aus Review / UX Tests / Gesprächen in Backlog einarbeiten

7. Backlog managen

  • Backlog übersichtlich halten (max. 100 Storys)
  • Aufgaben in einem einzigen Backlog zusammenführen (Features, Bugs, Zurufe, E-Mails …) um sie alle gegeneinander priorisierbar zu machen
  • User Storys schreiben (lassen, auch gerne vom Team)
  • User Storys Akzeptanzkriterien hinzufügen (die sich für automatisierte Akzeptanztests eignen)
  • Backlog durchgehen, um Storys auf gewünschte Wirkung zu prüfen
  • Top 10 User Storys immer parat haben / den Stakeholdern vermitteln können
  • Umfang des Produkts flexibel halten bzw. Kompromiss-bereit bleiben
  • Backlog DEEP halten (detailed appropriately, emergent, estimatable, prioritized)
  • User Storys INVEST halten (independent, negotiable, valuable, estimated, small, time-bound)
  • User Storys priorisieren (MoSCoW, Pirate Metrics, Eisenhower Matrix, Quick Wins, Kano Modell, Cost of Delay …)
  • User Storys besser mehr User Kontext hinzufügen als noch detaillierter zu spezifizieren
  • Entscheidungsformate überlegen (Delegation Poker, Konsens, Konsent, Buy a Feature …)

8. Sprints managen

  • Sprintkalender mit Scrum Master optimieren (wann welche Events stattfinden)
  • User ins Team integrieren
  • wöchentliche Refinements einführen, um User Storys mit dem Team zu besprechen/grob zu schätzen/zu schneiden, die die nächsten 2-3 Sprints betreffen
  • Sprint-Ziel definieren, das auf größere Ziele oder die Product Vision einzahlt
  • am Daily teilnehmen, um zu informieren / zu lernen / zu helfen
  • Sprint Planning vorbereiten und durchführen, indem man zu den Top PBI aussagefähig sein kann und ggf. Stakeholder als Gäste einlädt
  • Product Review vorbereiten und User das Product Increment selbst testen lassen während Team zuschaut und lernt
  • Prozess Feedback aus Review / UX Tests / Gesprächen in das Backlog einarbeiten

9. Messen

  • Geschwindigkeit der Sprints messen (T-Shirts sizing, Fibonacci, Man Days, #noestimates, Monte Carlo Simulation)
  • Geschwindigkeitsmessung checken (werden Sprints vorhersagbarer oder sinnlose Zeitverschwendung)
  • Forecasting über BurnDown/BurnUp Chart aktualisieren (lassen)
  • Tools oder Karten zum Schätzen verwenden
  • Alte User Storys mit Team durchgehen, wie sie diese heute schätzen würden

10. Prozesse verbessern

  • Kosten / Nutzen des Produkts ermitteln (Return on Invest)
  • Meetings vom Scrum Master moderieren und timeboxen lassen
  • Durchsatz / Durchlaufzeit der Entwicklung messen (lassen), um Engpässe zu erkennen
  • Scrum Master unterstützen Work in Progress (WiP) Limits einzuführen
  • Zulieferer in das Team integrieren
  • An Retrospektiven teilnehmen, um Prozesse und Kollaboration zu verbessern
  • Zulieferer-Teams einbinden um Prozesse/Schnittstellen zu vereinfachen
  • Sprint mit anderen Teams synchroniseren (lassen)
  • Team-übergreifende Events (Review, Retros) besuchen
  • Community of Practice (CoP) mit anderen POs gründen (um global zu optimieren, zB über Flight Levels)

11. Time to Market verbessern

  • Automatisierung vorantreiben (User Storys mit Team zum One-click Deployment und 10-min Builds schreiben)
  • Releases vereinfachen (User Storys mit Team zu kürzeren Release Zyklen schreiben)
  • Deployments erhöhen (Externe/Zulieferer ins Team holen oder User Storys kleiner machen)
  • Deployments flexibel halten (Feature Flags in den Code einbauen lassen)

12. Fehler reduzieren

  • Qualität erhöhen (Support fragen/einbinden, um Failure Demand zu erkennen)
  • Definition of Done (DoD) mit dem Team (und ggf. Stakeholdern) erstellen und einhalten (damit Qualität und Autonomie des Teams zunimmt)
  • Automatisierung vorantreiben (User Storys zur Automatisierung von Unit Tests und Regressions Tests schreiben)
  • Technical debts eruieren (technische Schulden mit Team eruieren und im Backlog priorisieren)
  • Test driven development ermöglichen (Team bestärken testgetrieben zu entwickeln)

13. Reflektieren

  • Aufgaben delegieren (Eisenhower Matrix, 7 Levels of Delegation)
  • Coach/Mentor engagieren, der sie für einen bestimmten Zeitraum / bestimmte Ereignisse begleitet
  • Firmenwerte und agile Werte mit den persönlichen in Einklang bringen (Commitment, Fokus, Mut, Offenheit, Respekt)
  • Klarheit bekommen, in welchem Kontext man arbeitet und in welche Richtung man sich entwickeln möchte (und dann Dinge von dieser Liste streichen, um sich zu fokussieren)
  • Erkenntnisse aus der Retro reflektieren