Vor ein paar Tagen bin ich auf den Blog-Artikel „Agile Mythen: User Stories schreiben ist Product Owner Aufgabe“ von Anna Rudat gestoßen. Als Enthusiast der agilen Softwareentwicklung und Product Owner Veteran, wurde ich mit der Meinung, dass allein der Product Owner für das Schreiben von User Stories verantwortlich ist, schon häufig konfrontiert. Nachdem ich den Artikel gelesen hatte, erinnerte ich mich an meinen letzten Einsatz als Product Owner und wie mein Team und ich uns in dieser Hinsicht geschlagen haben.

Product Backlog-Pflege: der Full-Time Job

Wie Frau Rudat in ihrem Artikel schreibt, existiert häufig die falsche Annahme, dass nur der Product Owner Product Backlog Einträge schreiben, das Backlog pflegen und priorisieren darf. Betrachtet man jedoch den Scrum Guide, ist hier nicht von einer reinen Schreibtischtätigkeit mit stumpfer Backlog-Pflege die Rede. Die genannten Aufgaben sind:

  • Product Backlog‐Einträge klar zu formulieren
  • Die Einträge im Product Backlog so zu sortieren, dass Ziele und Missionen optimal erreicht werden können
  • Den Wert der Arbeit zu optimieren, die das Entwicklungsteam erledigt
  • Das Sicherstellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie zeigt, woran das Scrum Team als nächstes arbeiten wird
  • Sicherzustellen, dass das Entwicklungsteam die Product Backlog‐Einträge im erforderlichen Maße versteht

Der Product Owner muss vielmehr ständig den Blick für die Ziele und Missionen der Produktentwicklung haben und die Backlog-Einträge entsprechend ihres Beitrages zur Erreichung dieser Ziele priorisieren. Des Weiteren muss er sein Team genau kennen und wissen, wie die Backlog Einträge optimal formuliert werden müssen, damit das Team sie effektiv und ohne viele Nachfragen umsetzen kann.

Nach meiner Erfahrung ist die Pflege des Product Backlogs daher auch ein Full-Time Job. Das kommt aber eher weniger daher, dass man die gesamte Zeit nur stupide Backlog Einträge formuliert. Betrachtet man die Aufgaben des Product Owners genauer, wird schnell klar, dass er als Mediator zwischen den Anforderungen seiner Vision und dem Umsetzungsteam funktionieren muss. Nur wenn er hier gute Arbeit leistet, kann er die Backlog Einträge entsprechend formulieren, eine geeignete Priorisierung des Product Backlogs erreichen und seine Vision effektiv an alle Beteiligten vermitteln.

Mein erfolgreichstes Backlog Refinement

Am deutlichsten wurde mir meine Rolle als Product Owner nach meinem erfolgreichsten Backlog Refinement Termin. Innerhalb dieses Termins flossen sehr viele Backlog-Einträge ein, sowohl vom Team als auch von mir eingebracht. Vor dem Refinement war es mir nicht möglich einen geeigneten Schnitt für alle Einträge zu entwickeln. Eine Besprechung der Einträge innerhalb des Refinements sah ich daher als sinnlos an. Stattdessen entwickelte ich eine Mind Map mit den kurzfristigen Zielen, die in einem bestimmten Zeitraum erreicht werden mussten. Innerhalb des Refinements entwickelte mein Team gemeinsam mit mir als Product Owner den richtigen Schnitt der Backlog-Einträge. Auf Basis der Ergebnisse aus diesem Termin konnte ich die Einträge dann entsprechend ausformulieren und im Product Backlog priorisieren. Insgesamt verbrachte ich im Vorfeld mehrere Tage mit Absprachen zu den Themen, methodischer Vorgehensweise im Refinement-Termin und agiler Ansätze. Die eigentliche Arbeit bestand in der Vorbereitung des Termins, nicht in der Ausarbeitung von Backlog-Einträgen.

Gemeinsame Entwicklung des Backlogs

Gemeinsame Entwicklung des Backlogs

Das anschließende Sprint Planning war dann nur noch eine Formsache. Das Team hatte unseren Weg mitentwickelt und stand hinter der Planung. Wir konnten das Sprint Planning sehr schnell abschließen und jeder wusste, was zu tun war. Belohnt wurde der Aufwand dann in der Retrospektive mit sehr positiven Erfahrungen hinsichtlich der Sprint-Vorbereitung und seiner Durchführung. In der Reflexion fällt es mir nicht schwer dieses Refinement als mein erfolgreichstes zu bezeichnen.

Die Sache mit den User Stories

Ein Punkt der mich hinsichtlich der Fokussierung auf User Stories ärgert ist, dass oft versucht wird sie auf Biegen und Brechen in ein User Story-Korsett zu zwängen. Sicherlich liegt der Fokus in der agilen Softwareentwicklung auf Produkten, die für Benutzer entwickelt werden. Daher liegt es nahe Anforderungen in einem Format zu dokumentieren, welches die Interaktion des Benutzers mit dem System beschreiben. Trotzdem werde ich nicht müde zu erwähnen, dass der Scrum Guide nie explizit von User Stories als einzige Inkarnation eines Backlog-Eintrags spricht. Es geht immer allgemein um Einträge die folgende Charakteristiken aufweisen sollen:

  • Beschreibung
  • Reihenfolge
  • Schätzung
  • Wert
User Story Format

User Story Format

Mir läuft jedesmal ein Schauer über den Rücken, wenn ich „User Stories“ im Format „Ich als Product Owner möchte, dass alle Verbindungen der Anwendung mit dem Protokoll HTTPS aufgebaut werden“ sehe. Gerade bei technischen Anforderungen, die sicherlich relevant, aber für den Benutzer direkt nicht interessant sind, wird versucht sie in einem User Story Format in das Product Backlog einzubringen. Wieso nicht einfach mal als eine einfache Aufgabe?

Links

Agile Mythen: User Stories schreiben ist Product Owner Aufgabe von Anna Rudat

Der Scrum Guide

3C Methode