User Story richtig formulieren
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.
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 sind, 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 eine 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.
Beispiel „User Story Card“:
User Story Bestandteile und Aufbau
Die User Story
- stellt ein(e) Anforderung/Requirement dar
- folgt einem einfachen, einheitlichen Aufbau
- berücksichtigt INVEST-Kriterien
- hat Akzeptanzkriterien
- hat einen Autor
- hat ein Erstellungsdatum
- hat eine Priorität
- hat eine Komplexität (Story Points)
- gehört zu einer EPIC
- kann Risiken haben
- kann auf User Story Cards festgehalten werden
- kann Testfälle beinhalten
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.