In der agilen Produktentwicklung setzen wir häufig auf den Einsatz von User Stories. User Stories sind informelle, in Alltagssprache beschriebene Anforderungen an ein (Software-)System. Aber sind User Stories wirklich Anforderungen? Im folgenden Artikel möchte ich mit diesem Vorurteil aufräumen und beschreiben, wie wir zu besseren Produkten mit Hilfe von User Stories und Hypothesenbildungen gelangen.
Der Ursprungsgedanke von User Stories war es, Features einer Softwarelösung aus der Sicht eines Users zu beschreiben. Sie sollte als Erinnerung dienen eine Konversation über ein Problem, eines speziellen Benutzers unserer Software zu führen. Typischerweise hat eine User Story folgenden Aufbau:
Als <Mensch> möchte ich <dies und das tun> um <jenes besser machen zu können>
Viel wichtiger als der Titel der Story ist allerdings die Diskussion über das beschriebene Problem des Nutzers. Dummerweise werden in vielen Projekten User Stories als Einzelteile eines großen Konzeptes betrachtet. Es werden also Feinkonzepte erstellt und in kleine Teile zerhackt. Diese Einzelteile werden dann zu mehr oder weniger holprigen Stories umgeschrieben. Dabei kommen dann mal gerne Stories wie „Als Nutzer möchte ich, dass nach dem Klicken auf den gelben Button ein Formular aufpoppt, in dem ich meine Daten eingeben kann um meine Daten erfassen zu können“ oder „ Als Server möchte ich…“. Das macht nicht nur keinen Sinn es ist auch total unnötiger Aufwand, der dort betrieben wird. Nur weil man agil arbeitet, heißt das nicht, dass man zwangsläufig alles mit User Stories beschreiben muss! Der Scrum Guide erwähnt User Stories bspw. mit keinem einzigen Wort.
Aber zurück zum eigentlichen Thema, warum User Stories Hypothesen sind.
Angenommen wir betreiben einen Online-Shop. Eine User Story in diesem Kontext könnte bspw. lauten:
Als Käufer möchte ich Paypal zur Bezahlung benutzen um meine Bezahldaten nicht extra eingeben zu müssen.
Was heißt es nun, dass wir hier über Hypothesen sprechen? Wir glauben, dass der User ein bestimmtes Bedürfnis hat. Dieses Bedürfnis versuchen wir zu befriedigen. Es handelt sich aber immer um unsere Sicht der Dinge und nicht unbedingt um die eine Wahrheit. Wir glauben, dass der User glücklicher ist, wenn sein Problem gelöst ist. Ob er das tatsächlich ist, entzieht sich komplett unserem Einflussbereich. Ebenso, ob der User tatsächlich die ganze Sache als Problem empfindet. Eventuell ist es ihm aber auch einfach egal.
Wenn man sich jetzt den typischen Aufbau einer User Story noch einmal genau anschaut, stellt man fest, dass eine User Story im Grunde genommen sogar zwei Hypothesen aufstellt. Das wäre zum einen, dass „Was“ der Kunde möchte und zum anderen das „Warum“ er es möchte. Im obigen Beispiel wären die beiden Hypothesen also:
User Stories sind also Hypothesen.
Das Problem ist, dass wir im Laufe eines Projektes sehr viele User Stories und damit Hypothesen aufstellen und umsetzen aber dummerweise in den meisten Fällen diese Annahme nicht mehr überprüfen. Und so landen dann diese ganzen ungenutzten Features im Produkt und fristen dort Ihr Dasein.
Einer Untersuchung der Standish Group zufolge werden ca. 50% aller Features in individuellen Software Lösungen selten bis gar nicht genutzt.
Das bedeutet, dass während der Entwicklung etwa 50% des Budgets in nicht genutzte Features gesteckt wurden. Diese Features haben aber nicht nur keinen Wert, sondern einen negativen Wert. Alle Features, die unser Produkt beherbergt, erzeugen in irgendeiner Form Wartungsaufwände. Es können Bugs, Security Probleme usw. im Kontext dieser nicht genutzten Funktionen auftreten, die behandelt werden müssen. Die Gesamtkomplexität der Software steigt.
Wenn also User Stories Hypothesen sind, haben wir also eine Wahrscheinlichkeit von ca. 50%, dass unsere jeweilige Hypothese zutrifft.
Was was macht man nun mit den aufgestellten Hypothesen? Hypothesen validiert man am Besten damit, dass man kleine Experimente durchführt. Welches Experiment wir durchführen, beschreibt die User Story dankenswerterweise direkt mit.
Wir müssen also einen Mechanismus schaffen, wie wir validieren können, ob die Annahmen die wir getroffen haben stimmen.
Häufig enthalten User Stories sogenannte Akzeptanzkriterien. Dabei handelt es sich um fachliche Fragestellungen, die mindestens bei der Umsetzung der User Story beantwortet werden sollen. Es ist also eine Art Checkliste anhand derer überprüft wird, ob die Umsetzung der Story der gewünschten Fachlichkeit entspricht. Es sollte sich hierbei im Normalfall nicht um einen seitenlangen Prosatext handeln sondern eher um einzelne Sätze, die jeweils einen Punkt beschreiben.
Was leider fehlt, ist ein Mechanismus, der beschreibt, was eintreten muss um festzustellen, ob die aufgestellte Hypothese zutrifft oder eben nicht.
Zu diesem Zweck sollten User Stories neben den fachlichen Akzeptanzkriterien immer auch eine formulierte testbare Hypothese enthalten. Diese Hypothesen können dann messbar gemacht und überprüft werden.
Zu den beiden aufgestellten Hypothesen entwickeln wir nun überprüfbare Kriterien die uns dabei helfen sollen zu entscheiden ob wir auf dem richtigen Weg sind.
Wir glauben, dass der User gerne Paypal benutzen möchte.
Dieser Fall lässt noch recht einfach behandeln. Zur Überprüfung misst man einfach wie häufig die Kunden Paypal während eines bestimmten Zeitraums als Zahlungsmöglichkeit nutzen. Die Überprüfung könnte daher lauten:
Wir glauben, dass wir richtig liegen, wenn in den nächsten 2 Monaten 20% aller Bezahlungen über Paypal abgewickelt werden.
Der andere Teil ist schon etwas schwerer zu überprüfen, in diesem Beispiel aber vielleicht nicht ganz so relevant
Wir glauben, dass der User seine Bezahldaten nicht extra bei uns eingeben möchte
Eventuell ergeben sich beim Aufstellen der Hypothesen sogar Diskussionen darüber, wie sinn- und wertvoll eine User Story tatsächlich ist. Vielleicht haben wir nur den falschen Nutzen beschrieben, vielleicht merken wir beim Aufstellen der testbaren Hypothese aber einfach auch, dass es doch keinen messbaren Nutzen für den User gibt. Passiert das, können wir gegebenenfalls entscheiden, die User Story aktuell nicht umzusetzen, weil der Mehrwert doch nicht so hoch ist, wie gedacht.
Ein guter Zeitpunkt diese Hypothesen und deren Ergebnisse zu besprechen ist im Scrum ein Sprint Review.
Im Review bespricht man alle umgesetzten User Stories, für die man genug Daten gesammelt hat um die aufgestellten Hypothesen zu prüfen. Die Ergebnisse dieser Überprüfung fließen dann in die weitere Entwicklung. Hier können nun weitere Hypothesen aufgestellt werden, wieso eine Hypothese nicht so eingetreten ist, wie gedacht. Eine andere relevante Möglichkeit ist, das Feature durchaus wieder aus dem Produkt zu entfernen weil es keinen relevanten Nutzen hat. Dazu braucht es, vor allem zu Beginn einiges an Mut. Auf lange Sicht entsteht so aber ein wesentlich besseres, kundenfreundlicheres und wartungsärmeres Produkt!
Hat Dir der Artikel gefallen? Dann würde ich mich sehr freuen wenn Du ihn auf Deinen Social Media Kanälen teilst oder uns eine Nachricht zukommen lässt.
Beitragsbild von Annie Spratt auf Unsplash
Mach Dein nächstes Projekt zum vollen Erfolg
Über 70 % aller großen IT-Projekte scheitern, weil die Fehler an der falschen Stelle gesucht werden. Lerne die wahren Erfolgstreiber für Leuchtturm-Projekte kennen.
Im E-Book "Endlich erfolgreiche Projekte" decken wir die 3 Hauptgründe für das Scheitern von Projekten auf!
KOSTENFREIES E-BOOK
Sichere Dir jetzt unser Gratis E-Book "Endlich erfolgreiche Projekte"
