User Stories sind ein Werkzeug, das aus dem Extreme Programming stammt und de facto die Art und Weise geworden ist, wie agile Teams ihre Anforderungen dokumentieren und sammeln. Es wurde schon viel über User Stories geschrieben (Link, Link, Link), also werde ich nur darüber sprechen, was ich beim Schreiben von guten Stories für wichtig halte, da ich heute eine Menge wirklich schlechter Stories da draußen sehe.
Für diejenigen, die es nicht wissen: Stories sind ein leichtgewichtiges Artefakt, das uns erlaubt, sowohl die Bedürfnisse des Unternehmens zu erfassen UND die Arbeit zu planen. Sie werden typischerweise auf Karteikarten (ja…kleine 3×5 oder 4×6 Karten) in der Sprache des Unternehmens oder des Kunden geschrieben. Bei User Stories schreiben wir nur so viel, wie nötig ist, um die Bedürfnisse des Benutzers zu erfassen, und nicht mehr. Wir neigen dazu, Stories nicht als vollständige Spezifikation der Anforderungen zu betrachten, sondern als Platzhalter für spätere Gespräche zwischen den Entwicklern und dem Fachbereich.
Wenn sie richtig eingesetzt werden, bietet der Mangel an Details einer User Story einen großen Nutzen – wir können dasselbe Dokument verwenden, um über eine Anforderung von einer hohen Ebene aus zu sprechen, in die Implementierungsdetails hineinzuzoomen und wieder herauszuspringen, alles im Laufe von ein paar Sätzen. Wenn wir dann mit dem Sprechen über die Anforderungen fertig sind, können wir Risiken berücksichtigen, Abhängigkeiten identifizieren und einen Projektplan erstellen, ohne jemals die Karteikarte weglegen zu müssen. Wow! Ich kenne kein anderes Anforderungsartefakt, das uns einen solchen Nutzen bietet.
Im Laufe der Jahre haben sich Leute, die wirklich erfolgreich mit Stories arbeiten, auf einige Gemeinsamkeiten geeinigt, die in allen Stories zu finden sind:
- Rolle: wer oder was wird diese Funktion nutzen?
- Feature (oder Fähigkeit): was wird das Team liefern oder hinzufügen, nachdem es seine Arbeit beendet hat?
- Wert: warum will das Unternehmen diese Funktion überhaupt? Welche Auswirkung auf das Geschäft wird es haben?
- Akzeptanzkriterien: wie werden wir wissen, ob diese Funktion fertig ist?
- Schätzung: wie viel wird diese Funktion nach Meinung des Teams kosten?
IMO, damit eine Story als vollständig betrachtet werden kann, muss sie ALLE oben beschriebenen Eigenschaften haben. Ich stelle fest, dass, wenn Leute Schwierigkeiten haben, alle Merkmale zu definieren, die Stories nicht das sind, was ich als reif bezeichne, d.h. sie sind nicht gut genug durchdacht, um vom Team genutzt werden zu können. Zusätzlich zu diesen Merkmalen sollten Stories auch den INVEST-Kriterien folgen (dieser großartige Artikel von J.B. Rainsberger spricht auch über INVEST).
Mike Cohn hat ein großartiges Buch über User Stories geschrieben. Unglücklicherweise scheinen sich die Leute bei all dem Guten im Buch auf das eine Stück Schrott im Buch konzentriert zu haben – die User-Story-Vorlage. In seinem Buch bietet Mike eine Vorlage an, die von einigen Teams als hilfreich beim Schreiben von Stories empfunden wurde, und von da an war diese Vorlage die Quelle von so vielen schlechten Stories, dass ich ihr keine weitere Tinte (oder Bits) mehr geben werde. Was mich an der Vorlage stört ist, dass sie die Leute dazu bringt nicht mehr zu denken, da sie mechanisch Rolle, Feature und Wert ausfüllen und Akzeptanzkriterien und Schätzung weglassen (vermutlich weil sie in der Vorlage fehlen). Wenn ich sehe, dass Leute mit Stories zu kämpfen haben, dann deshalb, weil sie versuchen, ihr Geschäft in eine Vorlage zu pressen, die irgendeinem namenlosen Team (das diese Vorlage wahrscheinlich nicht einmal mehr benutzt) vor fünf oder sechs Jahren geholfen hat, und – Überraschung – sie passt nicht dorthin, wo sie gerade sind.
Es gibt einen Denkprozess, der stattfinden muss, bevor man eine einzige Story schreibt. Die Schritte, die ich bei Leuten sehe, die erfolgreich Geschichten schreiben, sind unten aufgeführt. Bitte denken Sie daran, dass diese Schritte in meinem Beitrag zwar linear sind, man aber zurück- und vorwärtsspringen und herumspringen kann, wenn es sinnvoll ist. Das Ziel ist es, diese Fragen zu beantworten, wenn Sie Ihre User Story Exploration abgeschlossen haben.
- Welche Rollen (oder Benutzer) werden Ihr System nutzen?
- Welche Bedürfnisse haben sie? Wie hilft ihnen das Produkt, diese zu erfüllen?
- Welche Funktionen (oder Fähigkeiten) wollen Sie diesen Rollen zur Verfügung stellen?
- Warum sind diese Funktionen für das Unternehmen wertvoll? Welche Art von Geschäftsergebnissen können wir von diesen Funktionen erwarten?
- Was sind die Prioritäten dieser Funktionen? Haben wir versprochen, einige bereits zu liefern?
- Wie würden Sie wissen, ob diese Funktionen fertig sind?
Schließlich neigen die Leute dazu, eine Menge Details auf die Vorderseite der Story Card zu schreiben. Ich habe zwei Vorschläge für diese Leute. Erstens, verwenden Sie kleinere Karten – wirklich. User Stories sind KEINE Spezifikationen oder Anforderungsdokumente. Sie sind nur Karteikarten, die die Bedürfnisse des Benutzers festhalten und daran erinnern, dass wir diese Implementierungsdetails später festhalten müssen. Wenn Sie versuchen, immer mehr auf eine Karteikarte zu packen, könnte das ein Zeichen dafür sein, dass Sie zusätzlich zu den User Stories eine Spezifikation oder eine Art Design-Dokumentation brauchen. Zweitens, die Arten von Details, die man versucht aufzuschreiben, sind eigentlich Abnahmekriterien. Indem wir diese Details in die Testfälle verschieben, halten wir die Geschichte in der Sprache des Geschäfts und behalten den Fokus auf die Funktion und den Wert, den Ihr Team liefert.