Wie beschreibt man Anforderungen bei einem Vorgehen, das nicht vom großen Masterplan getrieben ist? Eine recht beliebte Methode aus dem Bereich Anforderungsmanagement sind die sogenannten User Stories. Nicht nur in Scrum beliebt, verhelfen sie in verschiedenen agilen Methoden zu einem besseren Verständnis von Nutzeranforderungen.
Im Vordergrund eines jeden Projekts stehen Anforderungen, die erfüllt werden sollen. Schließlich gibt es die Stakeholder, also die Personen, die gewisse Wünsche und Vorstellungen vom Endprodukt haben. Eine User Story stellt dabei eine Beschreibung solcher Anforderungen in Alltagssprache dar. Das könnte dann zum Beispiel so aussehen:
„Als Gebrauchtwagenverkäufer möchte ich eine Liste der verkäuflichen Gebrauchtwagen und dessen Preisen einsehen können.“
Anforderungen aus Nutzersicht
Die Idee dabei: Die User Stories schildern konkrete Anforderungen aus der Sicht einer bestimmten (Anwender-)rolle. Daher empfiehlt sich für die User Story ein bestimmtes Format:
Als … (Rolle) möchte ich … (etwas tun), um … (Ziel)
Das Format ist in keiner Weise vorgeschrieben – viel mehr geht es darum, dass ein paar wichtige Informationen erkennbar werden:
- Wer hat die Anforderung? (Rolle)
- Welche Anforderung hat sie/er?
- Was möchte er/sie damit erreichen?
Wer jetzt sagt: „In diesem Sinne ist das Beispiel mit dem Gebrauchtwagenverkäufer verbesserungswürdig“ – hat wahrscheinlich Recht. Schließlich wird nur implizit zum Ausdruck gebracht, welches Ziel der Gebrauchtwagenverkäufer verfolgt.
Was hierbei aber dem Verständnis dient, ist die Verwendung einer aussagekräftigen Rollenbezeichnung wie Gebrauchtwagenverkäufer statt abstrakterer Begriffe wie „Nutzer“. So lässt sich vielleicht noch eher nachvollziehen: Aha, der möchte wahrscheinlich wissen, was er verkaufen kann und für welchen Preis.
Logisch, dass die User Stories dabei im Idealfall in enger Zusammenarbeit mit den tatsächlichen Anwendergruppen erstellt werden.
Mehr Verständnis für Nutzeranforderungen
Dabei soll eine User Story gerade nicht in erschöpfender Tiefe geschildert sein, sondern ist viel mehr eine Art Ausgangspunkt, auf dessen Basis die Details ausgearbeitet werden können. Insbesondere gilt: Auf die zu lösenden Probleme statt auf technische Details konzentrieren.
Ein großer Vorteil an User Stories ist, dass sie im Idealfall die Anforderungen an die Funktionalität greifbarer machen.
Das kann für die Entwicklung ein großer Vorteil sein, weil es dem Umsetzenden eventuell leichter fällt, die Perspektive des Anwenders einzunehmen, Sinn und Zweck von Anforderungen nachzuvollziehen, und nicht zuletzt auch deshalb, weil sich gut formulierte User Stories als Ausgangsbasis für Tests eignen.
Ausgangsbasis für Detailarbeit
Von einer User Story ausgehend können schließlich die Details erarbeitet werden. Im Scrum würde dies beispielsweise im Rahmen vom Product Backlog Refinement oder auch Backlog Grooming geschehen, aber natürlich auch im eigentlichen Doing – wenn sich etwa technische Bedingungen herauskristallisieren.
Dabei gilt die Devise: Vom Groben zum Feinen.
Das heißt nach und nach verfeinere ich in Zusammenarbeit mit dem oder den Auftraggebern sowie dem Team das gemeinsame Verständnis von einer Story und reichere es mit Details an. Dabei könnten beispielsweise Akzeptanztests formuliert werden, die Abnahmekriterien in größerem Detailgrad regeln.
In Scrum gilt übrigens: Erst wenn eine User Story ausreichend verstanden ist, kann sie in einen Sprint genommen werden.
Nicht nur in der Softwareentwicklung geeignet
Last but not least noch eine Anmerkung: Aus meiner Sicht eignen sich User Stories nicht nur für Entwicklungsprojekte. Ein guter Einsatzbereich sind meiner Meinung nach zum Beispiel auch Software-Evaluationen – dort sind User Stories einfach konkreter als meist doch eher abstrakt gehaltene Auswahlkriterien.
Weitere Informationen:
Update 14. März 2017: Kaputten Link zu „Warum User Stories helfen, bessere Software zu liefern“ korrigiert.
Warum Scrum (und andere Methoden) nicht der Pfad zur Erleuchtung sind
2 Replies to “Was sind eigentlich User Stories?”