Ein Beitrag von Dr. Jörg Beringer, Senior Consultant Human-Centered Design, ProContext USA

Als Trainer für Human-Centered Design (HCD) Methoden erlebe ich in nahezu jedem Kurs eine lebhafte Diskussion darüber, was User Stories sind, woher sie kommen, wozu sie da sind, ob sie dasselbe sind wie User Requirements (Nutzungsanforderungen), und wie sie zum Rest eines Human-Centered Design Prozesses passen. Und so läuft mein gut geplantes Seminar immer wieder schon am ersten Morgen aus dem Zeitrahmen, weil sehr grundsätzliche Fragen aufkommen und auch nach längerer Diskussion nicht unbedingt alles klar ist.

Dann frage ich mich immer, wie es sein kann, dass eine so etablierte Beschreibungsform wie User Stories gleichzeitig so unscharf sein kann und dadurch mehr Fragen aufwirft als Antworten. Deshalb habe ich mich entschlossen, an dieser Stelle aus der Sicht eines Human-Centered Design Experten zusammenzufassen, was der eigentliche Verwendungszweck von User Stories ist und wie sie in Bezug auf den Human-Centered Design Prozess methodisch einzuordnen sind.

User Stories leben im Lösungsraum

User Stories sind integraler Bestandteil der agilen Entwicklungsmethodik, um zu implementierende Bedienfunktionen eines Interaktiven Systems in natürlichsprachlicher Form zu beschreiben und zu priorisieren. Ihre Granularität muss so gestaltet sein, dass die beschriebene Bedienfunktion innerhalb eines Sprints (typischerweise zwei Wochen) vom Entwicklungsteam implementiert werden kann.

Die User Story ist damit ein taktisches Werkzeug, mit dem die Implementierung einer Lösung geplant und gesteuert wird. Mit anderen Worten, die Lösung als solche ist bereits festgelegt - ob mit vorangegangener Anforderungsspezifikation oder ohne. Es geht also nur um die operative Realisierung der Lösung und nicht mehr darum, aus welchem Grund bzw. wie man zur Lösung gelangt ist. Damit wird sehr schnell deutlich, dass eine User Story lediglich die “human-centered Beschreibung” eines (zu implementierenden) Systemmerkmals ist, und nicht ein (zu erfüllendes) User Requirement (Nutzungsanforderung), das durch ein User Need (Erfordernis) begründet ist.

Der Hauptverwendungszweck einer User Story ist, dass sie als “Human-Centered Boundary Object” einer Diskussion zwischen Interessenvertretern (Stakeholdern) dient, in der sich all Beteiligten eine Vorstellung über die Funktionalität eines interaktiven Systems aus Sicht des Benutzers machen können.

Sie ist damit letztendlich eine informelle Spezifikationsform im Lösungsraum, die allen am Prozess Beteiligten helfen soll, nicht nur zu verstehen, was implementiert werden soll, sondern auch warum und mit welcher Auswirkung auf den Benutzer. Man kann deshalb User Stories auch als eine Auflistung der zu implementierenden Bedienfunktionen verstehen, die der Umsetzung bestimmter Nutzungsszenarien bestimmter Benutzergruppen dienen sollen.

Informell beschriebene Empathie versus formale Klarheit

Nun zurück zum Ausgangspunkt. Wir haben uns gefragt, was eine User Story ist und wie eine User Story mit User Requirements zusammenhängt.

Nachdem wir festgestellt haben, dass eine User Story gar kein User Requirement ist, sondern eine empathische Beschreibung einer zu bauenden Bedienfunktion, sind viele Unklarheiten vom Tisch. Wenn da nicht die Best Practice Templates wären, die Product Owner anhalten, eine User Story immer so zu schreiben, dass es so klingt, wie ein User Need (Erfordernis) oder User Goal (Ziel):

Diese aus diesen Satzschablonen resultierende Sprache klingt sehr empathisch, aber entbehrt oft jeder Grundlage, weil die eigentlichen User Needs gar nicht ermittelt wurden. Es sind vielmehr spontan verpackte Beschreibungen der Bedienfunktionen einer angedachten Lösung, die sich rekursiv im Lösungsraum begründen (self-referential) und oft gar nicht auf tatsächlich im Nutzungskontext ermittelte Benutzerziele oder Benutzererfordernisse referenzieren.

User Stories werden üblicherweise erst spät geschrieben, nämlich dann wenn die Realisierung einer Lösung geplant wird. Dadurch besteht die Tendenz, eine zu implementierende Bedienfunktion einfach mit einer Persona und einer empathischen Motivation bzw. einem Ziel anzureichern, ohne sie auf eine lösungsneutrale Nutzungsanforderung zurückzuführen, die durch vorher durchgeführte Nutzungskontextanalysen und einer nachfolgenden Identifikation von Erfordernissen belegt ist.

Folgende Beispiele sollen das veranschaulichen:

Wenn wir also verstehen, dass eine User Story eine informelle emphatische Beschreibung einer zu implementierenden Bedienfunktion ist, und NICHT eine Alternative zu formalen Nutzungsanforderungen, die sich aus im Nutzungskontext beobachteten Erfordernissen ableiten, dann wird deutlich, dass User Stories nicht eine Nutzungskontextanalyse mit Identifikation von Erfordernissen und Nutzungsanforderungen im Sinne eines Human-Centered Design Prozesses ersetzen, sondern im besten Fall auf dessen Ergebnissen aufbauen.

Nun wird auch deutlich, warum die Diskussion über User Stories regelmäßig den Zeitrahmen unseres Trainings sprengt, weil allgemein eine gewisse Konzept-Unsicherheit besteht und die falsche Erwartung, dass eine User Story gleich ein User Requirement sei, diese Konzept-Unsicherheit noch erhöht.

Strukturierung von User Stories

Nachdem wir nun verstanden haben, was User Stories sind und nicht sind, können wir uns noch der Frage widmen, wie man sie denn nun einsetzt, um Bedienfunktionen zu priorisieren und den Scope von Sprints festzulegen.

Eine einzelne User Story beschreibt typischerweise eine Teilfunktionalität, die nicht unabhängig von anderen Bedienfunktionen ist. User Stories sind also nicht unabhängig voneinander, sondern beschreiben eine innerhalb eines Sprints zu implementierende Bedienfunktionalität, die meistens einem größeren Gestaltungsziel dient.

Es gibt dazu diverse Heuristiken (Daumenregeln), wie zum Beispiel “User Story Mapping”, die propagieren, Bedienfunktionen entlang von Aufgaben und Teilaufgaben zuzuordnen, damit die resultierende Lösung eine Aufgabe vollständig abdeckt. Das klingt logisch, ist in der Praxis aber nicht so leicht, wie es sich anhört.

Wenn zum Beispiel ein “Minimum viable Product” (MVP) gebaut werden soll, werden vielleicht viele Teilschritte bei der Beschreibung der Lösung aus Effizienzgründen weggelassen und nur der Idealpfad aus Benutzersicht implementiert. In diesem Fall muss wenigstens der erste Schritt und der letzte Schritt unterstützt werden, damit die zu unterstützende Aufgabe überhaupt in einem MVP Release auftaucht und man eine Evaluierung mit Benutzern durchführen kann.

Insgesamt scheint eine aufgaben-zentrierte Beschreibung nicht immer das Allheilmittel zu sein, weil wir uns ja im Lösungsraum bewegen, und die technische Architektur der Lösung unter der Haube jetzt auch eine große Rolle spielt. Oft müssen unter der Haube bestimmte technische Fähigkeiten als Backend oder Web Service gebaut werden in Vorbereitung eines angestrebten Benutzererlebnisses (User Experience). Einige Sprints werden einfach dem Bauen solcher neuen “Backend Services” gewidmet, die idealerweise im Rahmen eines Human-centered Design Prozesses aus den Nutzungsanforderungen abgeleitet wurden.

Wenn zum Beispiel ein Nutzer eine Meeting-Agenda mit allen Teilnehmern teilen können soll, um die Teilnehmer vorab zu informieren, dann bedeutet das, dass unter der Haube eine Einbindung von “Collaboration Services” erforderlich ist, die erst zu bauen sind, bevor man dann das interaktive System über der Haube bauen kann. Deshalb ist es durchaus zulässig, Sprints nicht nur anhand von “Human-Centered User Stories” zu organisieren, sondern anhand von “System stories”, die eben technischer Natur sein können.

Grundsätzlich ist die Topologie (innere Struktur) eines Nutzungsszenarios anders als die eines (technischen) Lösungsraums. Ein benutzerbezogenes Qualitätsziel (“human-centered quality objective”) wie z.B. “bequem Auto fahren” kann sich in verschiedenen technischen Lösungen und Komponenten des technischen Lösungsraums niederschlagen. Zum Beispiel Federungseigenschaften, Motorstärke, Schallisolierung der Scheiben, Polsterung der Sitze.

Man kann deshalb auch diese strukturelle Inkompatibilität des Problem- und Lösungsraums als “structural Chasm” (Kluft) verstehen, die die Kontinuität eines Human-centered Design Prozesses in Gefahr bringt. Es ist deshalb wichtig, auf die Integration dieser beiden Phasen zu achten.

User Stories tragen einen Teil der Human-Centered Erkenntnisse mit in den technischen Lösungsraum, und helfen die resultierende Lösung aus der Sicht des Nutzers zu verstehen, und diese so zu priorisieren, dass aus Sicht der Nutzer insgesamt eine schlüssige und attraktive Lösung entsteht.

Der Unterschied zwischen “Erledigt” und “Erfüllt”

Werden User Stories nur zum Zweck der Projektsteuerung eingesetzt im Sinne von ToDos für die im Scrum Team arbeitenden Entwickler, dann gilt eine User Story als ‘Erledigt’, wenn die beschriebene Bedienfunktion fachlich vollständig und korrekt ist. Die Erledigung einer Programmieraufgabe (Definition of Done) wird also daran gemessen, ob die zu implementierende Funktionalität vorhanden ist und fehlerfrei ist. Diese Verwendung von User Stories dreht sich innerhalb des Lösungsraums im Kreis, da ein zu implementiertes Feature beschrieben wird und die Erledigung der Aufgabe dadurch gemessen wird, ob das Feature vorhanden ist oder nicht.

Wenn hingegen User Stories aus zuvor erhobenen Nutzungsanforderungen und Benutzer-bezogenen Qualitätszielen abgeleitet sind, dann kann man messen, ob eine Umsetzung einer User Story diese zuvor festgelegte Bedingung oder Fähigkeit “erfüllt”. Nur so ist die Verwendung von User Stories auch eine qualitätsfördernde Methode im Sinne der Erfüllung von validen Anforderungen eines Requirements Engineering Ansatzes. Deshalb ist es wichtig, die idealerweise aus der Nutzungskontextanalyse im Vorfeld gewonnen lösungsneutralenlösungsunabhängigen Nutzungsanforderungen getrennt zu verwalten, um messen zu können, inwieweit die Lösung diese Nutzungsanforderungen erfüllt. Dies ist insbesondere in Produktbereichen wichtig, die regulatorischen Auflagen unterliegen, wie z.B. bei Medizinprodukten, die bei falscher Benutzung das Leben von Patienten bedrohen können.

Auf einen Blick

Die folgende Tabelle fasst die Unterschiede zwischen User Requirements und User Stories zusammen:

Schlussfolgerungen

Beim Schreiben dieses Blogs wird mir jetzt zunehmend deutlich, warum die Diskussion über User Stories so viel Zeit in Anspruch nimmt. Zum einen gibt es viele grundsätzliche Missverständnisse und falsche Erwartungen, was eine User Story ist. Zum anderen benötigt man ein solides Verständnis des Human-Centered Design Prozesses, um zu verstehen, wie agile Entwicklungsmethoden und Human-Centered Design Prozess zusammenpassen und sich gegenseitig ergänzen.

Wesentlich ist, dass Human-Centered Design (HCD) die Basis für eine valide agile Umsetzung liefert. Während User Stories im Lösungsraum leben und sich deshalb mit jedem Redesign verändern können, sind die durch eine Nutzungskontextanalyse identifizierten Anforderungen eher langlebig und können Release bzw. Projekt-übergreifend verwendet werden.

Wir machen es uns bei ProContext deshalb zum Ziel, mit unserem Seminarangebot sowohl das Grundlagenwissen zu Human-Centered Design zu vermitteln, als auch dann in Vertiefungskursen mit der gewonnenen Konzeptsicherheit und einheitlichen Terminologie die Integrationspunkte mit alltäglichen Themen herzustellen wie zum Beispiel das Generieren eines benutzerorientierten Backlogs auf Basis von klaren Nutzungsanforderungen, die im Rahmen einer Nutzungskontextanalysen identifiziert wurden. Damit beruht das Backlog auf empirischen Daten statt auf Annahmen der Projektbeteiligten und kann während eines agilen Projektverlaufs neu priorisiert und im Falle eines Redesigns angepasst werden, ohne den roten Faden zu verlieren.