Agile Softwareentwicklung: So erstellen Sie gute User Stories

Die agile Softwareentwicklung fordert Unternehmen heraus, die Qualität ihrer Produkte trotz immer kürzerer Lieferzyklen und wachsender Komplexität aufrechtzuerhalten. Die agile Vorgehensweise in Projekten rückt den Menschen wieder in den Vordergrund: Denn der Nutzen der Software für den Endnutzer steht dabei  im Fokus. Die Anforderungen des Fachbereichs – der  Stakeholder – lassen sich mit Hilfe von sogenannten User Stories definieren. Dieser Beitrag erklärt, wie das geht.

Zwei bekannte agile Vorgehensweisen sind Scrum (nicht der Prozess, sondern das Produkt wird in Einzelteile zerlegt) und Kanban (ist ähnlich wie Scrum, setzt aber einen eher lockeren organisatorischen Rahmen und lässt offen, wie die Entwicklungsschritte konkret aussehen). Die User Stories kommen unter anderem bei diesen Vorgehensweisen zum Einsatz.

Agile Softwareentwicklung: So erstellen Sie gute User Stories

Was sind User Stories?

Eine User Story ist eine kleine Arbeitseinheit in der agilen Vorgehensweise. Wir schreiben sie aus Sicht des Endnutzers. Der Endnutzer kann hierbei der Kunde, der interne Kunde oder der Kollege sein. Sie ist eine Produktbeschreibung aus Endnutzersicht.

Die User Story zeigt auf, welche Funktion und welchen Mehrwert beispielsweise das beschriebene Software-Feature – nach der erfolgreichen Umsetzung durch den Entwickler – für den Endnutzer haben wird.

Warum lohnen sich User Stories?

User Stories ähneln den klassischen Anforderungsplänen. Im Vergleich zu traditionellen Mitteln des Anforderungsmanagements sind User Stories unschärfer und offener formuliert. Sie lassen Raum für Änderungen und helfen dabei, ein System zu entwickeln, das der Kunde wirklich will, und nicht eines, das vor einem Jahr spezifiziert wurde.

Sie beschreiben die Funktionalität eines neu zu entwickelnden Produktes oder einer Dienstleistung. Jede User Story dient hierbei als Ausgangspunkt für Gespräche innerhalb des Teams. Die Entwicklung einer User Story ist daher ein dauerhafter Dialog zwischen den Beteiligten. Der Fokus verschiebt sich damit weg vom Schreiben hin zum Dialog im Sinne des Informationsaustausches und der Zusammenarbeit.

User Stories können unterschiedlich tief auf die Materie eingehen. Mittels einer User Story kann deshalb ein komplettes IT-Projekt beschrieben werden oder ein spezifischer Bestandteil der IT-Anwendung. Eine große User Story bezeichnen wir als „Epic”. Diese unterteilen wir dann in viele kleinere User Stories, damit wir nicht den Überblick verlieren. Die kleineren User Stories beschreiben i.d.R. nur ein Feature. Aufgaben innerhalb einer User story können zusätzlich als „Task“ aufgenommen werden.

Wie Sie eine User Story schreiben

Um eine User Story zu schreiben, identifizieren wir zunächst im Rahmen von Interviews und Workshops mit dem Fachbereich und den Endnutzern, den Kunden, die fachlichen Anforderungen. Im Anschluss diskutieren wir sie und nehmen sie dann in Form von User Stories auf.

Eine User Story beschreibt die gewünschte Funktion im Zielzustand aus fachlicher Sicht. Die geschriebenen User Stories werden anschließend mit dem Fachbereich final abgestimmt, bevor es zur technischen Abstimmung und Umsetzung mit dem Entwicklungsteam geht. So sind die Anforderungen des Fachbereichs für die Entwickler klar formuliert und das Feature kann korrekt entwickelt werden.

Der Business Analyst im Team macht sich meist bereits erste Gedanken zur User Story und formuliert diese als Entwurf, um sie im Workshop zu diskutieren und auszuformulieren. Er schreibt und stimmt hierbei die User Stories mit dem Fachbereich und den Entwicklern ab und klärt beidseitige Rückfragen und Anforderungen. Kunden einzubeziehen, liefert erfahrungsgemäß immer einen wertvollen Input. Deren Input nicht zu nutzen, wäre töricht.

Der Aufbau von User Stories:

  1. Titel der User Story
  2. Beschreibung der User Story (Welchen Nutzen/ Wert erhält der Nutzer?): Als ein “Benutzer” möchte ich “etwas machen/ haben”, damit ich “ein Ziel erreiche”.
  1. Akzeptanzkriterien (Abnahmekriterien, die definieren, welche Kriterien die Lieferung erfüllen muss, um den Anforderungen zu entsprechen.): Angenommen “eine Vorbedingung ist gegeben”, wenn dann “eine Aktion ausgeführt wird”, dann “wird ein Soll-Zustand erreicht.”
  1. Implementierungshinweise (Darstellung von möglichen Abhängigkeiten, Informationen für den Entwickler)
  2. Gegebenenfalls ein zusätzlicher Testcase: Was erwarten wir vom Feature? Was darf nicht angezeigt werden bzw. passieren, wenn ich die Auswahl per Schaltfläche treffe.
  3. Gegebenenfalls ein Mock-up (beispielsweise in Powerpoint) als grafische Unterstützung. Es erleichtert die Vorstellung des Features.

Die Beschreibung der User Story und die Akzeptanzkriterien sind dabei so genau, dass der Entwickler die Rahmenbedingungen kennt („Was“) und gleichzeitig genug Freiheiten bei der Umsetzung („Wie“) hat, das Feature nach den eigenen Vorstellungen zu bauen. Ziel ist es, ein besseres Verständnis davon zu entwickeln, was erreicht werden soll.

Wesentlicher Teil einer jeden User Story sind die Akzeptanzkriterien. Diese beschreiben, welche Kriterien erfüllt sein müssen, damit der Auftraggeber mit dem Ergebnis zufrieden ist und verhelfen dem Team damit zu einem besseren Verständnis darüber, was gewünscht ist.

Zusätzlich wird im Projekt die Definition of Ready (DoR) definiert. Diese sagt aus, wann ein Product Backlog Item (User Story) soweit ausgearbeitet ist, dass es in den Sprint “darf” und somit durch die Entwickler umgesetzt wird. Über die DoR stellen wir sicher, dass die Product Backlog Items (User Stories) ausreichend vorbereitet in den Sprint kommen und während der Entwicklung nicht ständig der Arbeitsfluss unterbrochen werden muss, weil Dinge unklar sind, die das Team nicht selbst klären kann.

Die Entwicklung erfolgt im Sprint und wird dem Fachbereich/Endnutzer anschließend zum Testen zur Verfügung gestellt. Ist die User Story beidseitig vom Fachbereich/Endnutzer und der Entwicklung verstanden, kommt es später kaum noch zu weiteren Iterationen aufgrund von Missverständnissen. Verbesserungen und Verfeinerungen können natürlich jederzeit auftreten, weil die zunächst erdachte Umsetzung sich beispielsweise als nicht praktikabel oder sinnvoll erweist, basierend auf dem Feedback der Nutzer.

Unsere Top-10-Tipps für die erfolgreiche Erstellung der User Stories

  1. Schreiben Sie die User Stories für den Endnutzer.
  2. Verwenden Sie Personas (z.B. Agent, Kundenservice, …), um die richtigenGeschichten für die User Stories zu finden.
  1. Erstellen Sie die User Stories mithilfe des Inputs der Endnutzer.
  2. Halten Sie Ihre User Stories einfach und prägnant (ein Feature pro User Story).
  3. Beginnen Sie mit Epics (große User Story).
  4. Verfeinern Sie die User Stories, bis sie fertig sind.
  5. Beschreiben Sie die Akzeptanzkriterien präzise und vollständig.
  6. Verwenden Sie Paper Cards, um neue Stories zu schreiben, bevor Sie sie in Confluence/JIRA hinzufügen.
  1. Halten Sie Ihre Stories sichtbar und zugänglich (Papier-Tafel und online im Board).
  2. Bleiben Sie kritisch und verlassen Sie sich nicht ausschließlich auf die User Stories.

Lassen Sie uns reden.

Ihr Kontakt bei LionGate: Vlora Bajrami, Senior Consultant