•  
  •  
  •  
  •  
  •  
User Stories in agilen Frameworks

Die 5 häufigsten Fehler beim Schreiben von User Stories

Gute User Stories zu schreiben ist kniffliger, als man denkt. Wir zeigen, welche 5 Fehler Product Owner beim Verfassen von User Stories am häufigsten begehen – und geben Tipps, wie man es besser macht.

04.09.2019Text: bbv0 Kommentare
User Stories
  •  
  •  
  •  
  •  

Gerade in agilen Frameworks wie Scrum sind User Stories ein beliebtes Mittel, um Software-Anforderungen festzuhalten. Der Product Owner – idealerweise vom Kunden bereitgestellt – formuliert sie und vermittelt sie dem Entwicklungsteam, damit es diese Summe an Anforderungen – den Product Backlog – schrittweise abarbeiten kann. Der Product Owner nimmt dabei die Priorisierung der einzelnen User Stories vor und trägt die Budget-Verantwortung für das Software-Produkt. Ausserdem ist er derjenige, der die Bedürfnisse der End-Nutzer genau kennt. Deshalb kommt ihm eine zentrale Rolle in der agilen Software-Entwicklung zu – und den von ihm formulierten User Stories: «Der Product Owner muss mit den User Stories seine Intention, seine Bedürfnisse ausdrücken können», erklärt Marko Marković, Senior Software Engineer bei bbv. «Gelingt ihm das nicht, könnte das Entwicklungsteam die User Stories falsch verstehen. Um die Missverständnisse wieder zu korrigieren, müssen Nachbesserungen vorgenommen werden. Für die Entwickler bedeutet das einen erhöhten Arbeitsaufwand und somit einen Verlust wertvoller Entwicklungszeit, und für den Kunden unter Umständen steigende Kosten.»

Auch wenn sie normalerweise kurz ausfallen und auf einer Karteikarte Platz haben, ist das Verfassen von guten User Stories keine leichte Aufgabe. Diese 5 Fehler werden beim Formulieren von User Stories am häufigsten begangen:

1. Zu grosser Umfang

Oftmals werden User Stories zu gross formuliert. Das hat zur Folge, dass ihre Umsetzung sehr lange dauert und Features umgesetzt werden, die eigentlich gar nicht gefordert waren. User Stories sollten deshalb möglichst klein sein: «Lieber mehrere kleine User Stories, als eine grosse», hält Marković fest. «Kleinere User Stories fokussieren sich auf einen bestimmten Aspekt und lassen sich besser schätzen. Dies führt zwar in gewissen Fällen zu Abhängigkeiten, erhöht jedoch die Flexibilität des Product Owners, da er sekundäre Funktionalitäten tiefer priorisieren kann.»

2. Das Problem wird nicht richtig vermittelt

Versteht das Entwicklungsteam das Problem hinter einer User Story nicht, sondern sieht in ihr nur einen Lösungsansatz, kann das die weitere Software-Entwicklung erschweren. Im schlimmsten Fall geraten Entwickler dadurch in eine Sackgasse, weil sie sich andere Lösungswege verbaut haben. Deshalb steht bei der Formulierung von User Stories das Problem, und nicht etwa der Lösungsansatz im Vordergrund.

3. Verweise aufs Anforderungsdokument

Wenn sich User Stories lediglich auf Anforderungsdokumente beziehen, bringen sie dem Entwicklungsteam wenig. Marko Marković macht ein Beispiel: «Eine User Story, die sagt, man solle den Warenkorb eines Onlineshops gemäss dem 20-seitigen Paragraf XY des Anforderungsdokuments umsetzen, ist nicht hilfreich, weil so der Austausch mit dem Product Owner völlig untergehen kann.» Das Ganze erschwert sich, wenn sich das Anforderungsdokument während der Entwicklungszeit ändert. «So jagt man beweglichen Zielen hinterher – was die Software-Entwicklung deutlich erschwert.». Bei User Stories steht der Dialog zwischen dem Produkt Owner und dem Entwicklungsteam im Vordergrund, und nicht etwa Anforderungsdokumente.

4. Festhalten nicht-funktionaler Anforderungen

Software-Charakteristika wie Sicherheit, Bedienbarkeit, Performance etc. sind Rahmenbedingungen von User Stories. Schreibt etwa eine User Story vor, dass die Software sämtliche Anfragen in 5 Sekunden abarbeiten soll, kann dies einen erheblichen Einfluss auf die Architektur der Software haben. Unter Umständen muss die ganze Software untersucht und entsprechend optimiert werden. «Nicht-funktionale Anforderungen sollten daher als Rahmenbedingungen verstanden werden, die für sämtliche User Stories gelten», erklärt Marković. «Es ergibt keinen Sinn, zuerst eine User Story rein funktional umzusetzen und alle nicht-funktionalen Anforderungen wie Bedienbarkeit und Performance mit einer zweiten User Story zu adressieren.»

5. Konkrete Lösungswege

User Stories schildern ein Bedürfnis – und nicht dessen genaue Umsetzung. Sie sollten als Diskussionsgrundlage für den Product Owner und das Entwicklungsteam verstanden werden. Findet das Entwicklungsteam einen eleganten, effizienten Weg zur Lösung eines Problems, so muss dieser dem Product Owner vorgeschlagen werden können. Er kann auf diese Weise viel mehr Einfluss auf das Produkt nehmen, Aufwände besser abschätzen und Priorisierungen leichter vornehmen. Die Wahrscheinlichkeit, dass die Software-Lösung schliesslich so umgesetzt wird, wie vom Kunden gewünscht, ist um ein Vielfaches grösser.

User Stories richtig schreiben

Inzwischen gibt es verschiedenste Guidelines, die erklären, wie User Stories richtig aufgebaut werden sollten. In der Regel empfehlen sie aber alle, bei der Formulierung immer demselben Muster zu folgen:

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

«Als Webshop-Kunde möchte ich zu einem Artikel eine Bewertung sehen, um einen besseren Kaufentscheid fällen zu können» wäre ein Beispiel einer guten User Story: Das Problem steht im Vordergrund – sowie der Nutzen, der entsteht, wenn man dieses Problem löst. Das Ziel ist präzise formuliert, ohne aber konkrete Lösungsvorschläge vorzugeben. Ob beim genannten Beispiel etwa eine Stern-Bewertung, eine Notenbewertung, ein Diskussionsverlauf oder ein anderer Lösungsansatz am sinnvollsten ist, entscheidet der Product Owner im Gespräch mit dem Entwicklungsteam – je nachdem, wie viel Aufwand für das Feature betrieben werden soll.

«Als Webshop-Kunde möchte ich meinen Warenkorb verwalten können» wäre dagegen ein Beispiel einer schlechten User Story. Nicht nur fehlt der konkrete Nutzen. Auch ist das Ziel ungenau formuliert: «Verwalten kann hier vieles bedeuten – einen Warenkorb anlegen, anschauen, bearbeiten, leeren etc.», erklärt Marko Marković. «Solche vagen Formulierungen sollten möglichst vermieden werden.»

Die Umschreibung «Als Webshop-Kunde möchte ich bei Produkten mit einer Lieferfrist von mehr als 5 Tagen ein rotes Ausrufezeichen links vom Produktbeschrieb sehen, um über Lieferverzögerungen informiert zu werden» eignet sich auch nicht als User Story, da bereits ein konkreter Lösungsweg vorgegeben wird. Das Entwicklungsteam wird dadurch zu stark eingeschränkt und kann dem Product Owner keine weiteren Lösungsvorschläge unterbreiten.

User Stories nach INVEST

Das INVEST-Modell fasst die wichtigsten Kriterien einer guten User Story zusammen. INVEST ist ein Akronym und steht für:

Independent: User Stories sollten möglichst unabhängig von anderen User Stories sein.

Negotiable: Die genaue Umsetzung der User Story muss diskutier- und verhandelbar sein. Das Entwicklungsteam tauscht sich dazu mit dem Product Owner aus.

Valuable: Jede User Story muss dem Anwender einen Mehrwert bringen. Sonst ist es keine User Story.

Estimatable: Der Umfang einer User Story muss abschätzbar sein, damit der Product Owner entscheiden kann, ob bzw. wie viel Aufwand dafür betrieben werden kann.

Small: Eine User Story sollte so präzise und klein wie möglich sein und nicht versuchen, mehrere Funktionalitäten zusammenzufassen.

Testable: Eine User Story sollte testbar sein. Man sollte beim Feature überprüfen können, ob es auch wirklich funktioniert – und dem Nutzer einen Mehrwert bringt.

Der Experte

Marko Marković

Marko Marković ist Senior Software Engineer bei bbv. Als Verfechter bewährter Prinzipien wie Clean Code, TDD und Pair-Programming legt er grossen Wert auf qualitativ hochwertige Softwareentwicklung. Seine Erfahrungen gibt Marković an Schulungen der bbv Academy weiter.

Unser Wissen im Abo

Software Development Quality

Schatzkarte für Entwickler-Teams

Softwareentwicklung
Veranstaltung in Luzern

Global Day of Coderetreat: Programmierleidenschaft pur

Softwareentwicklung

Artikel kommentieren

Die E-Mail-Adresse wird nicht publiziert. Notwendige Felder sind mit einem * versehen.