Wie schreibe ich eine User Story oder anders gefragt: Was nützt mir der Nebel?

Der Weg zur User Story fällt vielen erstmal schwer und zwar an der Stelle, an der man es eigentlich nicht erwarten sollte: Beim Formulieren des Nutzens. Wir sind so darauf getrimmt Funktionen zu beschreiben, dass uns der Nutzen implizit bewusst ist, jedoch anfangs nicht zu greifen erscheint. Einen Nutzen zu beschreiben und ihn in Worte zu fassen fällt schwer, es ist wie das Greifen nach einem Nebelfaden, der kurz vor der Berührung zerstäubt.
Im Nebel, so fühlen sich viele Teams, wenn sie Anforderungen ohne Nutzen übergeben bekommen. Sie müssen anfangen die Schemen, die geschrieben stehen, zu interpretieren. Den Nutzen in den Sätzen, Zusammenhängen zu finden, die Schwaden zu durchtrennen und zu entwirren. Gelingt es, dann haben wir bestenfalls eine Funktion mit einer Interpretation des Nutzens und wir können hoffen, dass die Beteiligten miteinander reden, um zu validieren, ob die Funktion auch den gewünschten Nutzen erfüllt.

“Gib mir einen Nutzen und ich gebe dir die Funktion dazu, die Du dir wünscht.”

Das ist mein persönlicher Leitspruch und auch meine Empfehlung, wenn es darum geht, User Stories zu schreiben. Fangt mit den Fragen “Wer” und “Wozu” an und schreibt diese auf. Startet beispielsweise so:
Als Stammkunde Ralf Müller möchte ich …, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.
Wenn ihr eine gute Idee habt, dann schreibt noch die Frage nach dem “Was” dazu, also die Funktion:
Als Stammkunde Ralf Müller möchte ich eine Benachrichtigung, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.
Am besten ist es, wenn ihr das “Was” gemeinsam mit eurem Entwicklungsteam klärt. Verstehen sie den Nutzen, dann werden Sie eine Funktion finden, die den Nutzen erfüllt. Spätestens im Sprint Planning 1 sollten die Anforderungen dann geklärt werden. Vielleicht schlägt das Entwicklungsteam neben der E-Mail Benachrichtigung und der direkten Anzeige auf der Folgeseite noch das Versenden einer Benachrichtigung per Blumenstrauß vor – wer weiß.
Um der angesprochenen Funktion etwas mehr Gestalt zu geben, formuliert ihr noch Akzeptanzkritierien. Dadurch könnt ihr den Rahmen aufspannen und vorgeben, was minimal erfüllt werden muss – nicht mehr, aber auch nicht weniger. Auch diese Kriterien klärt ihr gemeinsam mit dem Entwicklungsteam und zwar im Dialog und zwar von Angesicht zu Angesicht. Vom Entwicklungsteam lasst ihr dann Akzeptanztests bzgl. der  Akzeptanzkritierien aufstellen. Ein Kriterium könnte in unserem Beispiel sein:
Die Bestätigung erfolgt auf zwei Kommunikationskanälen. Ein Kommunikationskanal ist im System, der andere der Postweg.

Warum sollte das Entwicklungsteam die Funktion ausformulieren?

Das ist für mich implizit eine Frage nach der Reife des Teams. Jedes Entwicklungsteam lernt am eigenen Produkt die Fachdomäne, in der es sich bewegt und wird über die Zeit zum Domänenspezialisten. Das ist jedoch nur ein Grund, ein wichtigerer ist der folgende: Jedes Team weiß am besten, wie sich der gewünschte Nutzen im System am besten abbilden lässt. Ein cross-funktionales Team zeigt hier seine Stärken, jedoch kennt jedes andere Entwicklungsteam es auch besser als der Kunde bzw. die meisten User. Man fragt sie nur zu selten.
Ein Grund hierfür ist sicherlich, dass die User sich nicht die Fragen stellen müssen, die ein Teammitglied sich stellt, zum Beispiel: “Wie passt die Funktion in das Konzept der Anwendung?”, “Muss ich hier auch die Funktionen A, B und C berücksichtigen?” Ein Entwicklungsteam hat einen ganz anderen Kontext zum Produkt, das es entwickelt. Dieser muss aufgebaut werden.

Was benötigt eine gute User Story jetzt noch?

Wir haben das normale Format mit Wer, Was, Wozu – also: Als <Persona> möchte ich <Funktion>, damit ich <Nutzen>. Wir haben Akzeptanzkritierien , die aufzeigen, was minimal geliefert werden muss. Akzeptanztests, die das Entwicklungsteam ausformuliert und die aufzeigen, dass die Akzeptanzkritierien erfüllt werden. Was fehlt?
Es ist der Nebel.
In unserem Beispiel ist der Nebel zuerst der leere Funktionsteil. Hier muss Kommunikation erfolgen, damit geklärt wird was selbst der Platzhalter Benachrichtigung später konkret heißen soll. Konkret gesagt ist der Nebel keine Worthülse, die beliebig interpretiert werden darf, trotzdem ist der Nebel die Unklarheit auf dem Weg zur Implementierung.
Eine User Story ist ein Anlass zur Konversation. Das bedeutet, wir benötigen eine gewisse Unstabilität in der User Story, damit eine Konversation, ein Dialog entstehen kann. Wir brauchen Unschärfe. Hier brauchen wir allerdings die Art von Nebel, die nicht verschleiert. Nicht der Nebel, der durch schöne Worte und vermeintliche Vollständigkeit und die stumpfe Präzision eines Löffels uns denken lässt: “Alles steht hier geschrieben, genau das brauchen wir so wie es formuliert wurde.” Nein, wir brauchen den Nebel, der uns fragen lässt: “Hey, sollen wir lieber links oder rechts gehen, ich bin mir gerade nicht ganz sicher.” Software-Entwicklung ist zu großen Teilen ein Kommunikationsproblem und zu genaue Anweisungen verstärken dieses Problem. Bei zu genauen Anweisungen fragen wir nicht mehr nach, die Kommunikation versiegt.
Für viele von Euch ist die Fahrt, der Spaziergang im Nebel erstmals ungewohnt, lasst ihn trotzdem zu und lasst Euch drauf ein. Es ist faszinierend, was nach kurzer Zeit vor einem auftaucht und welche Überraschungen und Details einem ins Auge fallen, die man aus der Ferne, selbst mit Weitblick, nicht hätte erkennen können.

Geschrieben von

bgloger-redakteur bgloger-redakteur

TEILE DIESEN BEITRAG

8 Antworten zu “Wie schreibe ich eine User Story oder anders gefragt: Was nützt mir der Nebel?”

  1. Hans-Peter Korn sagt:

    Ja, und bei all dem ist zu berücksichtigten, dass User Stories allein für grössere Systeme nicht genügen.
    Siehe in http://www.scrum-day.de/archiv/scrumdayjul12sap/vortraegedownload/Scaling%20Lean%20and%20Agile%20for%20Scrumdays.pptx.pdf die Seiten 5 bis 8 und dann noch http://scaledagileframework.com/agile-software-requirements-model/ und http://scaledagileframework.com/stories/

    • Marc Bless sagt:

      Das SAF versucht ja explizit, mit der Terminologie “Feature” die bekannten Sprache von Marketing und Product Management zu übernehmen, um die Kommunikation dorthin zu vereinfachen. Die aufgebaute Hierarchie Epic -> Feature -> Story ist ein reines Vehikel und wirkt auf mich etwas künstlich. Wenn eine von einem Feature abgeleitete Story sehr groß ist, kann sie immer noch ein Epic sein. Epics und Stories sind per se das gleiche und unterscheiden sich nur in der Größe.
      Aber wenn es hilft, den Wasserfall mit dem SAF etwas zu agilisieren, und dies der erste erstrebenswerte Zustand in einer Organisation ist, dann soll es mir recht sein.
      In meiner Welt sieht die Hierarchie so aus: Story -> Story -> Story -> … und jede Story kann dabei noch beliebig vielen Themes zugewiesen werden.

      • Hans-Peter Korn sagt:

        Mit einer Hierarchie “Story -> Story -> Story -> …” bin ich gar nicht glücklich. Denn eine “Story” – entstanden bei XP als informeller “Gesprächsanlass” zwischen Kunde und Entwickler und jetzt (etwas formalisierter) auch in anderen agilen Vorgehensweisen benutzt – ist ja etwas, das vollständig innerhalb einer kurzen timebox von 1 bis max. 4 Wochen von einem Team realisiert werden kann – und zwar nebst weiteren Stories. Wenn auch umfangreichere Funktionalitäten – bis hin zu Epics auf der Ebene von “Investment Themen” oder “Business Cases” auch “Story” genannt werden, dann erschwert das die Kommunikation. Und diese umfassenden Funktionalitäten können ja auch nicht nur mittels “”Als möchte ich , damit ich “” beschrieben werden, da sie z.B. normalerweise eine Reihe von Personas und unterschiedliche Funktionen betreffen. Und am anderen Ende der Skala werden Stories ja auch in “Tasks” unterteilt – die auch wieder anders als nach dem Muster “”Als möchte ich , damit ich “” formuliert sind.
        Alles nur als Story in der Form “”Als möchte ich , damit ich “” formulieren zu wollen ist für mich eine unangemessene Trivilalisierung.
        Paul Valéry sagte mal:: „Alles einfache ist falsch, alles komplizierte unbrauchbar.“
        Wir müssen also auch hier einen angemessenen Mittelweg zwischen zu grosser Vereinfachung und zu grosser Verkomplizierung finden.

  2. Rolf F. Katzenberger sagt:

    Hi Sven,
    an der Nutzenbeschreibung lässt sich noch etwas verbessern, finde ich. Im Beispiel
    “Als Stammkunde Ralf Müller möchte ich eine Benachrichtigung, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.“
    sieht man schön die oft in User Storys auftretende Verwechslung des Benutzer-Nutzen mit einem Effekt im/am “System”. Die Interaktion mit dem System schafft aber einen Nutzen, der *außerhalb* des Systems liegt, denn es ist ja der Nutzen von *Ralf Müller*, den die User Story beschreibt.
    In diesem Beispiel, etwas spekulativ formuliert, wäre der wahre Nutzen für Ralf Müller eher umschrieben mit: “Prima, für mich bleibt jetzt nichts mehr zu tun, ich kann einfach passiv abwarten, bis die Lieferung kommt.”
    Da taucht kein System drin auf und sollte es auch nicht. Der wahre Nutzen ist sicher nicht immer leicht zu formulieren; in unserem Beispiel wäre mein Vorschlag so etwas wie:
    “Als Stammkunde Ralf Müller möchte ich eine Bestellbenachrichtigung, damit
    ich erkenne, dass ich nichts mehr zu tun brauche, damit die Lieferung kommt.“
    Gruß,
    Rolf

    • Sven Winkler sagt:

      Hi Rolf,
      mag sein, dass man sich beim “das im System” ablenken lassen kann, für mich nicht wirklich relevant, da mein Nutzen für mich als User klar formuliert ist und außerhalb liegt. Mir geht es ja nicht drum ob das Ding im System konsistent oder sonst etwas gespeichert ist, sondern, für mich als User ist es in jedem Webshop wichtig, dass ich sehe, dass meine Bestellung entgegengenommen wurde und daher im System eingegangen ist. Vielleicht noch aus einem anderen Winkel betrachtet: Für mich ist es besonders bei einer Bestellung wichtig zu sehen, ob die Anwendung auch wie erwartet reagiert, so möchte ich doch Mehrfachbestellungen vermeiden und trotzdem meine Ware bekommen.
      Wenn es schöner klingt gerne:
      …damit ich erkenne, ob meine Bestellung erfolgreich entgegengenommen wurde.
      …damit ich sehe, ob meine Bestellung erfolgreich eingegangen ist.
      …damit ich erkenne, was ich noch zu tun habe.
      …damit ich erkenne, ob meine Bestellung erfolgreich verarbeitet wurde.
      Cyas 🙂

      • Rolf F. Katzenberger sagt:

        Hi Sven,
        ha, da möchte ich nochmal nachhaken 😉 Du sagst: “Vielleicht noch aus einem anderen Winkel betrachtet: Für mich ist es besonders bei einer Bestellung wichtig zu sehen, ob die Anwendung auch wie erwartet reagiert, so möchte ich doch Mehrfachbestellungen vermeiden und trotzdem meine Ware bekommen.”
        Wichtig zu sehen, ob die Anwendung auch wie erwartet reagiert? Ja klar, aber das ist nicht der *Nutzen*. Genau Deinen Nutzen hast Du doch im allerletzten Teil superkurz und knackig ausgedrückt: “möchte ich doch Mehrfachbestellungen vermeiden und trotzdem meine Ware bekommen.”?
        Die späteren Formulierungsvarianten zum Nutzen beschreiben letztlich ein
        Akzeptanzkriterium des POs in Kurzform (“Bestellung erfolgreich
        verarbeitet”), das wäre aber ein anderer Teil der User Story (Confirmation)), nicht der Nutzen.
        Im wahrsten Sinne des Wortes bildlich gesprochen: dass der Nagel nun sichtbar, heil und tragkräftig aus der Wand herausragt, ist wichtig – aber es ist nicht mein gewünschter Nutzen. Der Nutzen ist, dass ich jetzt beruhigt mein Bild an der Wand betrachten kann. Sieht man auch daran, dass ich 2025 auch den dezenten Pieps eines Levitationsgeräts statt der altmodischen Nageleinschlagsvollzugsbestätigung freudig akzeptieren werde, solange ich am Ende unverändert *meinen* Nutzen davon habe.
        Etwas salopp formuliert würde ich sagen, der Nutzen muss per “5 Whys” aus dem herausgekitzelt werden, was dem Autor der User Story als erstes dazu eingefallen ist.
        Ist wirklich ein interessanter Aspekt, deshalb die Penetranz… Vielleicht einigen wir uns ggf. auf ein let’s agree to disagree agreeably. 😉
        Cyas 🙂
        Rolf

        • Sven Winkler sagt:

          *gg* Agree und das mit dem Levitationsgerät gefällt mir gut 😉
          Das Beispiel entkoppelt sehr schön das WIE und WAS.
          Warte nun freudig auf 2025 und vielleicht können wir dann zusammen ein paar Bilder aufschweben 😉

  3. toller Ansatz mit dem Persona und Nutzen zu beginne, werde bei meiner nächsten User Story gleich damit beginnen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.