Wie schreibe ich eine User Story?

User Stories scheinen sich zu einer “State of the art”-Methode zur Formulierung von Anforderungen entwickelt zu haben. Kaum ein Buch über agile Softwareentwicklung, dass nicht auf diese Form der Beschreibung von Anforderungen verweist. Aber: Wie schreibt man eigentlich eine User Story?
Erst einmal zur Beruhigung: User Stories schreiben ist wie Fahrad fahren! Am Anfang ist es ungewohnt und fühlt sich seltsam an. Nach ein paar Versuchen läuft es dann aber wie von alleine und man verlernt es nie!

Nach über einem Jahr der Arbeit mit User Stories kann ich mir kaum noch vorstellen, wie ich mit meinen Teams vorher Anforderungen formuliert habe.

Grundsatz: Formulierung aus Sicht des Nutzers

Ein wichtiger Grundsatz bei User Stories ist, dass sie aus der Sicht eines Anwenders geschrieben werden. Daher werden sie auch frei von technischem Schnickschnack gehalten. Jeder, der am Projekt beteiligt ist, also auch jeder Anwender, sollte sie optimalerweise verstehen können. Hingegen sollte das Entwicklungsteam tolerant gegenüber der Fachsprache der Anwender sein.

3 Bestandteile einer User Story

Eine User Story setzt sich mindestens aus den folgenden drei Elementen zusammen:

  • Einem kurzen, prägnanten Namen.
  • Einer kurzen Beschreibung der Anforderung.
  • Mehreren Akzeptanzkriterien, die die Details ausdrücken und dokumentieren und bei der Klärung helfen, ob eine Story wirklich abgeschlossen ist.

Nach wie vor hilft diese einfache Satzkonstruktion beim Einstieg in das Schreiben einer User Story:

Um (den folgenden Nutzen zu erhalten), möchte ich als (Anwendertyp) (diese Funktion).

Schauen wir uns die drei Teile dieses Satzes noch einmal etwas genauer an.

Name

Eine kurze, prägnante Benennung, die sich die Teammitglieder und die anderen Beteiligten gut merken können. Am besten ist sie so, dass jeder etwas damit anfangen kann, wenn jemand sagt “Wir sollten noch xy umsetzen”. Wir die Anmeldung an einem System kann also die Bezeichnung “Anmeldung” ausreichend sein, wenn das Team versteht, was damit gemeint ist.

Beschreibung

Wer möchte eigentlich etwas?

Es ist möglichst klar darzustellen, von wem die Anforderung überhaupt kommt. Vermutlich am häufigsten anzutreffen sind User Stories mit dem Anwendertyp “Benutzer”. Es kann jedoch deutlich spezifischer zum Ausdruck gebraucht werden, um welchen Benutzer es sich handelt. Z.B. durch eine Ergänzung wie “als Benutzer mit einem Twitter-Account”. Das ist schon ein ganzes Stück spezifischer und hilft allen Beteiligten einzuschätzen, wie groß die Nutzergruppe ist und woher ihr Wunsch kommt.
Wenn das Team mit Personas arbeitet, kann es sinnvoll sein, die bestimmte Persona zu nennen, die im besonderen diese Anforderung hegt.

Warum will er das tun, welchen Nutzen will er erzielen?

An dieser Stelle steht der zu Grunde liegende Nutzen, der erreicht werden soll. Die Idee ist dabei, dass die anschließend beschriebene Funktionalität aus dem Nutzenstreben abgeleitet sein muss. Ein Benutzer will sich z.B. nicht als Selbstzweck bei einer Softwareanwendung anmelden, sondern macht diese nur, um die Kernfunktionen der Software anschließend nutzen zu können.

Durch welche Funktionalität will er den Nutzen realisieren?

In diesem Teil wird dargelegt, welche Funktionalität zur Realisierung des Nutzens implementiert werden soll.

Insgesamt könnte die Beschreibung einer User Story damit wie folgt aussehen:

Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten anmelden).

User Stories können einen sehr unterschiedlichen Grad an Genauigkeit annehmen. Dies hängt auch damit zusammen, wie nah oder weit die Umsetzung der Anforderung ist. Es kann sein, dass die Lösung der User Story noch weitgehend offen gehalten werden soll, oder aber es ist schon eine Entscheidung für eine konkretere Umsetzungsvariante gefallen. Wurde etwa bereits festgelegt, dass in unserer Beispiel-Story die Anmeldung per Twitter-Zugangsdaten mit Hilfe des Protokolls OAuth erfolgen soll, könnte die User Story wie folgt konkretisiert werden:

Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten über das sichere Authorisierungsprotokol OAuth anmelden).

Akzeptanzkriterien

Wie kann festgestellt werden, ob die User Story entsprechend den Anforderungen umgesetzt wurde? Die Akzeptanzkriterien spielen dabei eine besondere Rolle. Sie beantworten die Frage, was getestet werden soll. Eine gute Hilfsregel für die Formulierung von Akzeptanzkriterien ist, dass sie mit “Teste…” anfangen sollten. Beispiele für unsere obige Story könnten sein:

  • Teste die Eingabe eines ungültigen Benutzernamens…
  • Teste die Eingabe eines ungültigen Passworts
  • Teste die Eingabe eines gültigen Benutzernamens und eines gültigen Passworts

Wie stelle ich sicher, dass das Team die User Stories versteht?

Zunächst kann eine gewisse Unsicherheit vorhanden sein, ob das Entwicklungsteam die User Stories in der Form akzeptiert. Hier ist es aber wie mit vielen anderen Dingen in der agilen Softwareentwicklung. Es gehört Mut dazu, Dinge auszuprobieren und sich einzugestehen, dass am Anfang nicht alles rund läuft. Inspect and adapt. Nach ein paar Wochen der Arbeit mit User Stories haben dann alle Beteiligten eine gemeinsame Vorstellung davon entwickelt, wie umfangreich, detailiert und sauber die User Stories ausgearbeitet werden müssen. Das funktioniert am besten, wenn darüber hinaus regelmäßige Backlog Grooming-Sitzungen durchgeführt werden, in denen mit dem Entwicklungsteam und Anwendern zusammen an den Stories gearbeitet wird.

Ergänzende Beschreibungen, Mock-ups, Wireframes,…

Ergänzt werden können diese drei Grundelemente einer User Story durch weitere Informationen, die dem Entwicklungsteam dabei helfen zu verstehen, wie die Umsetzung erfolgen soll. Das können ergänzende Beschreibungen, Mock-ups, Wireframes, Scribbles … you name it … sein. Das wichtigste ist, dass diese das gemeinsame Verständnis der Anforderung unterstützen. Sie sollten aber niemals die persönliche Kommunikation zwischen den Beteiligten ersetzen!

Weiterführende Informationen:

Foto: kmlz

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

About these ads

Userstories: Volle Konzentration auf den Kundennutzen

Ein zentraler Vorteil der Verwendung von Userstories für die Beschreibung von Anforderungen ist es, den Kundennutzen stark in den Vordergrund zu stellen. Wofür wird eine Funktion eigentlich entwickelt? Das sollte allen Beteiligten stets präsent sein.

Ein weiterer Vorteil von Userstories ist, dass Stories schreiben eine Übungssache ist und sich von jeder Person erlernen lässt. Vereinfacht wird der Einstieg in das Schreiben von Userstories durch Vorlagen für den Satzbau.
Bisher habe ich meist diese sehr gebräuchliche und verbreitete Vorlage für das Schreiben von Nutzerstories verwendet:

Als (Anwendertyp) möchte ich (folgende Aktion durchführen), um (dieses Ziel zu erreichen).

Für diesen Aufbau einer Userstory finden sich verschiedene Referenzen. Ich habe auch sehr gute Erfahrungen damit gemacht. Der große Fortschritt gegenüber vorher von uns verwendeten Arten der Anforderungsbeschreibung ist u.a. darin zu sehen, dass die Stories für jeden verständlich sind und der Kundennutzen klar ausgedrückt werden muss.

Aus einem Gespräch mit einem Kollegen und ScrumMaster habe ich lernen dürfen, dass eine leichte Modifikation des Aufbaus der Userstory dabei hilft, den Kundennutzen noch stärker in den Fokus zu rücken. Das sieht dann wie folgt aus:

Um (den folgenden Nutzen zu erhalten), möchte ich als (Anwendertyp) (diese Funktion).

Den Fokus auf den Kundennutzen zu richten ist wichtig und richtig. Daher werde ich zukünftig auch diese Vorlage verwenden.

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: CannedTuna

Die besten Ressourcen zu User Stories

Userstories sind eine besondere Form der Anforderungsbeschreibung, die sowohl Kunden, Anwender, Projektmanager als auch Softwareentwickler verstehen können. Besonders gerne werden sie in der agilen Softwareentwicklung eingesetzt. Dieser Beitrag gibt einen Überblick über die besten Artikel und Bücher zum Thema User Stories:

Deutschsprachige Artikel

Englischsprachige Artikel

Buchtipps:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Englische Version des Artikels

Produktmanagement Lesetipps: Überblick agiler und schlanker Methoden, die Rolle des Product Owners, 10 Tipps zur Backlogpflege, Sprint-Retrospektiven, Usertests

Diesmal mit einem Überblick über agile und “schlanke” Methoden, Ken Schwabers Forderung nach “richtigen” Product Owner, 10 Tipps für die Product Backlog-Pflege, kurzweilige Sprint-Retrospektiven, erfolgreiche Usertests und die 3Cs von Userstories.

  • Was hat es mit XP, Scrum und Kanban auf sich, wie unterscheiden sie sich voneinander? Bei The Agilista PM gibt es einen Überblick über agile und “schlanke” Methoden.
  • Ken Schwaber macht sich Gedanken über die Art, wie derzeit die Rolle des Product Owners gelebt wird. Viele Produktmanager nehmen sich von der Rolle aus und lassen einen Business Analyst die entsprechenden Aufgaben erfüllen. Er sieht die Ursache darin, dass die Entwickler sich einen Product Owner wünschen, der ihnen gut vorbereitete User Stories liefert. Viel wichtiger erscheint ihm jedoch jemanden zu haben, der den Business Value richtig vorantreiben kann. Dies kann auch als Warnung an alle Product Owner gelten, die sich zu stark darauf fokussieren, den Entwicklern die richtigen Häppchen vorzuwerfen und dabei das Produkt und den Nutzen der User aus dem Auge verlieren.
  • Roman Pichler bietet in seinem Blog 10 Tipps für die Pflege von Product Backlogs, die insbesondere Scrum Product Owner lesen sollten.
  • Wenn sich nach vielen gemeinsamen Sprints Routine im Team breit macht, ist es förderlich, für Variationen im Ablauf der Sprint-Meetings zu sorgen. Eine Idee, wie sich Sprint-Retrospektiven interessanter und kurzweiliger gestalten lassen, gibt es im Projekt-Log.
  • Auf vier vergessene Prinzipien von Usertests verweist Userfocus. Bei der Beobachtung mehrerer Usertests ist David Travis auf einige Dinge gestoßen, die sich negativ auf das Ergebnis des Tests auswirken. Ein kleiner Reminder für alle, die sich mit Usertests beschäftigen.
  • Was gilt es beim Schreiben von Userstories zu beachten? Weiterhin gelten die 3Cs für Userstories von Ron Jeffries aus dem Jahr 2001: Card, Conversation und Confirmation. Ein Einstieg für Produktmanager, die sich neu mit User Stories beschäftigen.

User Stories schreiben ist wie Fahrrad fahren


Schon einmal versucht, jemandem zu erklären, wie man Fahrrad fährt? Macht nicht wirklich Sinn, oder? Man muss einfach üben, üben, hinfallen, weiter üben.

So ähnlich ist das auch mit dem Schreiben von User Stories. Diese Form der Anforderungsbeschreibung lässt sich natürlich grundlegend auch rein verbal erklären. Eine User Story besteht aus einem Namen, einem beschreibenden Satz und einer Reihe von Akzeptanzkriterien. Aber gute Stories schreiben lernt man nicht durch eine Erklärung. Das ist genau so ein Balanceakt wie Fahrrad fahren. Die Stories sollen weder zu ungenau, noch zu detailliert, weder zu groß, noch zu klein sein. Übung im Schreiben von User Stories an sich und der Austausch mit dem Team ist dabei unerlässlich. Das Team wird in der Regel sehr deutlich kommunizieren, welcher Detaillierungsgrad einer Story ausreichend ist und insbesondere, wenn er es einmal nicht ist. Ein Anforderungsworkshop mit dem gesamten Team zum Start des Projektes kann helfen, sich aufeinander einzuspielen.

Im Laufe des Projekts entwickelt sich eine gemeinsame Sprache zwischen den Beteiligten, die zu einer Vereinfachung der Zusammenarbeit führt und es damit gerade auch jenen leichter macht, die in dem Projekt einen großen Teil der Stories schreiben.

Aber am Anfang steht: der Anfang. Wie beim Fahrrad fahren. Der Mut wird belohnt.

Weitere Informationen zu User Stories:

Foto: Von Bruce McAdam

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Buch Review: User Stories Applied von Mike Cohn

Userstories sind eine besondere Form der Beschreibung von Anforderungen in Software-Entwicklungsprojekten. An die Stelle einer technischen Beschreibung oder Anforderungsliste tritt eine “Geschichte” aus der Perspektive des Nutzers, die auch Nicht-Technikern ein Verständnis und eine Wertschätzung ermöglichen.

Wie Userstories in der Praxis richtig angewendet werden können, lässt sich mit Hilfe des Buches “User Stories Applied” erlesen. Der Autor des Buches Mike Cohn ist einer der absoluten Top-Experten im Bereich agile Softwareentwicklung. Er hat ein hilfreiches Werk für Einsteiger und Auffrischer geschaffen.

Mehr von diesem Beitrag lesen

Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 1.134 Followern an

%d Bloggern gefällt das: