Entwickler wollen wissen, was sie machen sollen, nicht wie sie es machen sollen. Für letzteres sind sie in der Regel die Experten. Doch wie teilt man Entwicklern mit, was benötigt wird? Was soll als nächstes implementiert werden? Und wie geschieht das in einem agilen Umfeld? Eine geeignete Möglichkeit ist “User Stories” für die Formulierung von Entwicklungsaufgaben einzusetzen.

Ich werde im Folgenden beschreiben, was User Stories sind, wie man mit ihnen plant und warum man sie einsetzen sollte. Ich werde dabei jedoch nicht in die Tiefe gehen, denn damit ließen sich durchaus ein paar Kapitel eines Buch füllen. Statt dessen verweise ich bereits hier auf das Standardwerk zu User Stories von Mike Cohen (siehe Quellen, [1]). Mike Cohen gibt neben einer Abgrenzung zu alternativen “klassischen” Methoden der Anforderungserfassung in seinem Buch vor allem wertvolle Tipps für den Praxiseinsatz. Für einen ersten Eindruck soll dieser Artikel hier genügen.

Was ist eine User Story?

Grundsätzlich kann man sagen, dass eine User Story eine Funktion einer Applikation beschreibt, die “wertvoll” für einen Anwender oder für den Käufer der Software ist. Sie besteht aus einer schriftlichen Beschreibung, aus Gesprächen über die Story und aus Akzeptanztests. Die Beschreibung dient zur Planung und zur Erinnerung; sie ist letztlich eine Zusammenfassung der Anforderung in einem Satz und wird entweder handschriftlich auf Karteikarten verfasst oder in ein elektronisches System wie beispielsweise JIRA eingepflegt. In den Gesprächen werden dann die Einzelheiten der benötigten Funktion herausgearbeitet und schließlich in den Akzeptanztests dokumentiert. Letztere legen auch fest, wann eine Story vollständig implementiert ist. Nicht zu verwechseln ist dies mit einer “Definition Of Done” (DoD, [2]), in der festgehalten wird, wann eine Story als abgeschlossen gilt. Diese drei Aspekte einer User Story hat Ron Jeffries als “Card, Conversation, and Confirmation” bezeichnet [3].

Der Umfang einer Story ist immer ein strittiges Thema. Mir sind schon Entwickler begegnet, die sich beschwert haben, dass nicht alle Details in der Story beschrieben sind. Dann gab es wieder Entwickler, die eine “Story” bearbeitet haben, die die Bezeichnung als solche nicht verdient hat: Die Beschreibung bestand aus einem einzigen Wort und statt Akzeptanztests der Vermerk “wie besprochen” festgehalten wurde. Nun gab es auch Stories, an denen wurde entwickelt und entwickelt und entwickelt … und irgendwann endlich nach einigen Wochen oder Monaten wurde sie als abgeschlossen erklärt. Wie ihr es euch sicher denken könnt, waren das alles Symptome, die auf – sagen wir einmal – nicht optimale User Stories zurückzuführen sind, sei es in ihrer Vollständigkeit oder in ihrem Umfang.

Beschreibung

Fangen wir mit dem zweiten Beispiel an, der Ein-Wort-Story: Sie hätte zum Beispiel lauten können “Sichtbarkeitsregeln”, “Login” oder “Dokumentenähnlichkeit”. Ja, die Beschreibung einer Story soll nur eine Erinnerung sein an die Funktionalität, die implementiert werden soll. Allerdings ist in diesen Ein-Wort-Beispielen der Informationsgehalt doch sehr beschränkt. Wichtig an einer User Story ist, dass bereits in der Beschreibung grob erkennbar wird, was die Funktion ist und dass sie auch einen Wert für den User, also den Anwender und/oder den Käufer der Software hat. Deutlich bessere Formulierungen wäre daher zum Beispiel: “Ein User kann nur Inhalte sehen, die für ihn aufgrund von Regeln sichtbar sind” oder “Das System kann Sichtbarkeitsregeln verarbeiten um dem User nur die Inhalte anzuzeigen, für die er leseberechtigt ist”. In beiden Beispielen lässt sich jetzt bereits in der Beschreibung ablesen, dass es um die Verarbeitung von Regeln geht, die die Sichtbarkeit von Inhalten für den Anwender steuern und diese Steuerung der Sichtbarkeit scheint für den Anwender oder vermutlich eher den Käufer von Wert zu sein. An den beiden Varianten der Formulierung kann man auch schon sehen, das es eine Vielzahl an Möglichkeiten gibt, eine Funktion in einem Satz zusammenzufassen und längst sind damit noch lange nicht die Details geklärt. Manche Varianten sind besser, andere schlechter; jedoch sollte man sich nicht zu lange an der Beschreibung aufhalten und wieder und wieder an der Formulierung feilen – zu Beginn ein gern gemachter Fehler.  Solange eine Funktion beschrieben ist und der Wert für den User erkennbar wird, ist das meiner Meinung nach völlig in Ordnung – schließlich gibt es ja noch zwei weitere Aspekte einer User Story.

Gespräch

Kommen wir nun zum ersten Beispiel, dem Entwickler, dem die Story nicht ausführlich genug beschrieben ist. Hier vertrete ich die Meinung: “Mut zur Lücke”, denn alle Einzelheiten sind beim Erfassen einer Story oft nicht bekannt. Und statt alle Einzelheiten aufzuschreiben macht es viel mehr Sinn, wenn das Entwicklungsteam diese mit dem Kunden oder dem den Kunden vertretenden Product Owner bespricht. Dass dann aus diesem Gespräch wiederum Notizen entstehen, die der User Story hinzugefügt werden (entweder rückseitig auf Karteikarten oder in einem Notizfeld in einem elektronischen System), dagegen spricht überhaupt nichts – im Gegenteil: da sie der Erinnerung an die besprochenen Einzelheiten dienen, sind sie erstrebenswert – dokumentieren allerdings keine vertragliche Verpflichtung. Eine solche Vereinbarung wird mit dem dritten Aspekt der User Story abgedeckt.

Akzeptanztests

Wir sind nun wieder bei der Ein-Wort-Story, genauer gesagt bei deren Vermerk “wie besprochen”. Das Gespräch ist mitunter ein wichtiger, wenn nicht sogar dar wichtigste Aspekt einer User Story. Und doch gibt es berechtigten Zweifel an dem Mehrwert der angesprochenen Notiz. Viel schlimmer ist jedoch, dass nirgends definiert wurde, wann die umzusetzende Funktion als vollständig implementiert akzeptiert wird: die Erwartung an den Entwickler ist somit unklar und die Gefahr besteht, dass wir dadurch eine Story erhalten, die entweder unvollständig implementiert wird oder bei der vom Entwickler hier noch ein Schleifchen und dort noch ein Schleifchen und da auch noch ein bisschen Bling-Bling dazu implementiert wird. Um dem zu begegnen ist die Beschreibung der Erwartung an den Entwickler unbedingt notwendig. Oft wird an dieser Stelle auch von Akzeptanzkriterien gesprochen, die es zu definieren gilt. Da diese Kriterien schlussendlich auch überprüft werden müssen – in der Regel durch automatisierte Tests – spreche ich lieber von Akzeptanztests und auch in der Praxis hat es sich bewährt, die Erwartungen in Form von Aufforderung zu beschreiben, was in dieser Story getestet werden soll. Möglichst vor Beginn der Implementierung sollten diese Erwartungen beschrieben werden: sei es bereits beim Story schreiben, beim Refinement (also der Verfeinerung/Überarbeitung einer Story) oder im Gespräch mit dem Entwicklungsteam. Grundsätzlich können Akzeptanztests jederzeit ergänzt werden – doch sobald die Story von Entwicklern in Bearbeitung ist, dann ist es nur unter Rücksprache legitim und sollte nur erfolgen, solange sich dabei der Umfang einer Story nicht oder nur marginal erhöht. Ist dies nicht der Fall oder wird das durch die Entwickler (begründet) nicht akzeptiert, dann hat es sich bewährt, die neuen Akzeptanzkriterien in einer neuen, ergänzenden Story festzuhalten.

Umfang

Nachdem wir uns mit den drei Aspekten von User Stories beschäftigt haben, möchte ich noch den Umfang einer User Story betrachten. Das obige Beispiel der Story, deren Implementierung sich über Wochen oder Monate hinzieht könnte als Ursache fehlende Akzeptanzkriterien haben. Viel Wahrscheinlicher jedoch ist, dass die Story viel zu umfangreich war, um sie in einer Implementierungsiteration umzusetzen. Umfangreiche und vor allem zu umfangreiche Stories werden häufig als Epics bezeichnet.

Zu Beginn der Erfassung von User Stories sind die Anforderungen an das Gesamtsystem noch unscharf. Epics spiegeln genau diese Unschärfe und sind daher sinnvoll als Platzhalter einzusetzen. Damit können dann größere Teile des Systems solange ausgeblendet werden, bis man sich mit deren Einzelheiten beschäftigen möchte und bis das Verständnis über die Anforderung an diesen Teil klarer geworden sind.

Mit der Zeit können die Epics und andere umfangreich Stories in kleinere Stories aufgeteilt werden. Komplexe Anforderungen werden somit in beherrschbare Teile aufgegliedert. Jedoch sollte man auch darauf achten, Stories nicht zu klein aufzuteilen. Idealerweise sind User Stories für den Entwickler abschätz- und damit auch planbar, wenn deren Umfang in einem halben Tag bis zwei Wochen für Implementierung und Tests von ein bis zwei Entwicklern zu bewerkstelligen ist.

Warum User Stories?

Es gibt einige Gründe dafür, die Anforderungen in Form von User Stories zu erfassen. Wesentlich ist unter anderem der Fokus auf der mündlichen statt schriftlichen Kommunikation. Im Dialog werden in kürzerer Zeit wesentlich mehr Informationen weitergetragen als es mit Dokumenten möglich wäre. Zudem wird auch weniger unnütze Dokumentation erstellt – unnütz ist sie nämlich dann, wenn sie eh keiner liest. Ein weiterer Grund für die Verwendung von User Stories ist, dass sie sowohl vom Kunden, vom Produkt Owner und auch den Entwicklern verstanden werden. Als nächstes wäre da noch aufzuführen, dass sie den richtigen Umfang für eine Planung haben und sie eignen sich für die iterative Entwicklung. Last but not least: User Stories ermutigen zum Auslassen von Details – zumindest solange, bis klar ist, was der Kunde tatsächlich möchte und bis das bestmögliche Verständnis darüber erreicht wurde, was gefordert wird.

In der Softwareentwicklung nach Scrum sind User Stories die meiner Meinung nach geeignetste Form Backlog-Items mit einem Wert für den Kunden oder den Product Owner zu formulieren. In einem meiner nächsten Artikel werde ich noch eine alternative Form von Stories vorstellen, doch zuvor wird es hier noch einen Artikel geben, der sich mit den Eigenschaften einer guten Story beschäftigt und euch auch Tipps gibt, wie man eine gute Story schreibt.

Literatur:

[1] Mike Cohen, “User Stories Applied: For Agile Software Development”, Addison-Wesley Professional; 1 edition (11. März 2004)

[2] Ian Mitchell, “Definitions of Done in Practice”, DZone Agile, https://dzone.com/articles/definitions-done-practice (13. Mai 2015)

[3] Ron Jeffries, “Essential XP: Card, Conversation, and Confirmation”, XP Magazin (30. August 2001)

Grafik: