Definition:


In der Rolle des Product Owners befindet sich derjenige, der auch maßgeblich für das "Produkt Backlog" verantwortlich ist. Der Product Owner nutzt definierte Prozessmeetings (das Grooming), um beispielsweise die Pflege und Weiterentwicklung des Produkt Backlogs im gemeinschaftlichen Rahmen voranzutreiben. Der Product Owner ist hauptsächlich für die Steuerung der zu entwickelnden Elemente verantwortlich. Die dafür zu Grunde liegenden Informationen besorgt sich oder erhält der Product Owner von seinem Umfeld (den Stake Holdern). Er ist auch maßgeblich dafür verantwortlich, den guten Kontakt zu den Stake Holdern, vor allem aus dem näheren Kundenumfeld, zu pflegen.


Im Umfeld von KANBAN unterliegt die Art und Weise wie Arbeitselemente in den Entwicklungsablauf einfließen, etwas anderen Bedingungen als in SCRUM. In KANBAN gibt es keine feste zyklische Entwicklungsphase in Form eines Sprints. Somit wäre es auch nicht notwendig, sehr große Aufgabenelemente pflichtgemäß zu teilen. Jedoch, um einen konkludenten und stetigen Arbeitsdurchfluss zu gewährleisten ("WIP" - "Work In Progress") sollte der Product Owner darauf bedacht sein, vom Arbeitsumfang "ähnliche" Pakete erstellen.



Aufgaben / Kompetenzen:


  • Sammeln, filtern und sortieren aller notwendiger Informationen zu dem zu entwickelnden Produkt (aus dem Umfeld der Stake Holder)
  • Werten und priorisieren von Produktmerkmalen aus Sicht des Kunden
  • Pflegen von guten Kundenbeziehungen (z.B. "Alpha"-Kunde als Stake Holder)
  • Erstellen von Releaseberichten


Ansprechpartner / Schnittstellen:



Besondere Verantwortung:


  • Produktvision (festlegen bzw. vorantreiben und konkretisieren der Produktvision)
  • Produktversionspflege (Releaseplanung)
  • Produktplanung (Backlogplanung)
  • Entwicklungssteuerung (durch Priorisierung der geplanten Arbeitselementen und Produktmerkmalen)
  • Backlogpflege


Ein kleines HOW TO - Umgang und (Selbst-) Organisation:



  • Wie bereite ich eigene Meetings vor?

  • Entscheidungen gegen das "Management" treffen und begründen!
    Manchmal ist es für einen Product Owner wichtig, bestimmte Entscheidungen vor dem Management zu vertreten und sich nicht zu sehr einschüchtern und einschränken zu lassen. Hier muss er die eigene Position bekräftigen, indem er auf den Rückhalt seiner Stake Holder und den anderen Rollen im Entwicklungsprozess vertrauen kann. Nicht nur hat er eine sehr genaue Vorstellung von dem zu betreuenden Produkt, er hat auch alle Argumente, Vorschläge und Wünsche dokumentiert. All diese Informationen kann der Product Owner nutzen, um ein Vertrauen zum Management aufzubauen. Es hilft, harte Einschnitte, die aus seiner Sicht dem Produkt und dem Entwicklungsprozess schaden würden, abzuwenden.   

  • Abstimmung und Koordination - Welche Möglichkeiten habe ich?
    Der Rahmen aus den Regelmeetings bildet schon eine sehr gute Basis im regelmäßigen Kontakt zu allen Prozessbeteiligen (Rollen). Darüber hinaus steht es natürlich jeder Rolle frei, eigene Termine zu vereinbaren. Gibt es die Notwendigkeit, vermehrt solche zusätzlichen Termine zu veranstalten, ist das ein Zeichen dafür, dass der Prozess hier nicht die notwendigen Bedürfnisse abdeckt. Dann sollte eine Rücksprache mit dem SCRUM Master oder dem Agile Coach erfolgen.
    Der Product Owner sollte sich auch die Frage stellen, ob er ausreichend für die Bedürfnisse aller Rollen erreichbar ist. Im agilen Umfeld ist es essentiell, aktiven Kontakt zu pflegen.


Ein Product Owner, der sich nicht so organisiert hat, dass er flexibel mit Änderungen seines Backlogs umgehen kann, wird vor sehr große Probleme gestellt werden.

Der Product Owner sollte sich nach Möglichkeit mit Werkzeugen ausstatten, die ihm Folgendes erlauben:

  • schnelles und einfaches Erstellen von User-Stories
  • redundante Inhalte vermeiden (Informationen an einen Platz halten)
  • User Stories einfach teilen zu können
  • den Planungsprozess für alle sichtbar und nachvollziehbar einzusehen
  • weitgehend automatisiertes Vorbereiten von Elementen für das Grooming (Liste und Agenda)
  • bereitstellen von Informationen zu Synchronisationspunkten
  • Verwaltung von Anfragen von Stake Holdern und ggf. die Zuordung zu den User Stories

Zur Priorisierung der Elemente kann der Product Owner verschiedene Techniken und Methoden anwenden.

Priorisierung und Risikoabschätzung mit Techniken wie:


Die Release Demonstration ist der Moment, an dem die Erfolge der vergangenen Wochen und Monate präsentiert werden. Es ist auch der Moment, der den Soll-/Istabgleich des Entwicklungstandes nach außen offiziell darstellt und die Erwartungshaltungen im Umfeld der Stake Holder ggf. neu justiert.

Nun ist ja das Wort Erfolg doch sehr vage und individuell definiert. In SCRUM würde sich Erfolg durch die erfolgreiche Umsetzung aller Elemente des jeweiligen Sprint-Backlogs etwas einfacher definieren lassen. Da wir in KANBAN keine zeitliche Abgrenzung mit einem "festen" Commitment haben, müsste man sich ggf. andere "Messpunkte" zur Bewertung heranziehen (WIP, Durchlaufzeit, etc.).

Seit der letzten Release-Demo haben wir:

  • 20% mehr Bugs beheben können als im Durchschnitt über die Zeiträume der letzten zwei Release Demos
  • 10% weniger neue Funktionen umgesetzt (wegen Bugs)
  • 20% mehr Dokumentation erstellt
  • die Fehlerrate bei den Tests um 30% reduziert
  • die Stabilität des Buildserver um 20% verbessert
  • Zeit für Builds um 30% verkürzt (neue Hardware)
  • unseren WIP um 10% gesteigert
  • etc.




Zu den Aufgaben eines Product Owners gehört es auch, Verständnis und Transparenz für den Planungsablauf von Arbeitselementen zu schaffen. Es gilt, die eigene Roadmap zu erklären (je besser die Menschen den Plan in der Produktentwicklung verstehen, desto besser können sie konstruktiv zur passenden Zeit die richtigen Inhalte beitragen, ohne, dass aufwendige Schleifen gedreht werden müssen). Formulierungen wie: "Das stellen wir vorerst mal zurück" zeigen, dass die Menschen schon zu weit um das eigentliche Thema herum denken.

Die "Verfeinerung" (Refinement) von Produktmerkmalen bis hin zur entwicklungsfähigen Beschreibung ist die Kernaufgabe eines Product Owners. Dabei ist es nicht entscheidend, ob er alle Formulierungen und Beschreibungen in Einzelarbeit erledigt, vielmehr dass er sich von seinen fachkundigen Stellen inspirieren, beraten und ggf. korrekte Bausteine vorformulieren lässt. Er zeichnet sich durch ein effizientes Informationsmanagement und durch die Fähigkeit zur Informationsaufbereitung aus. Mit Hilfe seines sehr guten Verständnisses und der Überzeugung zur Produktvision schafft er verwertbare Ergebnisse und drückt dies in seinem Product Backlog aus.


In dieser Session werden große Produktmerkmale initial überflogen. Die Teilnehmer/-innen sind bestrebt, in einer Art Brainstorming ein oder mehrere Produktmerkmale mit User-Stories zu formulieren. Die User-Stories werden im Detail nicht weitergehend ausgearbeitet. Dieses Format erfordert von den Teilnehmer/-innen viel Disziplin. In einzelne Themenbereiche tiefer abzuschweifen, ist hier oft nicht produktiv. Dabei ist der Moderator (Product Owner oder SCRUM Master) eine sehr wichtige Komponente, die Teilnehmer/-innen "on Track" zu halten.

Das Ziel ist es, eine möglichst vielfältige Grundlage an User Stories für weitere Groomings bereitzustellen. In den Groomings werden dann einzelne User-Stories im Detail "beleuchtet" und auf einen Detailgrad gebracht, der eine reibungslose Umsetzung erlaubt.


Ist für die Groomings ein initial gefülltes Backlog vorbereitet, beginnt die Detailplanung. Je nachdem wie der "WIP" ist, wird der Product Owner die Anzahl und Häufigkeit der Groomings steuern. Eine Mindestanzahl an garantierten regelmäßigen Terminen ist hier jedoch sehr zu empfehlen.


Wie kannst du als Product Owner nun vorgehen? Hier ein Vorschlag:

Grooming - Vorbereitung

  • Ordne dein Backlog nach Zeiteinheiten, z.B.: zwei Monate. Sortiere grob alle gefundenen Elemente in diesen Zeitsektoren ein. Versuche hier, ausgeglichen vorzugehen (in jedem Zeitsektor die gleiche Anzahl an Elementen).
    Nach welchen Kriterien du diese Einteilung vornimmst, wirst du dir selbst überlegen müssen. Hierzu helfen dir bestimmt die Rückmeldungen deiner Stake Holder. Mach deinen Stake Holdern aber klar, dass ein Sektor nur eine bestimmte Anzahl an Elementen fasst. UND ganz besonders wichtig: Das sind nur Hilfseinteilungen, keine festen VERSPRECHEN. Diese Einteilung WIRD und DARF sich nach jedem Grooming ändern.
  • Erstelle dir vor dem Grooming eine Liste aus all den Elementen, die du im Grooming besprechen möchtest. Du kannst diese Elemente auch noch mit MUST und SHOULD kategorisieren.
    Erstelle aus dieser Liste eine Agenda für das Grooming. Frage die Teilnehmer/-innen, ob sie selbst noch zum zu besprechenden Themenbereich etwas im Vorfeld beisteuern möchten. Lass auf der Agenda ggf. absichtlich Platz für noch unbekannte Themen.
  • Verschicke vor dem Grooming (mind. 1 Tag vorher) noch die finale Version der Agenda (bestenfalls habt ihr über ein Kollaborationstool eine Plattform, die diese Form der E-Mail Kommunikation ablösen kann)
    Dieser definierte Zeitraum als Vorlauf sollte immer für jedes Grooming FEST sein, so dass sich die Teilnehmer/-innen darauf verlassen können, dass bis dahin alle Informationen zur Vorbereitung bereitstehen. Handhabe das ggf. genauso für alle anderen Arten von gemeinschaftlichen Aktivitäten.

Grooming - Grooming


Grooming - Nachbearbeitung