Lesezeit: 3 Minuten
Inhalt
Leider ist Agilität alleine kein Patentrezept für zufriedene Kunden. Eine der Hauptursachen für ein unbefriedigendes Ergebnis ist eine unzureichenden Sprintvorbereitung durch den Product Owner. Denn wie überall bestimmt die Qualität des Inputs wesentlich die Qualität des Outputs bzw. in diesem Fall des Outcomes.
Sind die Entwicklungsergebnisse trotz agiler Vorgehensweise nicht zufriedenstellend oder beschweren sich die Entwickler über die Arbeit des Product Owners, so sollte eine Verbesserung der Sprintvorbereitung durch den Product Owner zu erheblich besseren Entwicklungsergebnissen führen.
Drei Fragen stehen dabei im Fokus:
- Wurde ein sinnvolles Sprint Ziel definiert? Denn dieses ist die Grundlage für die Priorisierung der User Stories.
- Sind die richtigen User Stories ausgewählt und wurden alle Abhängigkeiten bei der Planung dieser User Stories berücksichtigt? Versteht jeder Entwickler den Sinn der gewählten User Stories?
- Werden Qualitätsaspekte und Risiken ausreichend berücksichtigt?
1. Ein gutes Sprinziel definieren
2. User Stories für den Sprint vorbereiten und passend auswählen
Der Product Owner ist im Lead wenn es um die Frage geht, welche Product Backlog Items in den Sprint genommen werden und warum. Denn der PO legt die Priorisierung meist durch das Festlegen einer Reihenfolge der Product Backlog Items fest. Hat der Product Owner sich hierzu vorher die richtigen Gedanken gemacht und das Backlog Refinement ernst genommen, geht es im Sprint-Planungsmeeting deutlich effektiver voran und die Entwickler sind anschließend wesentlich motivierter bei der Umsetzung.
Product Backlog Qualität
Für ein gutes Product Backlog empfiehlt sich, dieses Backlog entsprechend dem DEEP Ansatz von Roman Pichler zu pflegen:
- D –
Detaillierungsgrad: Je näher an der Umsetzung desto detaillierter - E –
Estimated: Mit entsprechend grober bzw. feiner Aufwandsschätzung durch das Entwicklungsteam - E –
Emergent: Ständig aktualisiert insbesondere auch ausgemistet - P –
Prioritised: Sortiert nach Wichtigkeit bzw nach Nähe zur Umsetzung/Dringlichkeit
Die einzelnen Einträge des Product Backlogs sollten in den Backlog Refinement Meetings fortlaufend gemeinsam mit den jeweils betroffenen Entwicklern konkretisiert und aktualisiert werden. Hält der Product Owner sein Product Backlog entsprechend den DEEP Kriterien aktuell, ist das bereits die halbe Miete zu einer guten Sprint Vorbereitung.
User Story Qualität
Die User Stories, die in der Sprintplanung ausgewählt werden, müssen in guter Qualität vorliegen und im Sprint umsetzbar sein.
- Eine Best Practice zur Qualität der User Stories sind die INVEST Kriterien von Bill Wake. Diese zu beherzigen hilft sehr dabei, falsche oder qualitativ unzureichende Umsetzungen zu vermeiden.
- Bevor eine User Story für einen Sprint ausgewählt werden kann, muss diese zeitlich innerhalb eines Sprints umsetzbar sein. Das dazu häufig notwendige Story Splitting sollte ebenfalls bereits im Backlog Refinement Prozess stattfinden. Es benötigt etwas Kreativität, dabei kleinere User Stories zu finden, die ebenfalls den INVEST Kriterien entsprechen.
Im Sprint Planning werden genau die Backlog Items aus dem Product Backlog in den Sprint Backlog genommen, die das Erreichen des Sprint Ziels ermöglichen bzw. unterstützen.
3. Berücksichtigung von Risiken, Qualität und Rahmenbedingungen
Agilität bedeutet, möglichst in jeder Iteration die Software so zu erweitern bzw. zu verbessern, dass deren Nutzen für Stakeholder und Anwender fühlbar steigt. Das kann leicht dazu verleiten, alle jene Themen vor sich herzuschieben, die nicht zu diesem Prozessziel passen.
Risiken
Komplexität bedeutet automatisch auch Risiken bei der Umsetzung. Agile Vorgehensweisen adressieren diese Risiken besonders gut durch die kurzen Iterationszyklen. Allerdings reicht das nicht, wenn kritische und aufwändige Themen erst spät in der Umsetzung angepackt werden. Im klassischen Projektmanagement ist der zeitnahe, proaktive Umgang mit Risiken nicht umsonst eine zentrale Aufgabe der Projektleitung. Im agilen Umfeld kommt es leider oft darauf an, ob eines oder mehrere der Teammitglieder erfahren genug sind und automatisch ein Auge für Risiken haben.
Empfehlenswert ist deshalb auch in agilen Entwicklungen, Risiken explizit zu identifizieren und bei Bedarf möglichst früh nach dem Bekanntwerden anzugehen.
Technische Schulden
Eines der 12 Prinzipien im Agilen Manifest ist “Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität”. Nur so lassen sich auch noch nach einigen Monaten oder gar einigen Jahren neue User Stories schnell und in hoher Qualität umsetzen. Das gilt besonders, wenn Teams sich in Richtung DevOps entwickeln möchten. DevOps ist nur bei extrem hoher technische Qualität möglich. Schon beim Arbeiten nach Scrum sollten deshalb mit Blick auf DevOps technische Schulden so schnell wie möglich beseitigt werden. Ob dazu eigene Technical Stories sinnvoll sind, darüber wird viel diskutiert. Einerseits ließe sich eine Technical Story in eine User Story mit dem evtl. etwas weiter her geholtem Nutzen umformulieren, andererseits könnten diese Arbeiten einfach “nebenher” mit den eigentlichen User Stories erledigt werden – zu Lasten der Umsetzungsgeschwindigkeit. Andere Teams reservieren dazu einfach einen bestimmten Zeitanteil in jedem Sprint. Mehr zum Thema Technische Stories liefert der Artikel Why technical user stories are bad.
Jedenfalls ist es im Interesse jedes Product Owners, den Entwicklern einen ausreichenden zeitlichen Spielraum für das Erreichen und das Erhalten einer hohen Softwarequalität einzuräumen. Andernfalls geht irgendwann nichts mehr voran und auf allen Seiten wächst der Frust.
Qualitätsanforderungen und Rahmenbedingungen
Viele dieser „Nicht-Funktionalen Anforderungen“ beziehen sich auf die gesamte Applikation, z.Bsp. Usability, Performance oder die Verfügbarkeit auf bestimmten Geräten oder Browserversionen. Deshalb passen diese Anforderungen oft nicht in eine bestimmte User Story. Teilweise stehen solche Anforderungen deshalb auf einer separaten Tafel im Besprechungsraum. Oder sie werden in den Akzeptanzkriterien einzelner User Stories explizit gemacht.
Und manchmal kommen diese Themen leider erst spät zum Vorschein. Denn viele dieser Anforderungen werden von den Anwendern als so selbstverständlich angesehen, dass sie gar nicht explizit von Anwendern und Stakeholdern ausgesprochen werden. Hier ist es also wichtig früh nachzuhaken!
Fazit
Leider wird in agilen Projekten die Rolle des Anforderungsmanagers, in Scrum ist das der “Product Owner”, zu oft nicht optimal wahrgenommen. Und das, obwohl agile Methoden auf das Verstehen der Anforderungen und damit im Ergebnis auf das Erzeugen eines maximalen Nutzens ein besonderen Fokus legen. Ein PO bzw. das Teilteam, das diese Rolle übernimmt, sollte für diese Aufgabe gut qualifiziert sein und über ausreichend Kapazität verfügen. Idealerweise sollte ein Product Owner sich im wesentlichen auf eine Produkt- bzw. Projektentwicklung konzentrieren und ein vollwertiger Teil des Entwicklungsteams sein.
Gerade wenn zu wenige Softwareentwickler verfügbar sind ist es umso wichtiger, dass die vorhandenen Entwickler möglichst effektiv arbeiten können. Nur wenn der Input durch den Product Owner optimal vorbereitet ist, kann ein gutes Team in jeder Iteration die bestmöglichen Ergebnisse im Sinne der Stakeholder und Anwender liefern. Es lohnt sich in der Regel, die aktuelle Situation bezüglich Backlog Qualität und Sprintplanung zu prüfen und gegebenenfalls nachzusteuern.
