Definition:
In der Rolle des Product Owner befindet sich derjenige, der auch maßgeblich für das "Produkt Backlog" verantwortlich ist. Der Product Owner nutzt definierte Prozessmeetings (das Grooming), um beispielsweise dessen Pflege und die Weiterentwicklung im gemeinschaftlichen Rahmen voranzutreiben. Der Product Owner ist auch weigehenst für die Steuerung der zu entwickelten Elemente verantwortlich. Die dafür zu Grunde gelegten Informationen besorgt oder erhält der Product Owner von seinem Umfeld (den Stake Holdern). Er ist auch maßgeblich 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 anderer 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 zu erstellen.
Ein kleines HOW TO - Umgang und (Selbst-) Organisation:
Kollaboration
- 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 Vorstellung von dem zu betreuenden Produkt, auch hat er alle Argumente, Vorschläge und Wünsche dokumentiert. Alle 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ätzliche Termine zu veranstalten, ist das ein Zeichen dafür, dass der Prozess hier nicht die notwendigen Bedürfnisse abdeckt. Hier 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 der Bedürfnisse für alle Rollen erreichbar ist. Im agilen Umfeld ist es essentiell einen aktiven Kontakt zu pflegen.
Verwaltung
Für einen Product Owner der sich nicht so organisiert hat, dass er flexibel mit Änderungen für sein Backlog umgehen kann wird vor sehr großen Problemen 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 eine Platz zu 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 verschiedenste Techniken und Methoden anwenden.
Priorisierung und Risikoabschätzung mit Techniken wie:
Präsentation
Die Release Demonstration ist der Moment, an dem die Erfolge der vergangen Wochen und Monate präsentiert werden. Es ist auch der Moment, der den Soll- / Istabgleich des Entwicklungstandes nach aussen offiziell darstellt und die Erwartungshaltungen im Umfeld der Stake Holder ggf. neu justiert.
Nun ist ja das Wort Erfolg doch sehr waage und individell 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" Kommitment haben, müsste man sich ggf. andere "Messpunkte" zur Bewertung heranziehen. (WIP, Durchlaufzeit, etc..).
Ein Resümee könnte wie folgt aufgebaut sein:
Seit der letzten Release-Demo haben wir:
- 20% mehr Bugs beheben können als im Durchschnitt über die Zeiträume der letzten 2 Release Demos
- 10% weniger neue Funktionen umgesetzt (wegen Bugs)
- 20% mehr Dokumentation
- Fehlerrate bei den Tests um 30% reduziert
- Stabilität des Buildserver wurde um 20% verbessert
- Zeit für Builds wurde um 30% verkürzt (Neue Hardware)
- unseren WIP um 10% gesteigert
- etc..
Grooming (Refinement)
Zu den Aufgaben eines Product Owner gehört auch Verständnis und Transparenz für den Planungsablauf von Arbeitselementen zu schaffen. Es gilt die eigene Roadmap 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 für einen Product Owner. Dabei ist es nicht entscheidend, ob er hier alle Formulierung 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 seinem sehr guten Verständnis und der Überzeugung zur Produktvision schafft er verwertbare Ergebnisse und drück dies in seinem Product Backlog aus.
"Story-Time Sessions" als Vorarbeit
In dieser Session werden große Produktmerkmale initial überflogen. Die Teilnehmer sind bestrebt in einer Art von Brainstorming ein oder mehrere Produktmerkmale mit sinnvollen User-Storys zu formulieren. Die User-Stories werden im Detail nicht weitergehend ausgearbeitet. Dieses Format erfordert von den Teilnehmern viel Disziplin. In einzelne Themenbereiche tiefer abzuschweifen ist hier oft nicht Produktiv. Hier ist der Moderator (Product Owner oder SCRUM Master) eine sehr wichtige Komponente die Teilnehmer "on Track" zu halten.
Das Ziel ist es eine möglichst vielfältige Grundlage an User Stories für weitere Groomings bereit zu stellen. In den Groommings werden dann einzelne User-Stories ganz 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. Jenachdem wie der "WIP" ist wird der Product Owner die Anzahl und die 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.: 2 Monate und sortiere grob alle gefunden Elemente in diese 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 Elemente fasst. UND ganz besonders wichtig, das 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, SOULD kategorisieren.
Erstelle aus dieser Liste eine Agenda für das Grooming. Frage die Teilnehmer, 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 hab ihr über ein Kollaborationstool eine Plattform die diese Form der Emailkommunikation ablösen kann)
Dieser definierte Zeitraum als Vorlauf solle immer für jedes Grooming FEST sein, so dass sich die Teilnehmer 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
