Was eine Story ist
Kurz gesagt: Eine Story sagt in einem Satz, wer etwas will, was er will und warum. Sie ist keine Spezifikation: Die Einzelheiten kommen im Gespräch, und die Bestätigung sagt, woran wir erkennen, dass sie fertig ist. Eine Aufgabe für den Entwickler und eine Schicht sind keine Stories, weil niemand sie allein ausprobieren kann.
Problem
Die Bitte in einer Zeile
Auf der Aufgabenliste des Teams steht eine Zeile: „Gutscheincodes“. Der Entwickler baut ein Feld für den Code, das 10 % von der ganzen Bestellung abzieht. Der Tester prüft, dass 10 % abgezogen werden. Alles besteht.
Zum Start fragt das Marketing, warum der Code auch bei reduzierten Produkten funktioniert. Die Buchhaltung fragt, wo sie sehen kann, wie viel Rabatt in diesem Monat gegeben wurde. Niemand hat seinen Teil falsch gemacht. Die Zeile „Gutscheincodes“ hat nie gesagt, für wen sie war oder warum.
Die Idee
Wer, was, warum
Eine User Story beschreibt einen Bedarf in einem Satz mit drei Teilen:
Als [Rolle] möchte ich [Ziel], damit [Nutzen].
Als Stammkunde möchte ich im Warenkorb einen Gutscheincode eingeben, damit ich für die Bestellung weniger zahle.
- Die Rolle ist der Mensch, der den Bedarf hat. Nicht „der Benutzer“ im Allgemeinen, sondern ein Kunde, ein Lagermitarbeiter, eine Buchhalterin. Das sind die Interessengruppen aus dem vorigen Modul.
- Das Ziel ist das, was sie tun wollen, in ihren Worten, ohne Buttons und Tabellen.
- Der Nutzen ist das Warum. Er ist der wertvollste Teil, denn die Lösung wird an ihm validiert: Funktioniert das Feld für den Code, aber der Kunde zahlt trotzdem nicht weniger, ist die Story nicht erfüllt.
Eine Story ist eine kleine Anforderung, geschrieben so, dass sie ein Gespräch anstößt. In diesem Kurs sagen wir Story.
Genauer, für Neugierige
Die Schablone „Als …, möchte ich …, damit …“ wird mit einem Team der britischen Firma Connextra um 2001 verbunden und wurde durch das Buch „User Stories Applied“ von Mike Cohn (2004) bekannt. ISTQB CTFL v4.0.1 (Abschnitt 4.5, kollaborationsbasierte Testansätze) gibt dieselbe Schablone an: eine Rolle, ein Ziel und den geschäftlichen Wert für die Rolle.
Die Schablone ist nicht verpflichtend. Manche Teams schreiben „Um … zu …, als …, möchte ich …“, um den Nutzen nach vorn zu stellen. Wichtig ist, dass alle drei Teile da sind.
Probier es aus
Eine Story oder nicht?
Die Idee
Die drei C
Ein Satz kann nicht alles über Gutscheincodes tragen. Und er soll es auch nicht. Ron Jeffries, einer der Begründer des Extreme Programming, beschreibt eine Story mit drei englischen Wörtern, die mit C beginnen. Sie heißen die drei C:
- Card (Karte). Die Story ist so kurz, dass sie auf eine kleine Karte passt. Die Karte ist nicht die Anforderung; sie erinnert daran, dass ein Gespräch nötig ist.
- Conversation (Gespräch). Die Einzelheiten werden im Gespräch zwischen denen erarbeitet, die Bescheid wissen: dem Fachbereich, QA und dem Entwickler. Dort kommen die Fragen „Was ist mit reduzierten Produkten?“ und „Was, wenn der Code zweimal verwendet wird?“ auf.
- Confirmation (Bestätigung). Woran erkennen wir, dass die Story fertig ist? An konkreten Regeln und Beispielen, die sich prüfen lassen. Sie werden vor der Arbeit aufgeschrieben.
Die Story zu den Gutscheincodes hatte eine Karte. Sie hatte kein Gespräch, also auch keine Bestätigung. Deshalb hieß „fertig“ „der Entwickler hat aufgehört“.
Genauer, für Neugierige
Jeffries hat die drei C 2001 in einem Artikel beschrieben. ISTQB CTFL v4.0.1 führt sie im Abschnitt über das gemeinsame Schreiben von User Stories auf und verbindet die Bestätigung mit den Akzeptanzkriterien. Die Kriterien sind das Thema der Lektion „Akzeptanzkriterien“ in diesem Modul.
Die Idee
Was eine Story nicht ist
Drei Dinge hält man am häufigsten für eine Story:
- Eine Spezifikation. Eine Story listet nicht alles auf. Wird die Karte zu einer Seite mit jedem Fall, findet das Gespräch nicht statt, und das Geschriebene bleibt trotzdem unvollständig. Die Einzelheiten werden nach dem Gespräch aufgeschrieben, als Regeln und Beispiele.
- Eine Aufgabe für den Entwickler. „Füge der Zahlungsseite ein Feld für den Code hinzu“ sagt, was zu tun ist, aber nicht für wen oder warum. Aufgaben sind in Ordnung, aber sie kommen nach der Story, wenn das Team entscheidet, wie es sie baut.
- Eine Schicht des Systems. „Das Backend für die Gutscheincodes“ oder „der Bildschirm des Warenkorbs“ sind Teile der Lösung. Niemand kann sie allein ausprobieren und sagen „ja, das wollte ich“.
Und noch eines: „Als System möchte ich …“ ist keine Story. Das System hat keine Bedürfnisse. Hinter jedem „Als System“ steht ein Mensch, den wir noch nicht gefunden haben.
Probier es aus
Welches „damit“ ist ein Nutzen?
Wähle in jeder Frage das Ende der Story, das den echten Nutzen nennt.
Die Idee
Warum der Nutzen wichtig ist
Der Nutzen tut zwei Dinge.
Erstens wird die Story an ihm validiert. „Damit ich entscheiden kann, ob ich noch etwas dazunehme, um 50,00 € zu erreichen“ sagt, dass es nicht genügt, die Lieferung nach der Zahlung zu zeigen. Sie muss im Warenkorb sichtbar sein, solange der Kunde noch auswählt.
Zweitens eröffnet er bessere Lösungen. Die Buchhalterin bittet um einen Excel-Button. Der Nutzen ist „damit ich mit der Bank abgleichen kann“. Vielleicht ist die bessere Lösung ein fertiger Bericht, der von selbst ankommt. Das ist dieselbe Gewohnheit wie in der Lektion über die Ermittlung: der Bedarf hinter der gewünschten Lösung.
Wenn du den Nutzen nicht schreiben kannst, ist das ein Zeichen. Entweder weißt du nicht, warum die Story gebaut wird, oder sie wird nicht gebraucht. In beiden Fällen ist der nächste Schritt eine Frage, keine Arbeit.
Übung
Von der Bitte zur Story
1. Welche Story nennt den Bedarf? Drei Bitten von Interessengruppen, jede mit drei Versuchen, sie aufzuschreiben.
Test