© Ekaphon maneechot/Shutterstock.com
Sind User Stories eine Anforderung oder die Hypothese eines Produkts?

Ich hätt’ da gern mal ein Problem


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 [1] diesen Begriff an keiner Stelle erwähnt. Das Konzept der User Story stammt eigentlich aus dem Extreme Programming [2] 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 [3]. 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“ [4]. 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, 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?

diener_userstories_1.tif_fmt1.jpgAbb. 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 L...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang