Die Magie des „damit“ – und warum jede User Story eins braucht

Eine Scrum User Story besteht aus drei Teilen: Welche Person/Rolle möchte etwas haben um/damit ein Nutzen/Vorteil eintritt. Sehr oft wird dieser letzte Teil einer Story weggelassen und sie besteht im Wesentlichen nur aus der Beschreibung dessen, was gemacht werden soll.

· 4 Min Lesezeit

Unsere Erfahrung zeigt, dass eine Beschäftigung mit dem „damit“ ein unheimlicher Gewinn für die Arbeit an der Aufgabe ist. Wir möchten jede Person im Scrum-Prozess motivieren, diesem Aspekt Aufmerksamkeit zukommen zu lassen. Es lohnt sich.

Das „damit“ soll dazu dienen, den Nutzen der Aufgabe für den oder die Stakeholder zu verdeutlichen. Gekoppelt damit ist aber auch ein weiterer Effekt – es entsteht eine Transparenz zum Ziel der Entwicklung. Darauf geht dieser kleine Artikel ein.

Das Tun der Menschen kann man betrachten als eine Erfüllung eines Bedürfnisses mit einer Strategie. Z. B. „lass uns zum Chinesen zum Essen gehen.“ Hier steht die Strategie sichtbar – wir gehen zu einem chinesischen Restaurant. Was ist aber das Bedürfnis? Wenn ich als Partner das Bedürfnis kenne und verstehe, dann kann ich viel besser mit der vorgeschlagenen Strategie umgehen. Ist das Bedürfnis: Hunger stillen (egal wie), eine ruhige Ecke, um ein vertrauliches Gespräch zu führen oder Abwechslung und keine Lust mehr auf Pizza jeden Mittag? Ich als Partner erhalte ein tiefes Verständnis und kann mithelfen das Bedürfnis meines Gegenübers zu befriedigen. In der Regel gibt es eine gemeinsame Verbindung zwischen Menschen auf Bedürfnisebene.

Das Gleiche passiert auch bei der Entwicklung von Software. Welchen Nutzen (Bedürfnis) erwartet der oder die Stakeholder/in? Schauen wir uns eine typische „schlechte“ User Story an:

PowerShell Commandlet zum Speichern der Anlagenparameter.  

Jemand erfahrenes wird sofort loslegen können. Visual Studio gestartet und Projekt aufgesetzt, mit der Anlage verbunden und alle Analagenparameter in eine JSON-Datei gespeichert. Done. Aber wer will eigentlich diese Funktion? Was passiert mit der Datei?

Eigentlich wurde jetzt viel Potenzial verschenkt. Die gleiche User Story:

Als Anlagen-Konfigurator:in möchte ich ein PowerShell Commandlet zum Speichern der Anlagenparameter, damit ich die Konfiguration aus der Testanlage einfach in die Kundenanlage übertragen kann.

Aha: Mein/e Anwender:in will also im „Büro“ die Anlage in Betrieb nehmen und dann die Parameter in der Kundenanlage importieren. Damit spart man sich tagelange Vor-Ort-Termine in einem anderen Land beim Konfigurieren der Anlage. Spannend. Hier kann das Team weiterhelfen. Zum einen braucht es noch ein Commandlet zum Laden der Parameter. Aber viel wichtiger: Dürfen alle Parameter so einfach exportiert und importiert werden? Und müssen nicht einige Parameter konsequent verändert werden? Zwei Beispiele: Die Geräte Id muss eindeutig sein und darf nicht einfach so importiert werden. Also erzeugen wir eine GUID beim Laden. Zum anderen müssen die Ortsangaben angepasst werden. Wir schreiben noch ein Commandlet oder Skript welches die Ortsangaben („Büro“ in Deutschland zu Anlage in Taiwan) ersetzt. Und unser Commandlet exportiert keine Datei, sondern ein Objekt mit den Konfigurationsdaten.

Das Team kann also auf eine sehr detaillierte Weise neue und bessere und wahrscheinlich auch kostengünstigere (das Ersetzen der Ortsangaben muss nicht manuell erfolgen) Strategien – also Lösungen – anbieten. Die Beschäftigung mit der Story auf „Bedürfnisebene“ führt oft zu wertvollen Rückfragen und Klärungsgesprächen mit den Stakeholdern. Als Softwareentwickler und Softwareentwicklerin ist das ja unser Job – unsere Expertise beisteuern. Und wahrscheinlich gäbe es noch ganz viele andere Möglichkeiten, die Inbetriebnahme einer Anlage vorwegzunehmen und dann die Parameter zu übertragen.

Die Erfahrung zeigt, dass dieses Vorgehen die User Stories schärft und die Stakeholder bessere Lösungen bekommen. Auf diese Weise werden auch „technische“ Backlog Items (z. B. Logging oder CI/CD Pipeline) transparent in ihrem Nutzen.

Wenn man nicht in der Lage ist, ein überzeugendes „damit“ zu formulieren, dann ist die Story nicht „richtig“ bzw. „wertlos“ und braucht auch nicht implementiert werden.

Sie haben Fragen? Lassen Sie uns reden ...

Aydin Mir Mohammadi

Aydin
Mir Mohamadi


Lars Kaufmann

Lars
Kaufmann