≡ Menu

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]

Comments on this entry are closed.

  • Anje 14. Juni 2010, 20:48

    Das Konzept der User Stories ist für mich komplett neu. Bisher habe ich allerdings auch kein einziges Projekt von Anfang an begleitet (als Auftraggeber oder Nutzer). Ich bin immer erst dazu gestoßen, wenn der erste Wurf der Anwendung schon fertig war und eingeführt wurde. Um dann als Nutzer über jeden Fehler stolpern zu müssen und auf Nachfrage die Antwort zu bekommen: “Das ist so, damit müssen wir leben. Aber so und so kannst du das umgehen…” Meiner Meinung nach ganz klar: Thema verfehlt! 6, setzen!

    Bei den von mir begleiteten Weiterentwicklungen einer bestehenden Software ist es zwar auch ohne User Stories gut gegangen. Nichtsdestotrotz ist die Kommunikation zwischen Anforderer und Entwickler oft schwierig und zäh. Der Anforderer muss zumeist viele Fachbereiche und Interessen unter einen Hut bringen und traut sich aufgrund mangelndes Wissens bzgl. Softwareentwicklung nichts zu. Der/die Entwickler sind ja schließlich die Profis und werden es schon richtig machen. Letztgenannte kennen hingegen das Geschäft des Anforderers kaum oder gar nicht und können somit die speziellen Bedürfnisse des Kunden gar nicht befriedigen. Ein Teufelskreis, der zumeist vor allem dem Nutzer schadet. Denn der muss im schlimmsten Fall jeden Tag mit der Software arbeiten…

  • riethmayer 15. Juni 2010, 12:46

    Ich hab user-stories fuer unser Ticketing eingefuehrt:
    Um [einen Businessvalue zu erreichen]
    Als [Rolle]
    Moechte ich [in der Lage sein etwas zu tun] .

    Der Businessvalue ist dabei wichtig um den Bezug der Features eindeutig zu machen.

    Der Businessvalue ist also bei dir nicht ‘den Dialog zu schliessen’ sondern das ‘versehentliche Loeschen zu verhindern’.

    Es ist echt hilfreich, wenn die Entwickler verstehen, was die Product-Owner wollen. Und es ist gut, wenn dem Product-Owner klar gemacht werden muss, warum ein Feature wichtig oder unwichtig ist, wenn man sich ueberlegen muss wo denn der eigentliche Wert des Features liegt.

    Find ich super :)
    LG @riethmayer

  • André 16. Juni 2010, 08:36

    @Anje:

    > Der Anforderer […] traut sich aufgrund mangelndes
    > Wissens bzgl. Softwareentwicklung nichts zu.

    Das ist ja auch gar nicht deine Aufgabe, wie bei jedem anderen Dienstleister auch. Deshalb muss man drüber sprechen, und so ein Gespräch beginnt man am besten mit einer Story.

    @riethmayer:

    > Der Businessvalue ist also bei dir nicht ‘den Dialog zu
    > schliessen’ sondern das ‘versehentliche Loeschen zu
    > verhindern’.

    Sag ich doch: Deshalb ist das Beispiel ja mit “Woran man eine schlechte User Story erkennt” überschrieben. ;-)

    Mir gefällt das Kriterium “Wert des Features”! Darüber wird viel zu wenig nachgedacht bei der Entwicklung. (Und in Kundenprojekten wird das häufig leider gar nicht hinterfragt.)