Teil 3/4: So sieht Euer Wochen-Alltag als Product Owner im Detail aus
In unserer Artikelserie zeigen wir Euch, wie die Abräumer von morgen Produkte völlig ohne Projektmanagement entwickeln und dabei Zeit, Geld und Nerven sparen – und worauf ihr dabei achten müsst. Im ersten Schritt habt Ihr Eure Entwicklung bereits transformiert und arbeitet ohne Projektmanagement, dafür aber nun mit der dedizierten Rolle des Product Owners. Woher Ihr nun wisst, ob Ihr und der Product Owner auf der richtigen Spur seid und erfolgreich sein werdet, erfahrt Ihr in diesem Beitrag der Serie.
Weiterlesen
Wir behandeln das Thema in einer Serie bestehend aus 4 Artikeln, die unterschiedliche Aspekte beleuchten. Und am Ende der Artikelserie werdet Ihr wissen, wie Ihr die Transformation vom klassischen Projektmanagement zu modernen erfolgreichen Ansätzen hinbekommt, welche Aufgaben und Zuständigkeiten ein sogenannter „Product Owner“ (im Folgenden mit „PO“ abgekürzt) tatsächlich hat und woher dieser weiß, ob er/sie erfolgreich ist, bzw. gute Arbeit abliefert. Wir werden uns aber auch ansehen, wie eine gute Wochenroutine aussieht, die Euch bei Eurem Erfolg helfen wird. Und um das Thema vollumfänglich abzurunden, werfen wir ein besonderes Augenmerk auf die Wichtigkeit der Einschätzung des Bearbeitungs- und vor allem auch Abnahmeaufwandes.
Fassen wir kurz nochmal zur Orientierung zusammen, worum es in der Artikelreihe Produktentwicklung ohne Projektmanagement gehen wird:
- Wie Euch die Transformation vom klassischen Projektmanagement zu modernen erfolgreichen Ansätzen gelingt
- Die Zuständigkeiten und Aufgaben der Product Owner-Rolle (PO)
- Woran der PO weiß, ob er/sie erfolgreich ist bzw. gute Arbeit macht
- Wie eine gute weekly Routine aussieht + Erfolgs- Checkliste
- Die Wichtigkeit der Einschätzung des Bearbeitungs- und vor allem auch Abnahmeaufwandes
Im dritten Artikel unseres Vierteilers geht es darum, wie die wöchentliche Routine eines Product Owners aussieht und welche Schritte besonders wichtig sind. Diesen Artikel könnt ihr daher insb. in eurer Anfangszeit super als Checkliste nutzen, um schnell und ordentlich in diese neue Rolle reinzukommen und direkt alles am Laufen zu halten.
Wir leben in einer volatilen, sich schnell verändernden Welt. Unternehmen bleiben nur dann marktfähig, wenn sie sich schnell genug anpassen können. Zweck ist, dass aktuell passende Ideen und aktuelle Bedürfnisse der Stakeholder (also auch der Mitarbeiter) innerhalb weniger Tage oder Wochen so gut bedient werden, um weiter gut arbeiten zu können. Ist etwas nicht mehr zeitgemäß, führt das schnell zu Unmut und Desinteresse, sowie zum Verlust des Marktes.
Dieser Zyklus gibt Euch als Product Owner Sicherheit
Der Zyklus eines Product Owners umfasst im besten Fall 4 Schritte und sollte bspw. jede Woche von vorne beginnen – nur so seid ihr immer nah an den aktuellen Bedürfnissen der Nutzer (und anderen Stakeholdern) dran:
- Schritt 1: Refinement = das Backlog updaten
- Schritt 2: Umsetzungsaufwände erfragen + Vorauswahl + auf Realisierungspaket committen lassen
- Schritt 3: Abnahme und Finalisierung. – Ist ein Item von Umsetzern zurückgekommen / Done? Ist es ohne Probleme und Risiken auf Live integrierbar? (Check der Definition-of-Done)
- Schritt 4: Rollout auf Live-System(en) von fertigen abgenommenen Items und Ankündigung (marketingtechnisch)
Und wieder von vorne.
Nun lasst uns in die Details zu jedem Schritt springen und genauer erläutern, was damit gemeint ist:
Details zu Schritt 1 für Product Owner – das Refinement
Ärmel hochgekrempelt, denn wir sehen uns jetzt mal an, worauf es bei Schritt 1 im Detail eigentlich ankommt:
1a) Durch Gespräche mit und Umfragen in der Zielgruppe (und auch anderen Stakeholdern) wird ermittelt, was deren aktuelle Engpässe und Wünsche sind. Alle Feedbacks und Ideen sammelt Ihr in einem sogenannten Backlog Board.
1b) Was in jedem Zyklus erfolgen muss: bei neuen Einträgen im Backlog den Mehrwert pro Anliegen bestimmen. Viele verwenden die Fibanocci-Zahlen und geben ihnen zusätzlich eine textuelle Bedeutung, wie in der folgenden Grafik als Beispiel gezeigt:
Ihr könnt das aber natürlich auch mit drei Stufen (Niedrig, Mittel, Hoch) angehen, wenn das besser zu Euch passt. Wichtig bei der Bestimmung der richtigen “Höhe”: Vergleicht es mit schon früher eingestuften Anliegen. Wieviel mehr oder weniger Wert hat es für die Zielgruppe im Vergleich zu den früheren Items X und Y?
1c) Frühere Items, die es bisher nicht in die Realisierung geschafft haben, sollen beim Refinement im nächsten Schritt aktualisiert werden: Passt die Mehrwert-Einstufung noch an heutige Bedürfnisse und Umweltbedingungen der Zielgruppe? Vielleicht gibt es neue Gesetze oder neue Komponenten und Erfahrungen aus der Praxis? Als Daumenregel kann man davon ausgehen, dass sich bei ungefähr 50 Items jeden Monat ungefähr 2-3 Items der Wert für die Zielgruppe geändert haben (hoch oder runter).
Mit diesen drei Maßnahmen ist das Backlog wieder up-to-date, was die aktuellen Bedürfnisse der Zielgruppe betrifft. Danach könnt ihr aus der Liste die spannendsten Items (für die Zielgruppe) auswählen und inhaltlich weiter vorbereiten, so dass das Entwicklerteam bzw. ein Fachexperte den Realisierungsaufwand und -Komplexität bewerten kann.
Hierzu nimmst du diese Items und machst daraus Storycards mit mehr Details. Was ist die Userstory? Was sind weitere Anforderungen? Was sind Akzeptanzkriterien, ob die Story vollumfänglich umgesetzt wurde? Kann bei der Vorstellung dieser Storycard der Zuhörer verstehen, worum es geht und was genau gebraucht wird? Was muss noch mit drauf, dass das Team keine Zeit verliert durch Missverständnisse, Rückfragen, usw.?
Dieser Teil, also das Ausformulieren und Vorbereiten der Storycards, erfordert einen großen Anteil Eurer Zeit, daher diesem auch genug davon einräumen! Es schadet auch nicht, wenn es Euch möglich ist, dass jemand anderes einzeln auch mal drüber schaut, ob die Storycard vollständig genug erscheint.
Details zu Schritt 2 für Product Owner – die Umsetzungsvorbereitung
Mit den formulierten Storycards könnt ihr euren Experten (am besten das ganze Team) nun das Thema vorstellen (oder digital besprechen) und darum bitten, eine Einschätzung des Aufwands und der Komplexität vorzunehmen. Hier kommen die Storypoints als Maßstab zum Einsatz.
Das Team einigt sich auf einen validen Wert, mit dem sich alle – oft nach einer kurzen Diskussion – wohl fühlen und zustimmen können. Dieser Wert wird hierbei auch im Vergleich zu früher realisierten Storycards gesehen.
Wurde eine Story X schon mal mit einem Aufwand von 5 Storypoints eingeschätzt, während eine andere Story Y eine Größe von 13 hatte, könnte die aktuelle Story eine 8 sein, weil sie vom Aufwand her gefühlt genau zwischen den beiden anderen liegt.
Wird eine Story mit 40 oder 100 bewertet, gilt sie in der Fachsprache als “episch”, d.h. ein Warnsignal, dass die Story zu groß oder komplex ist, um sie richtig einzuschätzen. Es kann auch sein, dass es viele Unklarheiten und Parameter gibt, die sie so “aufblähen” und “schwammig” werden lassen. Bei diesen Stories gilt: Sie müssen zu einzelnen Items zerteilt und jeweils schärfer beschrieben werden. Es ist die Aufgabe des Product Owners zu entscheiden, wie man diese Stories zerteilen kann, oft mit Impulsen vom Team.
Wurden alle Items vom Team eingeschätzt, kann der Product Owner wieder in Ruhe das Backlog betrachten und nun einen Vorschlag machen, was sinnvollerweise als Nächstes umgesetzt werden sollte – nämlich die Stories, die den größten Nutzen-Aufwand-Verhältnis-Faktor haben. Viel Mehrwert bei wenig Aufwand ist immer zu priorisieren. Im späteren Verlauf werden Stories nach einigen Zyklen in der Regel immer aufwendiger (Zeit/Geld) und bringen immer weniger Mehrwert, sodass irgendwann auch ein Schlussstrich gezogen werden kann, weil das Produkt schon den maximalen Mehrwert für das bisherige Budget enthält.
Mit dieser Vorauswahl tritt der Product Owner, bzw. Product Ownerin ans Team heran und fragt, was das Team aus dieser Vorauswahl im nächsten Zyklus umsetzen möchte und kann. Das Team entscheidet dann, welche Themen es sich im gegebenen Zeitraum zutraut (Summe der Storypoints) und worauf es sich sicher – gemeinsam – auch zeitlich und ressourcentechnisch committen kann – unter Berücksichtigung aller “störender” Faktoren wie operativer Support, andere Meetings, Fortbildungen und Urlaubsausfälle. Mit diesem Commitment geht das Team eine wichtige Verpflichtung ein, auf die sich der PO zu 100% verlässt. Koste es, was es wolle! Zumindest im zeitlichen Sinne.
Mit jedem Zyklus wird das Team besser darin, sich richtig einzuschätzen, sich nicht zu übernehmen und eine machbare Summe an Storypoints pro Zyklusperiode zu kennen. Nach zwei Zyklen zeigt sich eine erste Indizgröße. Beispiel: das Team kann mit 25 Storypoints pro Zyklusperiode inzwischen gut umgehen und die Stories ohne Stress in guter Qualität umsetzen.
Mit dieser Zusage entlassen, wird sich das Team intern beraten und organisieren, wie es ihre Auswahl genau realisieren kann – und zwar zeitlich auch so, dass noch vor der Deadline Reviews und Mängelkorrekturen zuverlässig geschafft werden können. Aber das ist das Ziel des Teams, nicht des POs.
Details zu Schritt 3 für Product Owner – die Abnahme und Finalisierung
Das Team ist nun rechtzeitig mit den Stories durch. Es steht die Abnahme an. In vielen Startups macht der Product Owner die finale Abnahme aus Usersicht, also End-to-End Tests in der letzten Woche einer Zyklusperiode. Es führt aber oftmals zu Stress, Mängel noch in letzter Sekunde vom Team fixen zu lassen. Oft entstehen durch solche Hauruck-Aktionen neue Mängel bei älteren, bereits bestehenden Funktionen, die bei der Abnahme gar nicht auffallen, sondern erst, nachdem es veröffentlicht wurde. Das darf natürlich nie passieren!
Daher sollte das Entwicklerteam unbedingt selbst die Abnahmen und End-to-End-Tests durchführen. Es empfiehlt sich hierbei, einen Testingenieur im Team zu deklarieren, der alle Tests definiert. Aus Erfahrung: Programmierer beispielsweise sind bei dem Thema ungenau und lassen wichtige, sich wiederholende, End-to-End-Tests meistens weg – aus Bequemlichkeit oder aus Zeitdruck. Und schwupps rutscht wieder ein ungesichteter Mangel durch…. es passiert – und zwar garantiert! Also müsst Ihr Euch intern gut organisieren. Das Team muss als Ganzes für die Qualität einstehen und alle Maßnahmen vorsehen, die es für sinnvoll erachtet. Das sollte nicht in der Verantwortung des POs liegen. Der Product Owner kann und sollte Standards setzen, wie Ihr Qualität genau definiert. Was macht Qualität bei euch aus und wie kann sie mindestens auf täglicher Basis gemessen werden?
Definiert Kriterien, die zu Eurem Unternehmen und Euren Werten passen.
Das Team bekommt die Aufgabe, diesen Qualitäts-Wert vor der Deadline zu erfüllen und gute Testreports vorzulegen, die dem PO nachweislich aufzeigen, dass alles für euch Relevante geprüft wurde. Dieser Report ist bei jedem Zyklus enorm wichtig und sollte auch archiviert werden. So kann man, wenn nach der Veröffentlichung Mängel entdeckt werden, nachvollziehen, warum der Fehler durchgerutscht ist.
Details zu Schritt 4 für Product Owner – die Veröffentlichung
Im letzten Schritt ist der Product Owner dafür verantwortlich, dass der neu-realisierte Mehrwert auch wirklich beim Nutzer landet.
Einerseits muss er oder sie seine Expertinnen und Experten beauftragen, diese neuen Features auf alle Endgeräte der User auszurollen. Das kann bei großer Anzahl Monate dauern. Bei zentralen Systemen, wie Webanwendungen auf Servern, ist das einfacher, erfordert aber andere Maßnahmen, bspw. im Rahmen von nächtlichen Wartungszyklen, die durchzuführen sind. Hierbei darf es aber zu keinen Fehlern kommen, da man sonst einen Komplettausfall riskiert. Ein Zurückspielen auf ältere Versionen / Einspielen von Backups sollte immer möglich sein. Der PO sollte darauf achten, dass dies zu jedem Zeitpunkt möglich ist.
Und final muss der neue Mehrwert auch noch an die Zielgruppe kommuniziert werden, bspw. mit Marketing, Mailverteilern, Presse, …
Das Produkt ist jetzt wertvoller geworden, weil es nun genau die Funktionen erhalten hat, die im Schritt 1 bei der Zielgruppe als am dringendsten beurteilt wurden und bietet jetzt neue Funktionen, die den Alltag der Zielgruppe angenehmer machen.
Juhu, geschafft! Wir haben jetzt einen Zyklus komplett durchgespielt!
Und nach der Veröffentlichung ist vor der Veröffentlichung: Der neue Zyklus beginnt wieder bei Schritt 1, und so geht es kontinuierlich weiter.
Wer so vorgeht, sorgt dafür, dass das Produkt für die Zielgruppe Monat für Monat immer maximal wertvoller wird, und damit ist ein Erfolg nicht mehr verhinderbar 😉
Fazit
Im heutigen Artikel sind wir tief in die Arbeit des Product Owners eingetaucht und haben jeden einzelnen Schritt eines PO “Zyklus” im Detail beleuchtet. Wer sich daran orientiert, sorgt dafür, dass das Produkt jeden Monat so viel besser und wertvoller wird, wie es aktuell für die Zielgruppe nötig und möglich ist.
Ihr seht – trivial ist die Arbeit des Product Owners sicher nicht. Aber mit etwas Routine und zwei, drei Zyklen seid Ihr bald gut drin und es macht einfach Spaß und bringt Motivation zu sehen, wie Monat für Monat sehr schnell spannende Features von den Nutzern direkt genutzt werden und die Kunden das Produkt und Euch als Team immer mehr lieben.
Ausblick
Im nächsten und letzten Artikel dieser vierteiligen Serie erfährst du, worauf es bei der Definition von Akzeptanzkriterien und bei der Abnahme ankommt und wo oft Fehler bei der Einschätzung gemacht werden. Ihr dürft also gespannt sein!
Kleiner Tipp zum Schluss: Um nichts zu verpassen und euren Erfolg zu sichern, abonniert einfach diesen Kanal rechts in der Seitenleiste.