User Stories: Anforderungen aus Nutzersicht dokumentieren

Internet-Anwendungen werden für den Nutzer entwickelt. Punkt. Doch warum werden die Anforderungen an Web-Applikationen so häufig aus einer eher technischen Perspektive beschrieben? Tatsächlich gibt es nämlich ausgereifte Möglichkeiten, Anforderungen aus Sicht der Anwender zu formulieren. Bei der agilen Software-Entwicklung nach dem Scrum-Modell setzt //SEIBERT/MEDIA auf sog. User Stories – Benutzergeschichten.

Die Erfahrung zeigt: Bei der Umsetzung von Software-Anforderungen entstehen insbesondere Herausforderungen im Hinblick auf die Kommunikation zwischen den Nutzern und den Software-Entwicklern. Und die Auftraggeber oder die späteren Nutzer der Software müssen mit den Personen kommunizieren, die die Software realisieren. User Stories stellen eine Verbindung zwischen diesen beiden Parteien her: Sie sind verständlich für den Kunden, die Anwender und für die Entwickler.

User Story = Name, Beschreibung und Akzeptanzkriterien

Eine User Story setzt sich aus 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. (Anhand der Akzeptanzkriterien kann der Kunde später auch die Abnahme einer Anforderung durchführen.)

Im Optimalfall werden die User Stories in dieser Form gleich vom Kunden entwickelt, denn er formuliert sie so, wie es aus seiner Sicht sinnvoll ist. Für das Entwicklerteam ist es dann mitunter zwar etwas schwieriger, die Anforderung zu verstehen. Im Verlauf des Projekts spielt sich das erfahrungsgemäß aber ein.

Das Grundgerüst einer User Story

Für das Schreiben einer User Story kann es hilfreich sein, auf das folgende Grundgerüst zurückzugreifen:

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

Beispiel für eine User Story

Das folgende Beispiel aus unserem Software-Entwicklungsprojekt TwentyFeet soll die Ausgestaltung einer User Story verdeutlichen.

Name der Story: CSV-Export meiner Daten
Beschreibung: Als (Benutzer) möchte ich (die Daten meiner Konten per CSV-File herunterladen können), um (damit außerhalb von TwentyFeet weitere Auswertungen und Berichte zu erstellen).
Akzeptanzkriterien:

  • Ich kann die Daten für jedes meiner Konten herunterladen.
  • Es sind alle Werte in der CSV-Datei enthalten, die ich auch beim jeweiligen Konto bei TwentyFeet einsehen kann.
  • Ich kann die Daten für alle bei TwentyFeet zur Auswahl stehenden Berichtszeiträume ausgeben lassen.

Verfeinerung der User Stories

User Stories können auf verschiedenen Ebenen formuliert sein. In der Regel werden sie zunächst auf einem sehr groben Niveau festgehalten. Wenn sich dann der Zeitpunkt einer Realisierung der Anforderung nähert, wird eine granulare Formulierung und Einteilung vorgenommen.

Häufig entstehen aus einer übergeordneten User Story (Epic genannt) nun mehrere untergeordnete User Stories, die die Anforderungen präzise beschreiben. Dadurch, dass User Stories erst dann verfeinert werden, wenn die Umsetzung näherrückt, müssen neue Anforderungen nicht schon von A bis Z durchdacht werden, wenn noch gar nicht sicher ist, ob sie überhaupt jemals umgesetzt werden.

Die INVEST-Kriterien

Eine gute User Story erfüllt die sog. INVEST-Kriterien. INVEST steht dabei für:

  • Independent: Eine Story ist unabhängig von anderen Stories. Eine Story darf nicht davon abhängen, dass zuerst eine andere Story umgesetzt werden muss.
  • Negotiable: User Stories sind kein geschriebenes Gesetz. Kunden und Entwickler besprechen und präzisieren sie gemeinsam. Während der Kunde also die Funktionalität kurz und grob beschreibt, werden die Details mit den Entwicklern zusammen ausgearbeitet.
  • Valuable: Die Stories sollten einen erkennbaren Mehrwert liefern. Ansonsten gibt es keinen Grund, sie vorzuhalten. Der beste Weg zu wertvollen Stories ist der, sie vom Nutzer selbst schreiben zu lassen.
  • Estimatable: Eine Story muss so überschaubar sein, dass die Entwickler die Umsetzung der Anforderung beschätzen können. Zudem müssen die Entwickler natürlich über die entsprechenden fachlichen und technischen Kompetenzen verfügen.
  • Small: Über den konkreten Umfang von User Stories muss letztlich das Team entscheiden. Stories können „zu groß“ und „zu klein“ sein. Als grobe Regel gilt: Die komplette Umsetzung einer Story soll mindestens einen halben Personentag und maximal zehn Personentage erfordern.
  • Testable: Die Tests bilden den Maßstab dafür, ob eine Story erfolgreich abgeschlossen wurde oder nicht. Daher muss die Testbarkeit zwingend gewährleistet sein.

User Story auf Karteikarte = Story Card

User Stories werden von Scrum-Teams häufig auf Karteikarten festgehalten, um gemeinsam daran arbeiten und sie modifizieren zu können. In diesem Fall sprechen wir von Story Cards.

Über eine Erweiterung der Aufgabenverwaltung JIRA können Story Cards auch einfach aus dem System ausgedruckt werden. Nach der gemeinsamen Überarbeitung und Verfeinerung der Stories werden die zusätzlichen Informationen dann wieder in JIRA übertragen. Unsere Erfahrung zeigt: Die Nutzung der Vorteile von Print-Karten und einem elektronischen System eignet sich am besten bei der Nutzung von User Stories.

Planen Sie ein Software-Projekt? Möchten Sie agile Entwicklungsmethoden in Ihrem Unternehmen etablieren? Haben Sie Fragen zur Anforderungsbeschreibung im Rahmen der Anwendungsentwicklung? Wir beraten Sie gerne und unterstützen Sie in Ihrem Projekt mit unseren als Scrum Master und Product Owner zertifizierten Mitarbeitern. Bitte sprechen Sie uns unverbindlich an.

Weiterführende Informationen

Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
Arbeiten im Scrum-Team: Der visuelle Teamraum
Scrum: Agile Software-Entwicklung bei //SEIBERT/MEDIA
Agile Software-Entwicklung vs. Wasserfall-Modell: Was die Forschung sagt
Scrum in der Praxis: Papier und Jira

Kennen Sie schon Linch & Pin?

Linch&Pin_Banner_gross_Schatten_lang