Ich hätt’ da gerne mal ein Problem

How to Scrum: Sind User Stories Anforderung oder Hypothese des Produkts?

Konstantin Diener

© Shutterstock / Profit_Image

Viele Organisation behandeln User Stories wie Anforderungen. Dabei können sie das in einer komplexen dynamischen und postindustriellen Welt gar nicht sein. Fest steht: Wer User Stories verstehen möchte, muss sich erst einmal mit der Produktentwicklung beschäftigen.

User Stories sind heute in der Softwareentwicklung ein gängiger Begriff. Ich habe noch nie mit einem Scrum-Team gearbeitet, das keine User Stories einsetzt. Das ist interessant, weil der Scrum Guide diesen Begriff an keiner Stelle erwähnt. Das Konzept der User Story stammt eigentlich aus dem Extreme Programming und ist zumindest damit einem breiteren Publikum bekannt geworden. User Stories scheinen aber so gut zu Scrum zu passen, dass die allermeisten Scrum-Teams sie verwenden. Diese Teams treibt vor allem die Frage um, wie man User Stories sinnvoll „schneiden“, also in leichtgewichtigere Stories unterteilen kann.

Auf einem agilen Barcamp durfte ich Teilnehmer einer Session sein, die sich genau mit dem Thema „Schneiden von User Stories“ beschäftigte. Einer der Teilnehmer stand am Flipchart, um die Ergebnisse der Session dort zu dokumentieren. Er schlug vor, zum Einstieg kurz zu sammeln, was User Stories eigentlich seien und dann mit den Tipps und Tricks fürs Schneiden zu beginnen. Dazu schrieb er als erstes „User Stories sind Anforderungen“ an das Flipchart, was von den anderen Teilnehmern durch Kopfnicken bestätigt wurde. In mir begannen sich allerdings Zweifel zu regen …

User Stories durch die Produktentwicklung verstehen

Wenn Teams und Organisationen heute von Scrum sprechen, ist meist von Scrum-Projekten die Rede. Dabei ist Scrum eigentlich ein Ansatz, um Produkte zu entwickeln – was man unter anderem daran sieht, dass eine der Rollen Product Owner heißt. Tatsächlich sind viele der Softwareentwicklungsvorhaben auch eigentlich Produkte, die in Form von Projekten weiterentwickelt werden (Kasten: „Viele Projekte sind eigentlich Produkte“).

Viele Projekte sind eigentlich Produkte

Projekte sind laut Definition einmalige Vorhaben. Sie haben einen festen Zeitraum, eine klare Zielvorgabe und ein (festes) Budget. Außerdem werden Projekte von einer temporären Projektorganisation (dem Projektteam) durchgeführt. Diese Organisation löst sich zum Ende des Projekts auf und übergibt das Ergebnis „in die Linie“. Nicht erst seit dem Aufkommen der DevOps-Bewegung und ihrem Mantra „You build it, you run it“ gibt es keine Linienorganisation mehr. Außerdem wird Change nicht mehr als temporär (Projekt), sondern als kontinuierlich (Produkt) angesehen.

Viele Teams haben Kunden die innerhalb derselben Organisation angesiedelt sind (z. B. eine Applikation für eine Fachabteilung). Oft werden in diesem Fall einfach die Wunschlisten dieser Fachabteilung durch das Scrum-Team umgesetzt. Es ist durchaus sinnvoll, auch solche Konstellationen als Produktentwicklung zu betrachten und sich von den (internen) Kunden die Arbeitsweise und Probleme zeigen zu lassen, statt einfach die vermeintlichen Lösungen zu implementieren.

Die zentrale Frage eines Produkts gerät in Projekten gerne in Vergessenheit: Warum entwickeln wir das Produkt überhaupt? Mit diesem Thema beschäftigt sich Jeff Patton sehr intensiv in der Einleitung zu seinem Buch „User Story Mapping“ [1]. Seiner Meinung nach ist die Motivation zur Entwicklung eines Produkts, dass es Menschen gibt, die heute bestimmte Dinge in ihrem Leben nicht oder nur mit hohem Aufwand tun können (siehe auch Abb. 1). Kurz gesagt: Es gibt da draußen Menschen, die ein Problem haben. Ein Produkt ist zunächst mal eine Idee, wie dieses Problem gelöst oder zumindest erträglicher gemacht werden kann. Jedes Mitglied eines (Scrum-)Teams sollte deswegen die folgenden Fragen beantworten können

  • Was ist das Problem?
  • Wer hat das Problem?
  • Was ist unsere Lösungsidee?

Jeff Patton erinnert daran, dass in unserer postindustriellen Welt eine Lösungsidee genau das ist – eine Idee. Wir haben Grund zur Annahme, dass unsere Idee das Problem der Menschen lösen wird, wir wissen es aber nicht. Genau genommen wissen wir noch nicht einmal, ob sie das von uns identifizierte Problem überhaupt haben. Aus diesem Grund bezeichnet Patton alles, was zwischen der Idee und der Auslieferung unseres Produkts passiert, als Output (Softwareentwicklung, Dokumentation schreiben, Tutorialvideos erstellen, …). Das eigentlich Relevante ist aber der Outcome: Schaffen wir es mit unserer Lösungsidee wirklich, das Leben der Menschen (positiv) zu verändern?

Abb. 1: Produktentwicklung nach Jeff Patton (www.jpattonassociates.com)

Diese Frage wirkt vielleicht auf den ersten Blick etwas altruistisch. Andererseits arbeiten die meisten von uns in Organisationen, die Umsatz erwirtschaften müssen, und uns allen ist klar, dass Kunden uns kein Geld für etwas geben werden, das ihnen nicht das Leben erleichtert. Jeff Patton fasst es folgendermaßen zusammen: „Eure Firma bekommt nicht, was sie will, wenn eure Kunden und User nicht bekommen, was sie wollen.“ Wenn wir es schaffen, einen relevanten Outcome bei unseren Kunden zu erreichen, wird das auch für unsere Organisation von Vorteil sein und einen Impact erzeugen [1].

Die Überlegungen über das Problem und darüber, wer dieses Problem haben könnte, münden in der Regel in einer Produktvision. In der Produktvision werden die Zielgruppe, deren Probleme und die Top Features zur Lösung dieser Probleme beschrieben. Außerdem enthält eine Produktvision normalerweise Informationen darüber, wie mit dem Produkt Geld verdient werden soll, wer die Mitbewerber sind und welchen Differenznutzen das Produkt gegenüber diesen Mitbewerbern bieten soll. In Abbildung 2 ist eine Vorlage für Produktvisionen zu sehen, die an das Product Vision Board von Roman Pichler angelehnt ist. Gerne wird zur Beschreibung aber auch das Business Model Canvas [2] verwendet.

Abb. 2: Vorlage für eine Produktvision

Mit Impact Mapping denkt man den Produktnutzen von der eigenen Firma aus

Jeff Patton fängt mit seiner Betrachtung des Produktnutzens beim Kunden an, dessen Leben das Produkt verändern soll. Wenn wir das Leben der Menschen positiv verändern, wird sich auch ein Impact für die eigene Firma einstellen. Diese Betrachtung lässt sich noch auf eine andere Weise ausführen – beginnend mit den Zielen des Unternehmens.

Impact Mapping ist eine Methode, die Gojko Adzic im gleichnamigen Buch [3] beschreibt und die von den Zielen des Unternehmens (für ein Produkt) ausgeht. Für jedes Ziel wird eine Impact Map gezeichnet. Hierbei handelt es sich um eine spezielle Mindmap (Abb. 3) mit dem jeweiligen Ziel (Goal) aus Ausgangspunkt (Grow Mobile Advertising). Auf der zweiten Ebene der Mindmap werden die Akteure (Actors) aufgeführt, die bei der Erreichung des Ziels helfen können (Super-Fans with Mobile Devices). Welches Verhalten (Impact, was etwas anderes meint als der gleiche Begriff bei Jeff Patton) diese Akteure an den Tag legen müssen, damit das Ziel erreicht wird, und was sie für diese Verhaltensänderung (Deliverables) benötigen, das wird auf den Ebenen drei und vier der Map modelliert (Come Back More Frequently, Push Updates).

Abb. 3: Beispiel für eine Impact Map (www.impactmapping.org/drawing.html)

Eine Impact Map ist ein guter Ausgangspunkt für das Product Backlog. Zur Umsetzung werden die Deliverables in User Stories zerlegt. Adzic schlägt vor, so lange User Stories aus dem jeweiligen Zweig umzusetzen, bis der gewünschte Impact erreicht ist, die verbleibenden Stories zu verwerfen und dann mit einem anderen Zweig (anderer Impact oder anderer Actor) weiterzumachen. Durch dieses Vorgehen kommt das Unternehmen mit dem Produkt seinem Ziel sukzessive näher.

Was wir nicht genau wissen, müssen wir durch Experimente herausfinden

Unabhängig davon, ob die Gedanken über den Zweck eines Produkts von den potenziellen Kunden, von den Zielen des Unternehmens oder beidem ausgehen, handelt es sich im Wesentlichen um Annahmen oder Hypothesen (Kasten: „Grundannahmen eines Produkts“).

Grundannahmen eines Produkts

Ich meine, dass es jemanden gibt …
… der ein Problem hat …
… für das ich eine passende Lösung weiß …
… und dass er bereit ist, dafür Geld auszugeben.

Aus der Produktvision bzw. einer Impact Map entsteht idealerweise das Backlog des Produkts. Die im Backlog enthaltenen User Stories sind Verfeinerungen oder einzelne Aspekte der Hypothese(n) aus der Product Vision oder Impact Map. Aus diesem Grund können sie auch keine Anforderungen sein. Anforderungen sind in der Regel so beschrieben, als sei unzweideutig klar, was umgesetzt werden muss, damit auf jeden Fall der beabsichtigte Effekt erzielt werden kann. Genau wie die Produktvision oder Impact Map basiert eine User Story auf Annahmen bzw. Hypothesen („Stories are based on assumptions about business value, and those assumptions might turn out to be wrong.“ [4]).

Das Ziel der Produktentwicklung ist, herauszufinden, ob die Hypothesen zutreffen oder nicht. Dazu müssen wir Experimente durchführen und deren Ergebnisse messen. User Stories sind also nicht nur die kleinen Hypothesen unseres Produkts, sondern auch die dazu passenden Experimente. Der Aufwand für die Umsetzung dieser Experimente ist das, was Jeff Patton als Output bezeichnet. In Scrum-Teams bedeuten Experimente meist, Software umzusetzen. Untersuchungen zeigen allerdings, dass Softwareentwicklung die teuerste Variante zum Verifizieren von Hypothesen ist. Doch auch wenn das Experiment nicht aus Softwareentwicklung besteht, kostet es in der Regel Geld. Da sich die entsprechende Hypothese als falsch herausstellen könnte, ist es also sinnvoll, den Output und die damit verbundenen Kosten so gering wie möglich zu halten. Das Buch „Lean Experimentation in Action“ [5] gibt konkrete Tipps, wie man seine Experimente möglichst klein und günstig gestalten kann.

User Stories als Hypothesen und Experimente zu verstehen, soll an einem konkreten Beispiel verdeutlicht werden. Google Ads (früher AdWords) sind ein einfaches Mittel, um Hypothesen zu Internetprodukten zu überprüfen. Wir hatten eine Ads-Kampagne für eine Plattform geschaltet, die es Benutzern unter anderem erlaubt, ihre Bilder mit unsichtbaren Wasserzeichen zu versehen. Unsere Hypothese war, dass vor allem Fotografen daran interessiert sind, ihre Bilder mit unsichtbaren Copyrightinformationen zu versehen. Zusätzlich kann die Plattform die Bilder im Internet suchen. Die Ads-Kampagne sollte Google-Benutzern, die „Wasserzeichen“ und „Foto“ als Suchbegriffe angaben, unsere Werbung mit einem entsprechenden Text anzeigen. Die Hypothese war, dass die Benutzer die Werbung anklicken würden, wenn sie an Wasserzeichen für ihre Bilder interessiert wären. Zunächst sah es auch so aus, als würde unsere Hypothese zutreffen: Viele Benutzer klickten die Kampagne an. Bei näherem Hinsehen zeigte sich aber, dass 70 Prozent von ihnen unsere Startseite sofort wieder verließen.

W-JAX 2018 Java-Dossier für Software-Architekten

Kostenlos: 40+ Seiten Java-Wissen von Experten

Sie finden Artikel zu Enterprise Java, Software-Architektur, Agilität, Java 11, Deep Learning und Docker von Experten wie Kai Tödter (Siemens), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

Daraus leiteten wir eine neue Hypothese ab bzw., wie sich im Nachhinein herausstellte, eigentlich zwei neue Hypothesen. Vermutlich waren die Nutzer auf der Suche nach den gängigen sichtbaren Wasserzeichen für Bilder und fanden bei uns auf der Seite nicht direkt das, was sie gesucht hatten. Die damit verknüpfte Hypothese war, dass wir die Benutzer nur auf die Vorteile unsichtbarer Wasserzeichen aufmerksam machen mussten, um die Absprungrate von unserer Startseite signifikant zu reduzieren und schlussendlich mehr zahlende Benutzer zu gewinnen. Das Experiment war schnell definiert: Es musste eine neue Startseite her, die über die Vorteile von unsichtbaren Wasserzeichen aufklären sollte. Nachdem wir diese Seite in Betrieb genommen hatten, stellte sich ein unerwarteter Effekt ein: Die Absprungrate erhöhte sich auf deutlich über 80 Prozent. Offenbar war nur die erste unserer beiden Hypothesen richtig gewesen, die zweite aber nicht. Die Benutzer suchten tatsächlich nach sichtbaren Wasserzeichen, ließen sich allerdings von unserer Startseite nicht davon überzeugen, stattdessen unsichtbare zu verwenden. Möglicherweise hatten wir auch das Problem der Kunden falsch eingeschätzt. Sie hatten zwar nach „Wasserzeichen“ und „Foto“ gesucht, wollten aber möglichweise gar keine Copyrightinformationen. Oder es war ihnen zu aufwendig. Es konnte auch sein, dass sie der Meinung waren, die Wasserzeichen kosteten Geld, sie suchten aber einen kostenlosen Service. So ergaben sich aus diesem Experiment direkt die nächsten Experimente.

Das Team sollte nie vergessen, die Ergebnisse seiner Experimente zu messen

Das Beispiel zeigt einen wichtigen Aspekt, der gerne vergessen wird: Nur durch eine sinnvolle Messung ließ sich feststellen, ob das Experiment erfolgreich war und die Hypothese zutraf. Daraus ergeben sich zwei Konsequenzen. Zum einen sollten die Messpunkte zur Überprüfung des Experiments Teil der User Story sein. Entweder gibt es dazu eine eigene Kategorie auf der Story Card oder die Messpunkte werden in die Akzeptanzkriterien aufgenommen – schließlich entscheiden diese Kriterien darüber, wann eine Story abgeschlossen ist. Zum anderen ändert sich die Definition von „abgeschlossen“: Eine Story ist nicht nach dem Ende der Entwicklung beendet, sondern wenn die Hypothese überprüft wurde. Dazu sollte es am Taskboard eine eigene Spalte „in Messung“ nach der Spalte „Entwicklung abgeschlossen“ geben. In dieser Spalte befinden sich alle fertig umgesetzten Stories, für die das Team im Moment Daten sammelt. Die in der User Story beschriebe Hypothese lässt sich oft nämlich nicht sofort validieren. Es ergibt Sinn, mindestens bis zur nächsten Sprint Review Daten zu sammeln.

Die Sammlung von Daten bzw. Messung kann innerhalb der Applikation oder z. B. in Google Analytics stattfinden. Dazu bietet es sich an, die Stories in der Spalte „in Messung“ mit einer Information zu versehen, wann die Änderung produktiv gegangen ist (siehe Abb. 4). Sonst wird es sehr schwierig, nachträglich nachzuvollziehen, ob Veränderungen in den Messdaten mit einer User Story in Zusammenhang stehen.

Abb. 4: Wann ist die Änderung in Betrieb gegangen?

Damit die Kombination aus Umsetzung und Messung funktioniert, ist es wichtig, dass die entsprechenden Änderungen möglichst schnell auf dem Produktivsystem deployt werden – spätestens am Ende des Sprints. Anders lassen sich insbesondere für Internetapplikationen keine aussagekräftigen Daten generieren („Check outcome with real users“ [4]).

Hypothesen und Experimente werden in der Sprint Review unter die Lupe genommen

Wenn das Team eine Änderung in Produktion ausgeliefert und eifrig Messdaten gesammelt hat, ist irgendwann der Zeitpunkt gekommen, um die Messung mit der Hypothese abzugleichen. Im Idealfall führt das Team diesen Abgleich kontinuierlich, spätestens aber zum Ende des Sprints durch. Für diesen Abgleich eignet sich die Sprint Review.

Die Sprint Review dient laut Scrum Guide der Vorstellung der erledigten Backlog Items, um von den Stakeholdern Feedback zu bekommen. Im Idealfall sind unter diesen Stakeholdern echte Benutzer/Kunden des Produkts. Oft wird ein Produkt für eine anonyme Kundschaft im Internet entwickelt und das Scrum-Team kennt seine Kunden nicht persönlich. In diesem Fall passiert es oft, dass das Team seinem Product Owner oder „Vertretern ihrer Kunden“ (Sales, Marketing, Produktmanagement, …) das Produktinkrement vorstellt. Diese Personen treffen allerdings auch nur Annahmen über die Probleme und das Verhalten der Kunden. Sollte es nicht möglich sein, echte Benutzer oder Kunden in einer Sprint Review dabei zu haben, ist es besser, deren Verhalten zu messen und die Hypothesen des Product Owners und des Teams anhand dieser Messdaten einer Review zu unterziehen. Die gewonnenen Erkenntnisse können direkt wieder ins Backlog einfließen (z. B. neue Experimente) und im Planning bearbeitet werde.

User Stories als Hypothesen und Experimente betrachten

Auslöser meiner Gedanken zu User Stories war die eingangs beschriebene Session zum Schneiden von User Stories. Das ist immer wieder ein Thema auf agilen Meetups und Barcamps, weil wir ja gelernt haben, dass eine User Story in einen Sprint passen soll. Diese Faustregel hat damit zu tun, dass wir uns möglichst schnell Feedback holen und nicht zu lange in die falsche Richtung entwickeln sollen. Begreifen wir User Stories als Hypothesen und Experimente, ist es unerlässlich, dass wir uns möglichst schnell Feedback über Messungen einholen – wie ich es im vorigen Absatz beschrieben habe.
Oft sind die User Stories in Scrum Teams zu groß für einen Sprint. Deshalb ist diese Fragestellung ein Evergreen auf Meetups, Barcamps und Konferenzen. User Stories als Hypothesen und Experimente zu formulieren hilft auch dabei, kleinere User Stories zu bekommen:

  • kleineres Experiment: Lässt sich das Experiment in irgendeiner Form mit einem geringeren Aufwand umsetzen
  • Learning vs. Earning: Möchte ich nur etwas über meine Benutzer, meine Technologie o. Ä. lernen oder auch Umsatz generieren?
  • Kundensegment-Drill-Down: Kann ich die Kundengruppe in kleinere Gruppen unterteilen, die unterschiedliche Sichten auf das Problem haben?
  • Problem oder Lösung zerlegen: Kann ich das Problem in einzelne kleine Probleme zerlegen, für die die Lösung einfacher ist? Oder gibt es zu dem Problem möglicherweise eine einfachere Einstiegslösung (Stichwort: Dimensional Planning)?

In der Barcamp Session haben wir dann mehr über das Wesen von User Stories diskutiert und konnten nicht den Bogen spannen, wie Hypothesen und Experimente uns schlussendlich beim Schneiden helfen können. Der Schlusssatz zu diesem Artikel soll Jeff Patton gehören. Er hat in „User Story Mapping“ die Essenz von Produktentwicklung sehr schön zusammengefasst: „Letzten Endes ist es nicht euer Job, alle Anforderungen abgearbeitet zu haben – sondern die Welt zu verändern.“

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: