„Eine User-Story muss immer das Format -Als User möchte ich Funktion, um Nutzen- folgen“ und „Jedes Backlog Item im Product Backlog muss als User Story verfasst werden!“. Diese und andere Mythen halten sich speziell unter Anfängern gern hartnäckig.
Doch ist dem wirklich so? Und müssen Backlog Items, die keinen Nutzervorteil erzeugen, auch diesem Muster folgen? Dürfen Backlog Items ohne direkten Kundennutzen überhaupt erstellt werden? Oder muss das Team diese unter der Hand machen oder darf diese gleich partout nicht bearbeiten?
Um dieser Fragestellung etwas tiefer auf den Grund zu gehen, würde ich gerne an einer ganz anderen Stelle der Geschichte einsteigen.
Warum überhaupt User Stories?
User Story als Kommunikationstool
„The lineup consisted simply of six hydrocoptic marzelvanes, so fitted to the ambifacient lunar waneshaft that sidefumbling was effectively prevented. The main winding was of the normal lotus o-deltoid type placed in panendermic semiboloid slots of the stator, every seventh conductor being connected by a non-reversible tremie pipe to the differential girdlespring on the ‘up’ end of the grammeters.“ – Technical Jargon Overload on Youtube
Wenn ein Team mit Kunden interagieren möchte und seine Pläne teilt, ist ein Hintergrund davon Feedback zum Plan und zu den kommenden Änderungen zu bekommen. Verwendet ein solches Team Worte und Fachbegriffe die nicht verständlich sind, ist eine Kommunikation schwierig bis unmöglich.
Aus diesem Zweck ist eine User Story einfach gehalten und beschäftigt sich mit dem Mehrwert aus Benutzersicht.
Über technische Updates, Backendverbesserungen und das Aufräumen von technischen Schulden spricht ein Team eher selten mit dem Endnutzer. In diesen Fällen ist das Format also unnötig.
User Story als Reflexionstool
Eine Userstory kann helfen eine Anforderung an ein Produkt oder ein größeres Stück Arbeit als Team zu reflektieren und sich nochmal zu vergewissern, ob man den Wert wirklich verstanden hat.
Prinzipiell „verbiete“ ich hier meinem Team im Lückentext der obigen User Story für den „User“ die Wörter „User, Benutzer, Entwickler, … einzusetzen“. Der Gedanke hinter diesem Verbot ist nicht, innovativer zu denken und Synonyme für diese Gruppen zu finden, sondern sich noch einmal ganz anders mit den Anforderungen auseinanderzusetzen
Als Entwickler möchte ich ein Java Upgrade von Java 9 auf Java 14 vornehmen, um mit einer aktuellen Version zu arbeiten.
Strikt gesehen hat ein Product Owner in dieser Situation keine andere Wahl als ein solches Item nach unten zu priorisieren oder nie umzusetzen. Es erzeugt für den „Entwickler“ einen Wert. Und zwar den der Freude, mit einer neuen Version zu arbeiten.
Eine andere Version könnte ungefähr so klingen:
Für den Anforderer wollen wir ein Java Update vornehmen, um auch in Zukunft wartbaren Code zu haben, Sicherheitslücken vorzubeugen und Performancevorteile nutzen zu können.
Gerade das jüngste Beispiel rund um „Log4J“ vor der selbst das BSI warnte, ist diese Userstory nicht weit hergeholt. Auch in einer Aufrüstung, in Refactoring und im Nachziehen von Versionen steckt ein Mehrwert für den Endnutzer. Stellen wir uns vor, dass es einem Team aufgrund eines Updates gelingt, 1 % schneller/besser zu arbeiten als zuvor. Für dieses Upgrade braucht eine Person jedoch einen kompletten 2-wöchigen Sprint. Sollte ich eine solche Story umsetzen? Rein rechnerisch würde sich bei einem 7-Personen Team eine Amortisation von knapp 15 Sprints, also 30 Wochen ergeben. Zusammen mit anderen Refactorings und dem Vermeiden von technischen Schulden ergibt sich schnell ein Geschwindigkeitsboost, welcher merklich auch dem Product Owner zugutekommt und die Zufriedenheit im ganzen Team steigert.
Also User Stories oder doch nicht?
Ob ein Team das Format der Userstories und dessen Vorteile auch für rein technische, nicht-funktionsgetriebene Themen nutzen möchte, ist natürlich jedem Team selbst überlassen. Ich denke, ein offener Umgang mit diesen Themen sollte in einem guten Scrum Team unbedingt gegeben sein. „Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.“ Achtes Prinzip des agilen Manifestes.
Die Entwickler in einem Team haben die Verantwortung, die innere (vom Kunden nicht direkt sichtbare) Qualität eines Produktes hochzuhalten. Sei es durch Testautomatisierung oder eben das regelmäßige Aktualisieren genutzter Bibliotheken. Oftmals müssen Entwickler dafür kämpfen, vielleicht auch ein Stück weit im Refactoring Prozess „gegen“ den Product Owner. Der ScrumMaster des Teams kann dabei helfen, das Team hierzu zu ermutigen und das Gleichgewicht aus neuen Funktionen und Qualität in der Waage zu halten. Das Format der User Story kann helfen, diesen Konflikt etwas einfacher zu gestalten und dem Product Owner den Vorteil der technischen Themen begreiflicher zu machen.
Ertrinkt dein Team in technischen Schulden oder hast du das entgegengesetzte Problem: Du siehst nur noch goldene Wasserhähne? Ruf doch mal kurz durch. Bestimmt können wir dir einen Hinweis in die richtige Richtung geben.