© 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 (Pro...

Neugierig geworden?

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