Das unterschiedliche fachliche und technische Verständnis von Endkunden und Entwicklung führt oftmals dazu, dass der Austausch sehr schwerfällig verläuft oder die beiden Parteien gar aneinander vorbeisprechen. Kommt dir diese Situation bekannt vor? Um Anforderungen an eine Anwendung zu dokumentieren, existieren heute verschiedene Methoden. Eine davon ist die User Story.
Die User Story ist ein beliebtes Werkzeug für die Softwareentwicklung in agilen Vorgehensmodellen. Sie bildet die Brücke zwischen dem Endkunden und der Entwicklung. Wenn du im Umfeld der agilen Arbeitsmethoden tätig bist, dann bist du bestimmt schon mit dem Begriff «User Story» in Berührung gekommen. Mit einer User Story wird eine Geschichte aus dem Blickwinkel des Anwenders erzählt, um eine Funktionalität an eine Anwendung zu beschreiben. Die User Story wird oftmals in einer einfachen Sprache verfasst, so dass sowohl die Fachabteilung als auch die Entwicklung die Beschreibung der Anforderung problemlos verstehen können.
Für das Schreiben von User Stories existieren verschiedene Satzschablonen. Eine davon möchte ich dir in diesem Blogpost vorstellen. Diese Satzschablone besteht aus insgesamt drei Teilen, welche sich mit dem WER, WAS und WARUM auseinandersetzen. Als («WER» – Rolle) möchte ich («WAS» – Funktionalität), um («WARUM» – Nutzen) zu erreichen. Folgend ein Beispiel für eine User Story aus der Finanzbranche:
- Als Bankkundin / Bankkunde möchte ich einen Dauerauftrag (z.B. Kontoübertrag) erfassen können, um den Zahlungsvorgang nicht jeden Monat manuell erstellen zu müssen.
Akzeptanzkriterium definieren die Umsetzungsdetails
Die User Story wird, wie bereits erwähnt, in einfachen Worten definiert, daher besteht oftmals noch grosser Handlungspielraum. Aus diesem Grund lässt sich nur schwer eruieren, ob eine User Story vollständig und korrekt umgesetzt wurde. An dieser Stelle kommen die Akzeptanzkriterien ins Spiel. Die Akzeptanzkriterien definieren aus Anwendersicht allfällige Fertigstellungsparameter, die aus der User Story nicht direkt ersichtlich sind.
Beispiele für Akzeptanzkriterien zur obenstehenden User Story:
- Die Anwenderin / der Anwender kann den Dauerauftrag nur speichern, wenn von ihr / ihm alle Pflichtfelder (Belastungskonto, Gutschriftskonto, Betrag, Periodizität, Gültigkeit) ausgefüllt sind.
- Wenn der im Dauerauftrag festgelegte Betrag auf dem Konto nicht verfügbar ist, dann wird der Dauerauftrag nicht durchgeführt.
Feinschliff dank INVEST-Prinzip
Sehr gut, du hast nun den Kontext zur User Story und die dazugehörigen Akzeptanzkriterien verstanden. Am Ende kann mit dem INVEST-Prinzip geprüft werden, ob deine User Stories einen qualitativ guten Reifegrad erreicht haben. Das INVEST-Prinzip sollte im optimalen Fall mit der Definition of Ready (DoR) des Entwicklungsteams übereinstimmen. Damit ist gewährleistet, dass die User Stories in einen Sprint Backlog aufgenommen und damit zur Umsetzung eingeplant werden können
- Indepentent: Die User Story wird so geschnitten, dass diese unabhängig von anderen Stories ist.
- Negotiable: Der Inhalt einer User Story ist verhandelbar und wird nach und nach detaillierter beschrieben, bis sie in einer Iteration umgesetzt wird.
- Valuable: Die User Story schafft dem Endkunden einen Mehrwert bzw. Nutzen.
- Estimable: Die Entwickler müssen den Aufwand einer User Story schätzen können.
- Small: Die User Story ist so geschnitten, dass sie innerhalb einer Iteration bzw. eines Sprints umgesetzt werden kann.
- Testable: Die User Story besitzt entsprechende Akzeptanzkriterien und lässt sich damit überprüfen.
Fazit
Das benötigte Handwerk für die Erarbeitung von User Stories ist in kürzester Zeit erlernt. Zudem lassen sich User Stories mit wenig Zeitaufwand erstellen und können im Rahmen der iterativen Entwicklung schrittweise detailliert werden.
Weiterführende Links zum Thema
