So etwa 2014/2015 war ich Projektleiter und Scrum-Master in einem relativ großen Projekt in Bayern. Du kennst ja den Spruch „Manchmal gewinnt man, manchmal lernt man…“ – das war definitiv ein Projekt zum Lernen. In dem Projekt gab es eine ganze Menge „Lernerfolge“ – Wir hatten zum Beispiel das Phänomen, dass die Planungsmeetings viel zu lange dauerten und sehr ermüdend waren. Wir diskutierten und diskutierten und es nahm kein Ende…Woran lag das? Wir hatten doch die Userstories alle in langen Workshops zu Beginn des Projektes besprochen und geschätzt?…
Wann hatten wir das gemacht? Zu Beginn des Projekte – Du hast richtig gehört…
Eins der wesentlichen Elemente ist ja das Lernen auf dem Weg…was wir damals in dem Projekt gemacht hatten, war allerdings ein verkapptes Wasserfallprojekt mit Scrum-Elementen zu überlagern. Wir hatten zu allem Überfluss noch verschiedene externe Partner in dem Projekt, die jeweils eine eigene Agenda hatten. Alles keine guten Voraussetzungen für ein gelungenes Projekt…
Das Verständnis, wie wir im Projekt vorgehen wollten, war fundamental anders und es äußerte sich unter anderem auch in einem besonderen Meeting – dem Refinement…und das innige Verhältnis, dass ein Product Owner zu seinem Backlog aufbauen sollte…oder in dem Falle eben nicht…
Wenn Du Product Owner oder Product Ownerin bist, bist Du diejenige Person, die für die Betreuung bzw. das Management des Product Backlogs verantwortlich ist – so steht es jedenfalls sinngemäß im Scrum Guide. Als Product Owner bis Du der – oder diejenige – die den Wert des Produktes maximiert. Oder anders ausgedrückt: der die Arbeitszeit des Dev.-Teams zu einem lohnenden Investment für die Company macht.
Wir haben ja bereits über die im Scrum-Guide fest terminierten Events gesprochen – Am Anfang kommt das Sprint-Planungsmeeting, dann täglich die Daily Standups, am Ende dann das Sprint-Review und die Sprint Retrospektive.
Aber ein Meeting hat keine feste Agenda und keinen angestammten Platz und wird daher gerne vergessen oder verdrängt. Das Refinement Meeting (früher auch „Grooming“ genannt). Dabei kann das Refinement Dein besonderer Freund sein: Das Refinement bewahrt Dich davor, das Team auf die falsche Strecke zu schicken. Das Refinement gibt Dir die Möglichkeit stolz auf Dein Backlog zu sein und laut auszurufen: „Seht her, was wir hier cooles bauen und welchen Nutzen wir hier für unsere Kunden schaffen!!““
Hört sich gut an oder?
Stell Dir das mal vor –
Also reden wir in der heutigen Folge mal über das Refinement: – wozu dient das überhaupt?
Während sich die anderen genannten Meetings auf den laufenden oder kommenden Sprint konzentrieren, blickt das Refinement über den Tellerrand hinaus auf die Dinge, die später kommen werden.
Es dient dazu das Backlog zu sichten, zu verstehen und aufzuräumen. Denn nur, wenn Du als Product Owner und als Dev-Team auch verstanden hast, was in deinem Backlog steht, kannst du Entscheidungen treffen.
Und Entscheidungen sind essentiell, wenn es um die Optimierung des Wertes des Produkts bzw. der Arbeitsergebnisse des Teams geht. Nur durch Entscheidungen, die das WAS und auch das WIE der Anforderungen betreffen, ist es überhaupt möglich einen Wert zu erhöhen bzw. überhaupt einen Wert zu schaffen. Ohne solche Entscheidungen ist der Wert, den die Arbeit des Teams letztlich hat, vom Zufall abhängig und so mit Sicherheit auch nicht optimal.
Denn es muss klar sein. Das Team arbeitet immer gleich (gut), sie kosten auch immer gleich viel… nur an was sie arbeiten, bestimmt letztlich den Wert der Arbeit (also das „outcome“ oder den Nutzen für den Kunden und damit für Deine Firma). Die oft geforderte „Performance“ eines Teams – also ein möglichst großer „output“ – ist nicht entscheidend für den Wert der Arbeit.
Doch wie erhöht man nun den Wert der Arbeit?
Wie oft und wann sollen die Refinements durchgeführt werden?
Nun – es ist sicherlich gut, wenn es – wie in den anderen etablierten Events auch – einen festen Termin gibt, an den sich das Team gewöhnen kann. Aber es muss auch möglich sein, dass der Product Owner sozusagen zu „ad-hoc Refinements“ einladen kann, wenn etwas besonders Dringendes besprochen werden soll. Du wirst sicherlich mit deinem Team einen guten Weg finden.
Wichtig ist, dass Refinements auf jeden Fall innerhalb des Sprints durchgeführt werden und das Du sie nutzt, um deinem Backlog zu zeigen, dass Du dich darum kümmerst…
Letztlich solltest Du als Product Owner dein Backog lieben…und das Backlog gibt dir durchaus Signale, wenn es etwas Zuwendung braucht…hier kommen ein paar:
Signal Nr. 1: Mein Backlog hat Übergewicht...Größer ist nicht besser.
Wenn Dein Backlog vollgestopft ist, wie eine Mastgans kurz vor Weihnachten, dann fühlt es sich nicht gut…lass es entschlacken und gönne ihm eine Abmagerungskur:
Das Backlog ist ein lebendes Artefakt, wir lernen aus jedem Sprint und in jedem Sprint-Review generieren wir neue Ideen, die das Produkt besser machen. Wenn im Backlog alte Ideen vor sich hin gammeln, sollten diese gelöscht werden. Denn Ideen oder Anforderungen, die eventuell seit Beginn des Projekts aus irgendeinem Stakehoder-Workshop da eingeflossen sind.
Ideen, die wahrscheinlich von der Wirklichkeit längst überholt worden sind oder Anforderungen nach denen keiner jemals wieder nachgefragt hat…haben höchstwahrscheinlich keinen großen Wert, denn sonst würde jemand danach fragen!
Also mache es Dir zu Regel, dass alles, was seit einem halben Jahr oder länger im Backlog liegt (und keine hohe Prio bekommen hat) gelöscht wird – oder das diese Userstories oder Anforderungen zumindest potentielle Streichkandidaten sind. (Vielleicht liegt in deinem Kontext die Schwelle auch bei drei Monaten oder darunter oder vielleicht auch darüber – die Entscheidung überlasse ich natürlich Dir…). Hier könntest du zum Beispiel im Refinement drüber sprechen.
Wenn Ihr euch nicht sicher seid, könnt ihr vielversprechende Ideen ja nochmal ins Bewusstsein hieven, in dem ihr das nochmal vor dem jetzigen Stand des Projekts diskutiert.
Signal Nr. 2: Mein Backlog – das fremde Wesen:…Unbekannte und unklare Stories fallen durch!
Wenn Du in deinem Backlog Stories oder Anforderungen findest, und beim Durchlesen nur noch denkst: Hä? was soll das denn sein? Dann läuft was falsch…
Oft ist es so, dass du als Product Owner gar nicht selbst alle Anforderungen ins Backlog schreibst, sondern diese von allen möglichen (und unmöglichen) Seiten da rein kommen…Wenn das bei Dir so ist, achte insbesondere auf die Definition of Ready: Oft haben sich auch „Formulare“ oder Templates bewährt, die du für die verschiedenen Ticketarten gestalten kannst (wie z.B. Userstory, Defect, Investigation): Bei einem Fehler kannst Du z.B. folgende Informationen einfordern:
- Wie kann man den Fehler reproduzieren? (Schritt für Schritt und welche Voreinstellungen wurden gemacht, bzw. welches Systemsetting liegt beim Auftreten des Fehlers vor?)
- Was ist das erwartete Ergebnis, wenn man die Schritte nacheinander durchführt?
- Was ist im Gegensatz dazu das aktuelle Ergebnis?
Und bei einer Anforderung solltest Du auf das User-Story Format und die Akzeptanzkriterien achten…Nochmal zur Erinnerung…Ne Userstory enthält 3 Bestandteile – Wer braucht es? ,, was wird gebraucht? Und wozu wird es gebraucht (Nutzen)?
Signal Nr. 3: Die Unwichtigen sind die Detaillierten...
In einem guten Backlog sind die hoch priorisieren Items auch diejenigen, die am besten detailliert beschrieben sind. Diese stehen oben und sind dazu noch so klein, dass sie direkt im nächsten Sprint geplant werden können. Du kennst vielleicht die Eigenschaften eines guten Backlogs: DEEP – ein Akronym – natürlich kommt das aus dem englischen: (D: angemessen detailliert, E: = Emergent, also sich entwickelnd E: Estimated – also geschätzt und P: Priorisiert).
und was bedeutet das jetzt in der Praxis?
Detaillieren ist schließlich Arbeit – Wenn ihr Euch mit unwichtigen Dingen beschäftigt, die in den nächsten 6 Monaten sowieso nicht umgesetzt werden, dann vergeudet ihr wertvolle Zeit, die euch bei den wichtigen Themen dann fehlt – Du kannst das mit den Opportunitätskosten vergleichen, die bei der BWL ja oft genannt werden. Wenn Du Zeit oder Geld in ein Thema investierst, fehlt dir genau diese Zeit und das Geld bei einem anderen Thema. Daher solltest Du immer darauf achten welche Themen die aktuell wichtigen sind. Diese verdienen jetzt auch die volle Aufmerksamkeit. Die anderen Probleme kannst Du dann lösen, wenn sie da sind…
Signal Nr. 4: Abgekoppelt von der Product-Vision – Habt ihr überhaupt eine Produkt Vision?
Hier kommen wir zu einem Kernthema – insbesondere wenn es bei Euch vielleicht schon zu Unzufriedenheit gekommen ist und ihr gerade Euer agiles Vorgehen mit Scrum in Frage stellt:
- Habt ihr eigentlich eine Produktvision?
- Baut ihr eigentlich gerade ein Produkt?
- oder macht ihr etwas anderes?
Scrum kann seine Stärken besonders dann ausspielen, wenn es darum geht ein Produkt zu entwickeln – oder weiter zu entwickeln. Kontinuierliche Änderungen an einem bestehenden System – im Sinne von Wartung oder Fehlerbehebung – steht gegebenenfalls in Konflikt mit der eher starren Planung eines Sprints. Hier könntet ihr überlegen, ob nicht vielleicht eine Anpassung des Vorgehens in Richtung Kanban sinnvoll ist.
Wenn ihr allerdings eine Produkt-Vision habt, dann ist ja alles ok – dann sollten allerdings die Userstories auch dazu passen…
Backlog Items, die nicht zur Produktvision passen, lenken im besten Fall nur ab. Im schlechteren Fall sorgen sie dafür, dass ihr Eure Vision nicht erfüllen könnt. Daher – und hier bist Du als PO gefragt – Behalte die Vision im Auge und lass dich nicht abbringen. Viele Wege führen nach Rom, aber wenn ihr in Warschau rauskommt, ist was falsch gelaufen…
Frage Dich, wenn du im Backlog Stories oder Anforderungen findest, einfach – bringt mich das der Produkt-Vision näher? Wenn Du die Frage mit „ja“ beantworten kannst, gehe weiter. Wenn nicht – frage Dich – „warum steht das hier?“ – Gib dem Item noch eine Chance – aber nur eine…falls Du auch nach intensivem Nachdenken nichts dazu einfällt kicke das Ticket aus dem Backlog. Wahrscheinlich fragt sowieso nie wieder jemand danach. Alle Backlog-Items, bei denen Du die Frage mit „ja“ beantwortet hast, kannst Du dann im Refinement mit dem Team diskutieren, so dass der Nutzen und die Größe der Story jedem klar ist…
Signal Nr. 5: Nur Du arbeitest am Backlog.
Du bist zwar verantwortlich für den Wert des Produkts, das bedeutet aber nicht, dass nur Du alleine im Backlog arbeiten darfst. Nach dem Scrum-Guide ist das Backlog Refinement ein andauernder Prozess, in dem Du (als PO) zusammen mit dem Team an den Details für die Anforderungen arbeitest.
Bitte interpretiere das nicht so, dass nur Du als PO an den Stories arbeiten darfst. Gib dem Team die Möglichkeit, selbst Ideen aufzubringen (- solltest Du Scrum – Master oder Team Mitglied sein, fordere diese Möglichkeiten für Dich oder das Team ein). Ihr verschenkt eine Menge an Kreativität im Team, wenn ihr hier zu streng seid. Oder ihr riskiert eine Überforderung des PO – was definitiv ein Risiko ist. Schütze Dich selbst und gib ab…auch wenn das hier von aussen über den Podcast leicht gesagt ist und ich weiß, dass die Umstände oft schwierig sind. Bedenke, es geht nie um den Prozess um des Prozesses willen – es geht um die Ergebnisse und den Wert der Arbeit. Wenn der Prozess hier nicht unterstützt, ist etwas am Prozess falsch und nicht an Dir!
Fazit: Denke spätestens bei Deiner Arbeit am Backlog an die Macht von Pareto! Pareto, das ist der italienische Wissenschaftler und Ökonom, der das 80:20 Prinzip entdeckt hat, welches auch nach ihm benannt wurde. Und das sagt: Du brauchst 20 % des Aufwands um 80% des Nutzens zu erreichen…Wenn Du also als Product Owner in der Lage bist, die Anforderungen, die 80% des Kundennutzens erzielen rauszufiltern, dann hast Du deinen Job richtig verstanden und super gemacht. Dann entlastest Du das Team und dich selbst von 80% wahrscheinlich unnötiger Arbeit.
Lass Dir das mal auf der Zunge zergehen….das ist angenehm, wie ein wunderbar cremiges italienisches Eis in der Sonne….
Mmhhh….
Mit dem Bild und dem wohligen Geschmack auf der Zunge lass ich dich nun zurück…
Und wünsche Dir noch einen schönen Tag oder Abend…je nachdem, wann Du diesen Podcast hörst.
Tschüß – Dein agilophiler Frank
Diese 5 Signale sind inspiriert durch den Artikel: „5 signs your product backlog is in need of some love – published via linked-in by Dan Churchill, May 5, 2019