Eine todsichere Methode, bessere User Stories zu schreiben

[caption id="attachment_7574" align="aligncenter" width="420" caption="Foto: punchline to a joke yet written von dickuhne (Lizenz: CC-BY)"]Foto: Nahaufnahme einer Hand, die mit Kugelschreiber auf Papier schreibt[/caption]

Wir haben an dieser Stelle bereits den Sinn und Zweck von User Stories behandelt und gesehen, warum sie helfen, bessere Software zu liefern. Der Artikel ist seit seiner Erscheinung einer der gefragtesten auf WendtsWelt, und ich möchte daher die Gelegenheit nutzen und das Thema etwas ausbauen. Wenn du den anderen Artikel noch nicht kennst, lies ihn bitte zuerst und komm dann wieder zurück. Wir warten solange...

Schön, dass du wieder da bist! Wie schreibt man nun eine richtig gute User Story?

Skandal: Kunden denken über ihre Probleme selbst nach!

Das Problematische ist, dass das, was der Kunde als Anforderung formuliert, häufig keine ist. Er hat nämlich meist schon selbst darüber nachgedacht. Das ist prinzipiell gut. Schlecht wird es, wenn die vom Kunden gefundene Lösung als Anforderung formuliert wird. Denn es gibt es vielleicht bessere Lösungen, die von der Anforderung verdeckt werden.

Wie findet man nun heraus, was das eigentliche Problem ist? Mit den "fünf Warum" -- diese Fragetechnik geht auf Toyota zurück, wird häufig zur Fehleranalyse herangezogen und ist bei wandelweb gut beschrieben:

Warum müssen wir an dieser Maschine jeden Tag den Boden wischen?
Auf dem Boden sammelt sich Öl.

Warum ist immer wieder Öl auf dem Boden?
Die Maschine hat ein Ölleck.

Warum leckt der Ölkreislauf der Maschine?
Das Absperrventil schließt nicht richtig.

Warum schließt das Ventil nicht richtig?
Der Ventilsitz ist beschädigt.

Warum wurde es nicht ausgewechselt?
Wir haben nicht bemerkt, dass es beschädigt war.

Warum haben wir es nicht bemerkt?
Es ist nicht im Wartungsplan.

Aha!

Für die Anforderung heißt das übertragen: Der Kunde beauftragt das "Automatisch-Öl-Aufwischen"-Feature, das noch dringend gebraucht wird. Damit wird aber lediglich das Symptom bekämpft.

Dass Kunden es nicht besser wissen, ist aber nicht weiter schlimm -- wir sind ja schließlich Dienstleister und keine Coding Monkeys. Im eigenen Interesse sollten wir also dem Kunden beratend zur Seite zu stehen, damit wirklich etwas Sinnvolles herauskommt.

Wissen, wann Schluss ist

Du musst nur wissen, wann du aufhörst zu fragen (Hervorhebung von mir):

Wieweit soll ich weiterfragen? Der Sinn der Fünf-Warum-Fragetechnik ist es, die Ursache soweit zu klären, dass man wirksam mit Gegenmaßnahmen ansetzen kann.

Dabei sollte natürlich der Kunde nicht das Gefühl bekommen, dass die Anforderung an sich hinterfragt wird. Aber er muss verstehen, dass es eventuell ein tiefer liegendes Problem gibt, das sich meist einfacher lösen lässt.

Weitere sehr einleuchtende Beispiel aus dem Alltag sind auch im Artikel Wer nicht fragt, bleibt dumm! bei der it-republik zu finden.

Ab hier schreibt sich die User Story von selbst

Ist das wirklich so? -- Ja! Das obige Beispiel als User Story formuliert:

Als Ingenieur
möchte ich einen aktualisierten Wartungsplan,
um Ventil-Beschädigungen rechtzeitig erkennen zu können.

Wir haben hier also eine klar abgegrenzte, nicht zu schwammige Rolle ("Ingenieur"), ein Feature ("aktualisierter Wartungsplan") und einen tatsächlichen Nutzen ("Beschädigungen rechtzeitig erkennen"). Diese Dinge sind zwingend notwendig für gut formulierte User Stories.

Noch ein anderes Beispiel, das ein bisschen besser zum Thema passt als Öl auf dem Boden: Der Kunde kann in unserer Software für bestimmte Dinge Titel vergeben und möchte, dass diese Titel eindeutig sein müssen. Das klingt erstmal vernünftig, aber vielleicht steckt ja doch ein anderes Problem dahinter!?

"Warum müssen sie eigentlich eindeutig sein?" -- "Weil sie sonst in einer Liste nicht unterscheidbar sind." -- "Warum sind sie nicht unterscheidbar?" -- "Weil nur die Titel angezeigt werden."

Eine mögliche Alternative ist also, mehr als nur die Titel anzuzeigen. (Das Beispiel zeigt auch, dass mitunter zwei Nachfragen reichen, um ans Ziel zu kommen!) Die passende User Story dazu lautet:

Als Redakteur möchte ich
mehr Eigenschaften als nur die Titel aufgelistet sehen,
um Dinge mit gleichem Titel unterscheiden zu können.

Ein nettes Beispiel ist auch, die Formulierung von Fehlermeldungen ändern zu wollen, obwohl die Programmlogik so geändert werden kann, dass die Meldung gar nicht mehr benötigt wird.

Alles da? Nochmal zum Abhaken

User Story fertig? Dann hilft vielleicht folgende Checkliste gegen grobe Schnitzer und für den letzten Schliff:

  1. Um wen geht es? Wessen Problem wird gelöst?
  2. Haben wir das Problem hinterfragt und verstanden oder die Anforderung einfach vom Kunden übernommen?
  3. Wird bereits eine Lösung vorgegeben oder wirklich nur das Problem beschrieben?
  4. Was ist der Nutzen dieser Anforderung? Passt er auf die genannte Rolle?

Auch wenn das alles sehr formalistisch klingt: Keine Sorge -- je mehr Stories du schreibst, desto mehr werden diese Dinge in Fleisch und Blut übergehen.

Hab ich was vergessen?

Oder vielleicht etwas übersehen? Sicherlich hast du noch Ergänzungen parat -- als Entwickler, Kunde, Produktmanager oder Außenstehender. Sag's uns in den Kommentaren!

Aktualisiert: