Warum User Stories helfen, bessere Software zu liefern

Es gibt zwei Umstände, die bei der Softwareentwicklung nicht gerade helfen, das Produkt in einem nutzerfreundlichen Zustand auszuliefern:

• Anforderungen werden meist technisch und ohne ihren Nutzen für den Anwender formuliert. Das lässt zu wenig Spielraum für Alternativen, falls sie notwendig sein sollten. Außerdem wird es erschwert, die Anforderung zu hinterfragen.
• Oft vergeht zwischen der Formulierung einer Anforderung und ihrer Umsetzung zu viel Zeit. Damit ist dann auch die Information über den Nutzen im besten Fall nicht mehr gegenwärtig, im schlimmsten Fall sogar ganz verloren.

Abhilfe können User Stories schaffen, die häufig in agilen Prozessen wie Scrum benutzt werden.

Beschreibung von Features nach Schema F

User Stories formulieren die Anforderung und den zugehörigen Kundennutzen in Alltagssprache:

Als [Nutzer]
kann ich [Dinge tun],
um [daraus einen bestimmten Nutzen zu ziehen].

Das macht es vor der Umsetzung einfacher, über das Feature zu reden, ohne den Kunden mit technischen Details in die Flucht zu schlagen. (Oder sich als Entwickler die Umsetzung vorweg nehmen zu lassen.) Das ist eine der Hauptaufgaben: Konversationen anzustoßen.

Aber auch während der Umsetzung ist das eine Erleichterung, weil die Story die Hintergründe einer Anforderung deutlich macht. Wenn technische Einschränkungen die Anforderung erschweren oder unmöglich machen, lässt die Story Spielraum für Alternativen.

User Stories können also zur Produktivität, Selbstorganisation und Kundenzufriedenheit beitragen.

Woran man eine schlechte User Story erkennt

User Stories werden meist auf Karteikarten, sogenannte Story Cards, geschrieben -- um sie "klein zu halten".

Wie genau man sich an die Formulierungsvorgabe hält, ist jedem selbst überlassen. Die Story soll schließlich einen Zweck erfüllen -- daher ist es legitim, das nach eigenem Ermessen anzupassen.

Eine gute Story lebt davon, dass sie wirklich in Alltagssprache formuliert wird. Dabei ist der dritte Teil, also der Kundennutzen, unbedingt zu beachten.

Als Nutzer
kann ich "OK" drücken,
um den Dialog zu schließen.

ist eine denkbar schlechte User Story. Warum?

1. Die Rolle "Nutzer" ist zu schwammig formuliert, das passt immer.
2. Die Aktion "[OK] drücken" ist zu technisch formuliert.
3. Der Nutzen "um den Dialog zu schließen" ist gar keiner, sondern lediglich eine weitere Aktion.

Von diesem Pseudo-Nutzen zum tatsächlichen kommt man mit der Frage "Wozu?" -- "Um zu drucken." Aha, da ist der wirkliche Nutzen! (Mehr zur Untersuchung von scheinbar aus der Luft gegriffenen Anfragen von Kunden in Bessere User Stories schreiben.)

Was eine gute Story ausmacht

Ein viel besseres Beispiel ist:

Als Autor
muss ich das Löschen meines Dokuments bestätigen,
um ein versehentliches Löschen zu verhindern.

Der Nutzen "versehentliches Löschen verhindern" ist konkret und lässt gleichzeitig Spielraum, den gewünschten Effekt auch anders umzusetzen (z.B. eine Rückgängig-Funktion, nach dem das Dokument ohne Rückfrage gelöscht wurde.)

Dem Nutzer hilft, wenn man permanent an ihn denkt

Der explizit formulierte Nutzen führt dazu, dass man als Entwickler nicht nur die technische Herangehensweise sieht, und sich auch in den Nutzer hineinversetzt.

Gute User Stories zu schreiben ist nicht so einfach. Zumindest aber helfen sie, bessere Software zu schreiben und sie näher am Nutzer zu orientieren.

Wie siehst du das als Nutzer, Entwickler oder Auftraggeber? Hast du schon Erfahrungen mit User Stories gemacht, die du beitragen möchtest? Werden User Stories vielleicht auch für andere Produkte eingesetzt?

Sag's uns in den Kommentaren!

[Foto: WikiData User Stories von Paul Downey, CC-Lizenz]