Gute User Stories sind… Wir geben Tipps aus dem Projektalltag!

Keine Kommentare

Der Begriff der „User Story“ ist heute in aller Munde, doch was ist eigentlich eine User Story? Übersetzt man den Begriff User Story ins Deutsche, so erhält man den Begriff „Anwender Geschichte“. Dieser Begriff ist schon recht passend, denn die User Story ist eine Hilfe, um eine Anforderung eines Anwenders an ein IT-System zu beschreiben. Dabei liefert die User Story mehr als nur die Anforderungsbeschreibung, sondern umfasst ebenfalls die Hintergründe und den Zweck der Anforderung, sozusagen die Geschichte dieser. Auch wenn User Stories zumeist in agilen Projekten angewendet werden, findet sich im SCRUM Guide kein Hinweis auf die Verwendung dieser. Den Ursprung haben User Stories im Extreme Programming (XP), in welchem Kent Beck 1996 bei Chrysler erstmalig Story Cards einsetzte.

Eine gute User Story zu schreiben ist gar nicht so einfach. Deshalb haben wir nachfolgend einige Tipps, basierend auf unseren Projekterfahrungen, zusammengestellt. Wir beginnen mit den Grundlagen und zu denen gehört natürlich auch die korrekte Formulierung.

Die Formulierung

In der Regel werden User Stories entsprechend des folgenden Schemas, basierend auf Rachel Davie‘s „Agile Coaching“, aufgebaut:

Als <Rolle> möchte ich <Wunsch>, um <Nutzen>.

Dieses einfache Schema lenkt den Fokus auf den Anwender und seine Bedürfnisse. Der Wunsch ist möglichst klar und prägnant zu formulieren, damit das Entwicklungsteam die Anforderungen bestmöglich realisieren kann. Neben der expliziten Benennung des Wunsches wird durch die ergänzende Aufnahme des Nutzens in die User Story, der tiefergehende Sinn und Zweck erläutert. Der Grund, auf dem der Wunsch basiert, zeigt die Hintergründe und Umstände auf. Dadurch können die Entwickler den Zusammenhang und die Umstände verstehen.

Abbildung 1: Die Formulierung

Durch Anwendung des oben beschriebenen Schemas wird sichergestellt, dass das Entwicklungsteam sowohl über Wunsch und Nutzen, als auch den zukünftigen Nutzer (die Rolle) informiert ist. Doch es gibt noch weitere Tipps rund um die Formulierung.

Hier ein Beispiel:

„Ich, als Student, möchte meinen Beurlaubungsantrag online ausfüllen und absenden können, um mir den Weg zur Uni zu sparen.“

  • Beschreiben Sie die User Story aus Sicht des zukünftigen Nutzers des Systems.
  • Verwenden Sie ein einfache, leicht verständliche Formulierungen, so dass jeder im Entwicklungsteam sowie der Kunde, in der Lage sind die User Story zu verstehen.
  • Nutzen Sie aktive statt passive Formulierungen.
  • Fokussieren Sie sich auf das Wesentliche und verwenden Sie kurze, prägnante Sätze.
  • Verfassen Sie maximal 2 Sätze pro User Story.

User Stories sollen für den Kunden, ebenso wie für das Entwicklungsteam verständlich sein. Deshalb ist zu beachten, dass eine ausformulierte User Story allein nicht ausreicht. Das Konzept der User Story lässt sich mit den „3 C’s“ beschreiben.

Die 3 C’s – Card, Conversation und Confirmation

Die 3 C’s, zurückgehend auf Ron Jeffries, fassen die Grundregeln zur Erstellung von User Stories gut zusammen. Eine User Story beinhaltet viel mehr als die kurze und prägnante Formulierung einer Anforderung. Zu einer User Story gehören ebenfalls der Austausch zwischen Kunde und Entwicklungsteam sowie, um eine erfolgreiche Bearbeitung der User Story zu gewährleisten, die Definition der sogenannten Akzeptanzkriterien.

„Card“

Eine User Story wird so formuliert, dass sie typischerweise auf eine „Card“ passt. Dieser Punkt beinhaltet die kurze und prägnante Formulierung, so dass auf den ersten Blick alle wichtigen Informationen zu erkennen sind. Ein weiterer Vorteil entsteht dadurch, dass auf Karten formulierte User Stories auch im Rahmen von KANBAN Boards verwendet werden können. So kann der aktuelle Stand der Bearbeitung direkt nachverfolgt werden.

 „Conversation“

Der Punkt „Conversation“ steht für das Kommunikationsversprechen: Es ist jeder Zeit möglich über eine User Story zu sprechen. Eine User Story ist, nicht nur auf Grund ihrer Größe, nicht bis ins kleinste Detail spezifiziert, sondern enthält Elemente über die verhandelt werden kann. Gemeinsam mit dem Kunden und/oder Product Owner (Lesen Sie dazu auch „Ab ins Gedränge!“ Oder, was ist eigentlich Scrum?) kann jederzeit, muss aber mindestens einmal im Projektverlauf, über jede User Story diskutiert werden. So wird ein gemeinsames, gleiches Verständnis der User Story sichergestellt.

„Confirmation“

Eine User Story muss umfassend akzeptiert werden. Ein Hilfsmittel sind die sogenannten Akzeptanzkriterien. Schon während des Verfassens der User Story sollten die Akzeptanzkriterien gemeinsam zwischen Kunden und Entwicklungsteam erarbeitet und präzisiert werden.

Abbildung 2: Die 3 C’s – Card, Conversation und Confirmation

Ob eine User Story bereit für die Entwicklung ist, kann anhand der folgenden INVEST-Kriterien, basierend auf William Wake, überprüft werden.

Die INVEST Kriterien

Gute User Stories sind eine Investition in das Projekt! Denn entscheidend für den Projekterfolg ist ein gemeinsames Verständnis der Anforderungen. Allerdings kann ein umfassendes, detailliertes Verständnis der einzelnen User Stories auch erst im Projektverlauf entstehen. Vor der Umsetzung einer User Story sollten sie auf die folgenden Kriterien überprüft werden.

  • Independent (unabhängig): User Stories sind nicht voneinander abhängig. Eine User Story ist in sich geschlossen und wird nicht von anderen User Stories beeinflusst.
  • Negotiable (verhandelbar): User Stories dienen als Diskussionsgrundlage, um ein optimales, gemeinsames Verständnis zu ermöglichen. Es ist jederzeit möglich neu über User Stories zu verhandeln.
  • Valuable (nützlich): User Stories stiften immer einen Wert.
  • Estimable (schätzbar): User Stories bieten immer die Möglichkeit die Aufwände für die Realisierung abzuschätzen.
  • Small/Sizeable (klein): User Stories sind immer in einem Sprint (Lesen Sie dazu auch „Ab ins Gedränge!“ Oder, was ist eigentlich Scrum?) realisierbar. Sollte eine User Story zu groß für einen Sprint sein, so ist dies ein Zeichen dafür, dass sie weiter unterteilt werden sollte.
  • Testable (testbar): User Stories sollten durch Tests überprüft werden können. Dazu ist es notwendig vorher die schon oben beschriebenen Akzeptanzkriterien zu definieren.

Abbildung 3: Die INVEST Kriterien

Erfüllt eine User Story nicht alle INVEST-Kriterien, so muss solange nachgebessert und angepasst werden, bis alle Kriterien erfüllt werden. Wenn zum Beispiel eine User Story zu groß ist, bietet es sich an die User Story aufzuteilen, dies kann z.B. anhand der Akzeptanzkritierien erfolgen. Eine User Story ist dann zu groß, wenn sie so komplex ist, dass sie nicht in einem Sprint realisiert werden kann.

User Stories in der Praxis

Sowohl in unseren Projekten in Hochschulen, als auch im Mittelstand haben wir in den letzten Jahren eine stärkere Orientierung in Richtung Agilität und agiles Projektmanagement erlebt. In einigen Projekten setzen wir nun bewusst User Stories anstatt detaillierter Anforderungskataloge ein. Unsere Erfahrungen zeigen, dass User Stories für viele Kunden greifbarer und leichter verständlich sind. Durch die Formulierung des Nutzen, also des Anwendungsfalls, versteht der Kunde die Anforderung im Kontext besser und schneller. Wir haben festgestellt, dass es beim Erstellen einer User Story um viel mehr als die passende Formulierung geht. Diese ist die Grundlage für die anschließende Diskussion zwischen Kunde und Entwicklungsteam. Nur dadurch kann ein gemeinsames Verständnis geschaffen werden.

Unsere Empfehlung lautet: Investieren Sie direkt zu Beginn in gute User Stories mit dem Fokus auf dem Kunden!

Quellen

https://www.projektmagazin.de/glossarterm/user-story

Kategorien: Allgemein Bildung und Forschung Mittelstand

Hinterlasse einen Kommentar