Technische User Stories
4. April 2011
User Stories sollen eine Anforderung eines Nutzers an das System beschreiben. Technische Teilaufgaben sollten daher eigentlich immer Teil einer User Story sein und dann in diesem Kontext umgesetzt werden. Es wird aber auch immer wieder technische Aspekte geben, die nicht direkt einem Kundennutzen zugeordnet werden können, z.B. der Umstieg auf eine neue Datenbankversion weil die bisher genutzte aus der Wartung fällt, oder die zu komplex sind, um als Task einer User Story behandelt zu werden.
Häufig werden auch aus den Teams Aufgaben benannt, die notwendig sind um z.B. Skalierung und Wartbarkeit zu verbessern. Diese haben naturgemäß eine sehr technische Ausrichtung. Damit ein qualitativ hochwertiges Produkt entsteht, müssen auch diese Tasks berücksichtigt werden: Sie müssen als User Stories auf das Backlog. Das wiederum wird aber allein vom Product Owner verwaltet, die technische Aufgabe muss also dem Product Owner verständlich gemacht werden. Soweit die Aufgabe.
Wie komme ich aber zur Lösung, d.h. wie erstelle ich zu einer technischen Aufgabe wie „Magic Numbers durch Enums ersetzen“ oder „Oracle 10 Migration“ eine User Story, die der Product Owner verstehen und damit priorisieren kann?
Um aus einem technischen Task eine User Story zu formen, müssen eigentlich nur zwei Fragen beantwortet werden:
- Warum soll die Aufgabe durchgeführt werden?
- Wem nützt das Ergebnis?
Die Antwort auf die erste Frage liefert mir den zweiten Teil einer User Story, nämlich das „um … zu erreichen“. Wenn eine einfache Frage nicht direkt eine befriedigende Antwort liefert, kann auch mittels der „5 Why“ nachgebohrt werden. In unserem Beispiel könnten die Antworten lauten „um den Code leichter lesbar zu machen und die Wartbarkeit zu erhöhen“ bzw. „um weiterhin Support vom Hersteller zu erhalten“.
Die Antwort auf die zweite Frage liefert mir dann den Anfang der User Story, also das „Als … möchte ich“. Die Frage, wer von einem Task am meisten profitiert, könnte in unserem Beispiel beantwortet werden als „Als zukünftiger Entwickler des Systems“ und „Als Systembetrieb“. Die User Stories zu unseren Beispielen könnten also wie folgt lauten:
- „Als (zukünftiger) Entwickler möchte ich, dass Magic Numbers durch Enumerations ersetzt werden, um den Code leichter lesbar zu machen und die Wartbarkeit zu erhöhen“
- „Als Systembetrieb möchte ich, dass auf die neueste Oracle Version migriert wird, um weiterhin Support vom Hersteller zu erhalten.“
In dieser Form lassen sich Sinn und Wichtigkeit technischer Aufgaben leichter dem Product Owner vermitteln. Und wenn sich kein Grund angeben und kein Nutznießer finden lässt, dann ist die entsprechende Aufgabe wohl auch einfach nicht wirklich wichtig.
Quelle Bild: © coramax – Fotolia.com
| 2 Kommentare