Agile Methode: User Story (User Story, Nutzergeschichte, User Storys)
User Storys werden in allen agilen Systemen verwendet. Wenn ein Unternehmen agil arbeitet, dann ist die Verwendung von User Storys schon fast eine Pflicht. Die Methode der User Story kann auch in vielen anderen Zusammenhängen genutzt werden, so z.B. in dem Anforderungsmanagement des klassischen Projektmanagements oder Produktmanagements.
Die Aussage, die sich im Zusammenhang mit Agilen Methoden ständig findet: "Anforderungen dürfen im klassischen Projektmanagement nicht geändert werden", ist einfach falsch. In allen Projektmanagement Systemen gibt es ein Anforderungsmanagement. Teil dieses Anforderungsmanagements ist immer ein Änderungsmanagement, in dem ein Prozess für das Ändern von Anforderungen festgelegt wird. Im "klassischen Projektmanagement" dürfen Anforderungen also durchaus geändert werden. Es besteht lediglich eine Notwendigkeit, diese Anforderungsänderungen von den Entscheidern genehmigen zu lassen. Das ist, wenn agil gearbeitet wird, aber nicht anders.
Anforderungen stellen in den Agilen Systemen einen Handlungsspielraum dar, der verändert werden kann, um geschäftliche Ziele zu erreichen. Wenn neue Erkenntnisse während der Entwicklung entstehen, die darauf hinweisen, dass das Kosten-Nutzen Verhältnis einer Anforderung ungünstiger ausfällt als ursprünglich gedacht, muss diese Anforderung angepasst werden. Genau diese Forderung findet sich auch in allen klassischen Projektmanagement Systemen.
Im Scrum muss am Anfang eines Leistungserstellungsprozesses nur ein geringer Aufwand betrieben werden, um die Anforderungen im Voraus zu entwickeln. Alternativ können auch Platzhalter im Product Backlog festgelegt werden, die erst im Verlauf des Projektes mit Inhalten gefüllt werden.
User Storys sind nur ein "Platzhalter" in einem Product Backlog für Anforderungen. Diese Anforderungen sind für ein gemeinsames Verständnis zwischen Team und Stakeholdern über die zu erstellende Leistung notwendig. Dieses Verständnis entsteht durch die Kommunikation über die zu erstellende Leistung in einer Face to Face Kommunikation und häufige Feedback Schleifen in Form von Rückfragen und Reviews.
Hier liegt der große Unterschied zwischen dem "klassischen Umgang mit Anforderungen" und einem agilen Vorgehen. Viele Anforderungen in "klassischen Projekten" werden von Spezialisten in Zusammenarbeit mit den Stakeholdern geschrieben. Leider verändern diese sich mit der Zeit oder sind für Entwickler nicht zu verstehen. - Aber die Anforderer haben ihre Arbeit getan und wollen mit Rückfragen nicht mehr belästigt werden. Die Entwickler haben gefälligst das zu tun, mit dem sie beauftragt sind und die Anforderer nicht mehr zu stören. Immerhin haben die Anforderer viel Geld ausgegeben, um die Anforderungen von Beratern richtig formulieren zu lassen.
Wenn der Anforderer jetzt im Sinnes des Agilen Managements von den detaillierten Anforderungen zu leicht und schnell zu erstellenden User Storys wechselt, dann glaubt er, alles getan zu haben - und lehnt sich, seinen bisherigen Gewohnheiten entsprechend, zurück, in der Erwartung, das geliefert zu bekommen, was er glaubt bestellt zu haben. User Storys sind für ihn das ideale Mittel, um seinen eigenen Aufwand zu minimieren, denn User Storys sind wesentlich schneller und leichter erstellt als "klassische Anforderungsbeschreibungen".
Durch den Einsatz agiler Methoden ist das Kommunikationsproblem von Entwickler und Anforderer eher größer geworden. Das Kommunikationsproblem, das bei Einsatz der "klassischen Methoden" darin bestanden hat, dass der Anforderer nicht mit dem Kunden reden möchte und ihm die Teilnahme an einem Review viel zu kompliziert und eine Überarbeitung seiner Anforderungen zu aufwendig ist. Agil oder "klassisch", keiner der Methoden ist das Problem - oder löst irgendein Problem. Das Problem liegt in der nicht vorhandenen Kommunikation zwischen Anforderer und Leistungsersteller - und es kann auch nur an dieser Stelle gelöst werden.
User Storys sind also Platzhalter, die Entwickler und Anforderer daran erinnern, dass sie über dieses Thema noch häufiger reden müssen und die durch genauere, spezifischer User Storys ersetzt werden, wenn über die Gespräche und die Erfahrungen aus diversen Reviews die Erkenntnisse über die zu erstellende Leistung im Verlauf des Leistungserstellungsprozesses besser geworden sind.
Der Zeitbedarf bei der Arbeit mit User Storys ist zumindest für die Seite der Anforderer nicht kleiner geworden. Im Gegenteil. Der Unterschied besteht lediglich darin, dass das Risiko geringer wird, das eine Leistung erstellt wird, die nachher nicht den Wünschen der Anforderer entspricht. - Ein Risiko, dass auch bei den klassischen Methoden erheblich reduziert werden würde, Anforderer und Leistungsersteller häufiger und klarer miteinander kommunizieren würden.
Ziel / Nutzen
User Storys werden zur Beschreibung der Anforderungen aus Perspektive eines Nutzers verwendet. Hierfür wird die Alltagssprache verwendet. Eine User Story beschreibt, was ein Benutzer mit einem Produkt erreichen will.
Hilfsmittel
User Storys sollten mündlich formuliert werden. Sie müssen anschließend schriftlich fixiert werden. Das geschieht zumeist in zwei Schritten:
- die schriftliche Ausformulierung in einer Langfassung.
- Kurzform, so dass sie auf eine Moderationskarte passt.
Die Kurzfassung wird in eine Product Backlog oder in einem Work breakdown Chart verwendet. Die "Langfassung" ist eine notwendig Voraussetzung, damit mit einer User Story gearbeitet werden kann.
Wie geht es?
User Storys sollten vom Auftraggeber oder vom späteren Anwender formuliert werden. Eine Hilfslösung besteht darin, dass ein Spezialisten Team, welches die Zielgruppe sehr gut kennt, die User Storys formuliert.
Das Erstellen von User Storys ist ein interaktiver, mehrzyklischer Prozess. Zumeist entstehen "übergeordnete User Storys" (Metaebene), aus denen dann untergeordnete User Storys entstehen, die zu kleineren "Problemlösungen" führen. Es entstehen sehr schnell Strukturpläne aus User Storys. Das zeigte uns auch das INVEST-Kriterium
Eine der gerne gewählten Irrtümer besteht in der Annahme, dass der Aufwand der Umsetzung der Kundenwünsche in einem agilen Umfeld nicht geschätzt werden muss. Betrachten wir uns das INVEST-Kriterium ist das Gegenteil der Fall.
Die drei C´s der User Story:
Card (Karte)
User Storys können direkt auf Karteikarten oder Klebezettel (Post it) geschrieben werden. Dabei wird der unten beschriebene Satzbau verwendet.
Conversation (Gespräch)
In einem interaktiven Kommunikationsprozess von Feedback Schleifen wird zwischen den Beteiligten geklärt, wie die User Story zu verstehen ist. Natürlich dürfen dabei auch Dokumente verwendet und bei Bedarf erstellt werden. Ebenso selbstverständlich kann in der User Story auf andere Dokumente verwiesen werden.
Confirmation (Bestätigung, Akzeptanzbedingungen)
Zumeist auf der Rückseite der Karte werden die Akzeptanzkriterien aufgeführt. Das sind die Bedingungen, unter denen der Anforderer bereit ist, die User Story als erfüllt anzusehen. Häufig zeigt sich hier deutlicher als in der User Story, was genau der Anforderer haben möchte. Gleichzeitig legt sich der Anforderer damit fest. Wenn diese Kriterien erfüllt sind, dann hat das Team die Leistung im Sinne des Anforderers erstellt.
Dieser Ansatz wird auch als Spezikation nach Beispiel oder Acceptance-Test-driven Development (ATTD) bezeichnet.
Eine User Story kann auch eine längere Geschichte sein und sich über mehrere Textseiten ziehen. Wichtig ist nur, dass:
- Sie in einer kürzeren Form dem nachfolgendem Satzbau entsprechend umformuliert wird.
- Sie von der Entwicklerseite umfassend verstanden wird.
Satzbau
Eine User Story ist immer nach dem folgenden Schema aufgebaut:
Als <Rollen, die der Anforderer in der Story hat> will ich <Eigenschaft der Leistung>, damit < folgender Nutzen> entsteht.
Eine alternative Möglichkeit:
In meiner Rolle als <....>, ist mir folgendes passiert <....>. Dadurch sind folgende Probleme entstanden <...>. Eine Beseitigung dieser Probleme würde mir folgenden Nutzen generieren <...>.
Im ersten Fall, muss der Anwender die Eigenschaften einer Leistung, die er benötigt, bereits kennen. Im zweiten Fall, liegt es in der Verantwortung des Projektteams, eine Lösung zu entwickeln.
In beiden Fällen ist die Formulierung der Nutzenerwartung des Anderen wichtig. Nur dadurch ist es möglich, zu überprüfen, ob ein Wert für den Anwender geschaffen wurde.
Kriterien für eine gute User Story
INVEST-Kriterium
[I]ndependent
Eine gute User Story ist unabhängig von anderen User Storys. Die Entwicklung der Lösung für diese User Story sollte möglich sein, ohne dass zuerst andere User Storys umgesetzt werden müssen.
Über die User Story hinausgehende Informationen
Oben wurde bereits gesagt, dass eine User Story ein Platzhalter ist. Auf dem Product Backlog ist auch kaum Platz für weitere Informationen.
An diese User Story können und sollen aber detaillierte technische Spezifikationen, etc. soweit bekannt "angehangen" werden. Das bedeutet in der praktischen Umsetzung auch, dass es eine Vielzahl an Spezifikationsdokumenten geben kann, die zu einer User Story gehören, aber in einem entsprechenden Ordner abgelegt sind, die den Entwicklern ebenso zur Verfügung stehen müssen, wie den Anforderern.
Detailierungsgrad
Eine User Story unterliegt einer Geschichte, bis so detailliert ist, dass sie klein genug strukturiert ist, damit sie in einem Sprint abgearbeitet werden kann. User Stories werden im Verlauf des Leistungserstellungsprozesses immer weiter detailliert (siehe hierzu auch den Artikel Product Backlog). Die Verfeinerung der User Story erfolgt progressiv, also spätestens zu dem Zeitpunkt zu dem sie benötigt wird, in einem iterativen Prozess.
Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org