Aufbau, Inhalt, Umfang und Struktur

Eine User Story stellt eine Anforderung dar, die sich aus den Wünschen und Vorstellungen der Stakeholder sowie der Nutzer ableiten lässt. Sie folgt  einem festgelegten Aufbau und soll verständlich formuliert sein. Die Formulierung der  Anforderungen erfolgt durch den Product Owner.  Dieser wird oft von Business Analysten oder Requirement Engineers unterstützt. Die Erhebung erfolgt in Form von Beobachtung, Interviews, Workshops, Walkthrough, etc.

Aufbau einer User Story:

Als <Rolle/Anwender/Persona> möchte ich <Ziel/Wunsch>, um/damit <Nutzen>.

Beispiel:

Als Anwender  möchte ich die Möglichkeit haben, das von mir vergebene Passwort neu zu vergeben, wenn ich es vergessen habe, damit ich mich wieder an dem Portal anmelden und es nutzen kann.

In Bezug auf die Komplexität ist zu beachten, dass die Umsetzung innerhalb eines Sprints möglich ist. Ist das nicht der Fall sollte sie unterteilt werden oder es handelt sich um ein EPIC.

Eine gute User Story erfüllt die INVEST-Kriterien

I = Independent (unabhängig) Soll möglichst nicht von anderen User Stories abhängig sein
N = Negotiable (verhandelbar) So lange das Produkt noch nicht ausgeliefert ist können Änderungen an User Stories vorgenommen werden
V = Valuable (nützlich) Steigert den Wert der Produkts für den Anwender
E = Estimable (schätzbar) Der Aufwand für die Umsetzung muss für das Entwickler Team abschätzbar sein
S = Small (klein) Der Aufwand für die Umsetzung sollte überschaubar sein. Eine User Story sollte innerhalb eines Sprint umsetzbar sein.
T = Testable (überprüfbar) Die vollständige und korrekte Umsetzung sollte anhand von nachvollziehbaren objektiven Kriterien überprüfbar sein.

 

 

Akzeptanzkriterien  für mehr Klarheit

Akzeptanzkriterien verbessern das Verständnis für eine User Story und sind Indikatoren über die messbar ist, wann eine Story vollständig umgesetzt ist.

Beispiel für Akzeptanzkriterien zu der obenstehenden Story:

  • In einer Maske habe ich die Möglichkeit meinen Benutzernamen zu erfassen
  • Nach Eingabe des Benutzernamens und dem Klick auf den Button absenden
    wird eine E-Mail an die zum Benutzernamen hinterlegte E-Mail-Adresse gesendet
  • In der E-Mail-Adresse befindet sich ein Link, der mich auf ein Maske mit der Erfassungsmöglichkeit für das neue Passwort führt
  • Das Passwort muss folgende Konventionen erfüllen: Mind. 8 Zeichen, mind. 1 Sonderzeichen, mind.1 Zahl.
  • Die Änderungsmöglichkeit des Passworts durch den Link in der E-Mail soll auf 24 Stunden nach Versendung begrenzt sein

Ergänzend gibt es die Möglichkeit auch noch Testfälle zu definieren, deren erfolgreiches Bestehen die Voraussetzung für die Abnahme einer Story ist.

Verwaltung und Bestandteile von User Stories

Die Verwaltung der Anforderungen erfolgt im Product Backlog auf „User Story Cards“ und werden dort nach Priorität sortiert. Das kann auf physischen Karten oder virtuelle über eine Applikation erfolgen. Es sollten für den bzw. die nächsten Sprints immer genügend umsetzungsfähige Stories zur Verfügung stehen, so es dem Entwickler Team möglich ist unterbrechungsfrei zu entwickeln.

Beispiel „User Story Card“:

User Story Card Vorderseite
User Story Card Vorderseite

Das zentrale Element im gesamten Scrum Prozess.

Bestandteile und Aufbau

Die User Story

  • stellt ein(e) Anforderung/Requirement dar
  • folgt einem einfachen, einheitlichen Aufbau
  • berücksichtigt INVEST-Kriterien
  • hat einen Autor
  • hat ein Erstellungsdatum
  • hat eine  Komplexität (Story Points)
  • gehört zu einer EPIC
  • hat eine Priorität
  • kann Risiken haben
  • kann auf User Story Cards festgehalten werden
  • hat Akzeptanzkriterien
  • kann Testfälle beinhalten
Die User Story Aufbau und Bestandteile

Braucht man mehr als eine User Story?

Bei komplexen Projekten oder in Teams die sich neu finden haben wir die Erfahrung gemacht dass es sehr hilfreich ist mehr als nur eine User Story zu formulieren. Aus diesem Grund haben wir einen erweiterten Rahmen für die Definition der Anforderungen entwickelt, der immer dann zum Einsatz wenn es komplex wird oder es erforderlich ist eine gemeinsame Linie zu finden. Wir nennen es das Transparency Framwork, da es für mehr Transparenz bei allen beteiligten sorgt und hilft schneller voranzukommen.