Was sind "echte" User Stories?
Den folgenden Artikel habe ich als Mitarbeiter der Firma Aperto am 7. August 2017 auf Medium veröffentlicht
Sinnbild für die Wünsche der Nutzer (Bild von cylonfingers https://flic.kr/p/bNfN1T
Was sind „echte“ User Stories?
Das Wesen von User Stories als Grundlage agiler Entwicklung
User Stories sind die essenzielle Grundlage der agilen Arbeitsweise in unserer Agentur. Sie entspringen den Bedürfnissen und Erwartungen der Endnutzer und beschreiben somit Ziele, die sie durch die Verwendung der Software-Anwendung verfolgen.
Unsere Software-Anwendungen sind Web-Produkte. In der Entwicklung dieser Produkte haben wir die Erfahrung gemacht, wie wichtig es ist, das Wesen von User Stories zu kennen und zwischen „echten“ und Pseudo-User-Stories differenzieren zu können.
User Stories können aus diversen Quellen zusammengetragen werden. Die beste Quelle sind die Endnutzer selbst. Je weniger Mutmaßungen wir anstellen müssen, desto besser treffen wir das, was Endnutzer wirklich wollen. Aus diesem Grund involvieren wir echte Endnutzer, die die adressierte Zielgruppe repräsentieren, in unseren Umsetzungsprozess. Diese Endnutzer begleiten uns im Analyse- und Gestaltungsprozess mittels Design Thinking und beurteilen unsere Entwicklungsergebnisse nach jeder Entwicklungsphase (d.h. Product Reviews nach _Scrum-Sprints_).
Zum Bild: Aus Aussagen echter Nutzer werden User Stories formuliert, die durch den Product Owner und Auftraggeber bewertet werden. Das Entwicklungsteam setzt sie in ein sog. Produktinkrement (also der realen Software-Anwendung) um, welches dann durch die Zielgruppe getestet wird.
Endnutzer sprechen oft ganz natürlich in Form von User Stories, ohne jemals vom Konzept der User Stories gehört zu haben. Sie äußern beispielsweise:
„Ich möchte den Artikel später auf meinem Heimweg weiterlesen können, ohne die Stelle zum Weiterlesen suchen zu müssen.“
„Ich möchte das günstigste Angebot als Erstes sehen.“
„Ich möchte mich mit meinem Facebook-, Twitter- oder Amazon-Login anmelden können, um keinen zeitaufwändigen Registrierungsprozess durchlaufen zu müssen.“
Da bekannt ist, um welchen Endnutzer es sich handelt, kann das „Ich“ in diesen echten User Stories im nächsten Schritt durch die Nutzerrolle ersetzt werden. Die erste User Story sieht dann zum Beispiel wie folgt aus:
„Als angemeldeter Nutzer möchte ich den Artikel später auf meinem Heimweg weiterlesen können, ohne die Stelle zum Weiterlesen suchen zu müssen.“
Da der Entwicklungsstand der Software bekannt ist, können bestimmte User Stories auf die wesentlichen Aspekte im Nutzungskontext umformuliert werden. Bezogen auf das zweite Zitat ergibt sich beispielsweise folgende User Story:
„Ich möchte im Suchergebnis das günstigste Angebot als Erstes sehen, um nicht weiter danach recherchieren zu müssen.“
Aus dem selben Grund kann eine umfangreiche User Story auch in mehrere kleine aufgeteilt werden, da es für das Umsetzungsteam wichtig ist, die Komplexität der Umsetzung einer User Story möglichst gering zu halten. Dies könnte für die dritte User Story beispielsweise zu einer Aufteilung nach Login-Art führen:
„Als unangemeldeter Nutzer möchte ich mich mit meinem Facebook-Login anmelden können, um keinen zeitaufwändigen Registrierungsprozess durchlaufen zu müssen.“
„Als unangemeldeter Nutzer möchte ich mich mit meinem Twitter-Login anmelden können, um keinen zeitaufwändigen Registrierungsprozess durchlaufen zu müssen.“
„Als unangemeldeter Nutzer möchte ich mich mit meinem Amazon-Login anmelden können, um keinen zeitaufwändigen Registrierungsprozess durchlaufen zu müssen.“
Durch die Aufteilung der User Story in drei User Stories, ist es dem Auftraggeber möglich, den Geschäftswert der verschiedenen Login-Arten zu beurteilen, da er der Experte für seine Zielgruppen ist. Handelt es sich bei der Software beispielsweise um eine News-Website, so priorisiert er die Amazon-Login-User-Story vielleicht runter. Falls diese Website jedoch eine News-Website für Amazon-Händler ist, so stellt sich die Priorität ganz anders dar.
Besser als die Aufteilung der Login-User-Story in mehrere kleinere ist es, das dahinterstehende Bedürfnis des Nutzers zu identifizieren und dem Umsetzungsteam den Lösungsweg zu überlassen:
„Als unangemeldeter Nutzer möchte ich keinen aufwändigen Registrierungsprozess durchlaufen, um auf mich zugeschnittene Neuigkeiten zu erhalten.“
Mit dieser User Story hat das Umsetzungsteam die Freiheit zu entscheiden, durch welche Lösung das Nutzerbedürfnis befriedigt werden kann. So kommt das Team vielleicht auf die Lösung, dass die Personalisierung durch ein Cookie anstelle eines Logins besser ist. Der echte Nutzer hatte bei seiner Äußerung die diversen Login-Arten als Lösung im Kopf, aber kannte nicht unbedingt die beste Lösung.
Um sich mit dem Auftraggeber über die geschäftsrelevanten Anforderungen auszutauschen, ist es nicht notwendig, über konkrete Lösungen zu sprechen, da dies die Aufgabe des Umsetzungsteams ist. Er muss lediglich wissen, was seine Endnutzer wünschen und beurteilen, welchen Mehrwert er sich verspricht, wenn dieser Wunsch erfüllt wird.
Erfahrungsgemäß kann es sogar schädlich sein, mit dem Auftraggeber über hypothetische Lösungen zu sprechen. Es ist schwierig und aufwändig genug, mit ihm die Relevanz von Nutzerbedürfnissen in Bezug auf den Mehrwert für ihn abzustimmen. Wenn in dieser Aushandlung zusätzlich über unausgegorene Lösungen diskutiert wird, läuft man Gefahr, das eigentliche Ziel aus den Augen zu verlieren.
Der passende Raum, Lösungen mit dem Auftraggeber zu besprechen, ist die Beurteilung des umgesetzten Ergebnisses im Rahmen einer Product Review.
Solange sich eine User Story noch nicht in Umsetzung befindet, wird sie auf Basis von Nutzerbedürfnissen, Geschäftsinteressen und Umsetzbarkeit fortlaufend verbessert, aufgeteilt, mit anderen zusammengeführt, beurteilt und priorisiert.
Das Umsetzungsteam ist Experte dafür, die User Stories in eine funktionsfähige Softwarelösung zu überführen. Auch kann es die User Stories so anpassen, dass es damit arbeiten kann.
Die Perspektive des Auftraggebers ist also: „Welchen Geschäftswert hat diese User Story für mein Unternehmen?“ Die Perspektive des Umsetzungsteams zur selben User Story ist: „Wie könnte die Umsetzung dieser User Story aussehen und wie komplex wäre diese Umsetzung?“.
Hierin zeigt sich die Stärke des Anforderungsmanagements durch User Stories: Auf Basis derselben User Stories werden das Expertenwissen des Auftraggebers und das des Umsetzungsteams aufeinander abgestimmt, ohne die Perspektive der Endnutzer aus dem Auge zu verlieren. User Stories stellen keine spezifischen Detailanforderungen dar, sondern eine Kommunikationsgrundlage aller Beteiligter. Daher werden sie in kurzen und für alle verständlichen Sätzen formuliert. Dies macht sie überschaubar und den Umgang mit ihnen für alle Beteiligten schnell und zielführend.
User Stories, welche durch echte Nutzerwünsche zustande gekommen sind, ermöglichen demnach folgende positive Effekte:
Kommunikationsunterstützung
Die Wünsche der Endnutzer stehen bei allen Beteiligten im Fokus und gehen über den gesamten Entwicklungsverlauf nicht verloren.
Endnutzer, Auftraggeber, Designer und Entwickler können die User Story leicht verstehen, erkennen deren Sinn und können sich leicht darüber austauschen.
Alle Beteiligten können umgesetzte User Stories in einem gemeinsamen Termin nachvollziehbar prüfen und beurteilen.
Priorisierung
Auftraggeber können die User Stories nach Geschäftswert beurteilen und intern mit anderen Abteilungen abstimmen.
Unwichtige Anforderungen werden frühzeitig erkannt und erst spät (wenn überhaupt) umgesetzt.
Umgesetzte User Stories bieten einen unmittelbaren und wertvollen Nutzen für den Auftraggeber (Geschäftswert) und die Endnutzer (Nutzwert).
Flexible Weiterentwicklung
Da kein Lösungsweg zur Erfüllung der Nutzerwünsche vorgegeben wird, kann die Umsetzung einer User Story potentiell zu jeder Zeit auf Basis des jeweils aktuellen Entwicklungsstands der Software erfolgen.
Da nur wichtige Anforderungen umgesetzt werden, können sich Designer und Entwickler auf das Wesentliche konzentrieren und schnell zu sinnvollen Ergebnissen und Erfolgserlebnissen kommen.
Die Qualitätsprüfung hat durch die Fokussierung auf wichtige User Stories eine klare Grundlage für Testfälle.
In einer lauffähigen Software umgesetzte User Stories sind potentiell direkt veröffentlichbar.
Was sind Pseudo-Stories?
Im Laufe der Zeit hat sich der Umgang mit User Stories in unserem Team gewandelt.
Letztlich hat sich gezeigt, dass es eher hinderlich ist, andersartige sogenannte „Pseudo-Stories“ als User Stories aufzunehmen und zu bearbeiten. Dies waren in der Hauptsache einzelne — im Format einer User Story geschriebene — Aufgaben, die der technischen Vorbereitung, der Vorbereitung von Konzepten und Designs und der reinen Umsetzung von Code dienten.
Diese „Pseudo-Stories“ sind eigentlich keine Stories im Sinne von User Stories, sondern Umsetzungsaufgaben. Hier wird das Prinzip echter User Stories umgedreht. Denn um echte User Stories umzusetzen, ordnen wir ihnen zur Umsetzung Aufgaben zu. Bei den Pseudo-Stories für UX-, UI-, Web-Frontend werden Aufgaben in den Mantel von User Stories gepackt und somit das Wesen und die Vorteile von User Stories missachtet und sogar ad absurdum geführt.
„Ich als Entwickler möchte eine skalierbare, relationale Datenbankstruktur definieren, um künftig alle möglichen Anwendungsszenarien damit abbilden zu können.“
Welchen Geschäftswert hat die Umsetzung einer tollen Datenbankstruktur, ohne dass der Endnutzer diese praktisch nutzen kann? Erst in einem Folge-Sprint könnte er eventuell eine umgesetzte User Story sehen, die in irgendeiner Form die Datenbankstruktur im Hintergrund nutzt. Was ist jedoch, wenn diese Struktur übers Ziel hinausschießt? Sie enthält vielleicht Datenfelder oder ganze Datentabellen, die in der Realität niemals zum Einsatz kommen werden. Vielleicht stellt sich heraus, dass die darauf bezogene User Story im Folge-Sprint irrelevant geworden ist, da die Nutzer die Daten aus einer anderen Quelle beziehen. Zudem könnte es sein, dass es in der Zwischenzeit einen Web-Service eines Datenlieferanten gibt, den man stattdessen verwenden könnte.
In der Regel werden derartige Pseudo-Stories in einen Sprint gepackt, die weitere darauf bezogene „Stories“ enthalten. Darunter ist dann üblicherweise auch die „echte“ User Story. Doch in einem solchen Sprint wird damit ein Wasserfallvorgehen eingeschmuggelt, was letztlich den Fokus auf die Nutzerbedürfnisse verwässert und wodurch es tendenziell zu unnötigen Aufwänden und Abhängigkeiten kommt. Diese kosten Zeit und Geld, ohne einen konkreten Nutzen für den Auftraggeber und Endnutzer zu generieren.
Ziel eines solchen Vorgehens ist es zumeist, im Verlauf eines Sprints alle Umsetzungsbeteiligten, wie Entwickler und Designer, gleichmäßig und kontinuierlich auszulasten. Doch diese Aufteilung blendet den Geschäftswert der User Stories aus und damit einen wesentlichen Aspekt der Produktplanung aus Auftraggebersicht.
Wie gehen wir mit einer komplexen User Story um?
Stellen wir fest, dass eine echte User Story für die Umsetzung in einem Sprint zu komplex ist, so muss sie durch das Umsetzungsteam im Grooming (= Pflege aller wichtiger User Stories) oder spätestens im Planning (= Planung des Umsetzungs-Sprints) entsprechend verkleinert werden.
Bezogen auf das Datenbank-Beispiel (s.o.) genügt es anfangs vielleicht, eine sehr simple Datenbankstruktur aufzusetzen, die alle Anforderungen einer konkreten User Story erfüllt. Vielleicht werden die benötigten Daten lediglich durch eine CSV-Datei bereitgestellt. Sollte es in späteren Sprints weitere auf diese Lösung bezogene User Stories geben, so kann die simple CSV-Lösung entweder komplett ersetzt werden, was nicht schlimm wäre, da sie sehr simpel war, oder um weitere Datenquellen und -strukturen ergänzt werden.
Da nach dem zweiten Agilen Prinzip Änderungen in der Software zu jeder Zeit zum Wettbewerbsvorteil erwünscht sind, ist es absolut legitim, in den folgenden Iterationen komplette Lösungsmodule zu verwerfen und durch geeignete zu ersetzen. Was zunächst nach Verschwendung aussieht, erweist sich häufig als sehr viel robuster und sauberer, da lediglich die jeweils notwendige Komplexität umgesetzt wird und dadurch eine Überschaubarkeit entsteht. In einem Folge-Sprint kann bei der Komplexitätsschätzung einer User Story ohne Weiteres auch ein Refactoring berücksichtigt werden, welches insgesamt die Lesbar- und Wartbarkeit des Codes verbessert. In der Realität kommen solche Fälle nach unserer Erfahrung recht selten vor.
Das folgende Video zeigt sehr schön auf, wie eine User Story aussehen sollte. Es deckt sich mit unserer Erfahrung:
Fazit
Die in diesem Artikel beschriebene Sicht spiegelt die Erfahrung eines stabilen Scrum-Teams wider, welches über mehrere Projekte hinweg an diversen Web-Produkten gearbeitet hat.
Der bisherigen Erfahrung unseres Teams nach sollten User Stories echten Nutzerwünschen entspringen und die Kommunikationsgrundlage zwischen Auftraggebern, Entwicklern, Designern, Qualitätsprüfern und weiteren Beteiligten darstellen. Umsetzungsaufgaben sind stets Unteraufgaben von User Stories und nicht umgekehrt.
Lösungen von User Stories sind das Spezialgebiet des Umsetzungsteams und sollten in Product Reviews nach jedem Sprint mit dem Auftraggeber abgestimmt werden und nicht bereits im Vorfeld. Im Vorfeld können hingegen Ideen und Vorstellungen auf einer groben Ebene besprochen und vor allem die Nutzerbedürfnisse ermittelt und bewertet werden.
Das Agile Prinzip, die funktionsfähige Software als Fortschrittsmaß zu betrachten, ist wichtig und führt zu einer engen Zusammenarbeit aller Fachdisziplinen ohne unnötige Dokumente und Abhängigkeiten zu erzeugen. So wird die Energie auf die Erfüllung der Nutzerbedürfnisse, die in den User Stories formuliert und priorisiert sind, gebündelt.
Themen zur Vertiefung
- Scrum belohnt die Investition mit einer erfolgreichen User Story
- User Stories, Epics & Themes
- User Stories
Weiterführendes Material
Das Agile Manifest
- Werte: Manifest für Agile Softwareentwicklung
- Checkliste: Prinzipien hinter dem Agilen Manifest
Danksagung
Besten Dank an Janko Hofmann, Dominique Duboc, Katrina Braun, Carlo Schulz und Jan-Sebastian Breitlauch fürs Gegenlesen und das konstruktive Feedback.