Im agilen Projektmanagement sind User Stories ein verbreitetes und etabliertes Werkzeug für die Beschreibung und für das Management von Anforderungen. User Stories haben eine gewisse Unschärfe in der Beschreibung der Anforderungen, sodass diese Raum für Änderungen enthält (siehe hierzu »Agile Werte und Grundsätze«). User Stories beschreiben Anforderungen immer aus Sicht des Benutzers und wenn möglich, soll der Inhalt in einem bzw. in sehr wenigen Sätzen formuliert werden. User Stories können als Platzhalter für eine spätere Kommunikation verstanden werden, was einen wesentlichen Bestandteil der Methode darstellt (siehe auch »Interpersonelle Konzepte im Projektumfeld«). Eine User Story beschreibt eine Anforderung eines Systems aus der Sicht des Benutzers und enthält einen konkreten und sichtbaren Mehr- bzw. Geschäftswert für den Kunden[1].
Akzeptanzkriterien, Conditions of Satisfaction
Wenn eine Anforderung über eine User Story beschrieben wird, gehören, aufgrund der Unschärfe in den Beschreibungen, zu den wichtigsten Eigenschaften der User Story die Akzeptanzkriterien (conditions of satisfactioin, kurz COS). Diese Akzeptanzkriterien halten fest, welche Kriterien erfüllt sein müssen, damit eine User Story bzw. die Anforderung als erfolgreich abgenommen werden kann[2]. Da zu einer Anforderung meist unterschiedliche Akzeptanzkriterien von dem unterschiedlichen Stakeholdern existieren, gibt diese Sammlung von Kriterien auch ein sehr gutes Abbild der unterschiedlichen Erwartungshaltungen wider (siehe »Einführung von User Stories«).
Story Cards
User Stories werden auf sog. Story Cards geschrieben und sind der sichtbare Teil einer User Story. Eine Story Card beschreibt kurz und klar das Ziel des Benutzers. Wie in Abbildung »Story Card« dargestellt enthält eine klassische Story Card eine ID, eine Kurzbezeichnung und das zugehörige Projekt. Die Wichtigkeit bzw. Priorität wird später über das Product Backlog festgelegt (siehe »Product- und Sprint-Backlog«). Danach werden die User Stories im Planning Poker geschätzt (siehe »Planning Poker«).
Anders als im klassischen Anforderungsmanagement, indem man die Anforderung so genau wie möglich formuliert, liegt der Erfolg im agilen Projektmanagement und der Verwendung von Story Cards in der Kommunikation. So gut wie jeder erfahrene Softwareentwickler weiß, wie schwer es ist, Anforderungen so genau zu beschreiben, dass diese geeignet wäre, eine der Erwartungshaltung des Kunden entsprechende Software zu entwickeln, zudem sich die Erwartungshaltung des Kunden während eines Projektverlaufes ändern kann (Moving Targets) oder der Kunde zum Zeitpunkt der Anforderungserhebung noch nicht genau abgrenzen kann, was er in seinem Geschäftsumfeld an Eigenschaften der Software benötigt. Der Schwerpunkt des Anforderungsmanagements wird beim Einsatz von User Stories von der schriftlichen auf die kommunikative Ebene verlagert.
Syntax der User Stories
Um die Erwartungshaltung des Kunden oder des Anwenders besser aufnehmen zu können, werden neben den Akzeptanzkriterien die User Stories in der Sprache des Kunden verfasst und haben ein eigenes Muster bzgl. ihrer Anwendungsdomäne[3].
Als [Rolle] will ich [Ziel], so dass [Grund für das Ziel]
Als Kunde will nach Ansprechpartner suchen, sodass ich diese sofort anschreiben kann.
Der erste Platzhalter wird durch die konkrete Rolle ersetzt, aus dessen Sicht die User Story geschrieben wird. Das Ziel stellt den Kern der Anforderung dar. Optional kann auch noch erklärt werden, was die Motivation oder der Grund des Zieles ist um die Erwartungshaltung genauer zu spezifizieren.
[1] Wirdemann, Ralph: Scrum mit User Stories; 1. Auflage; Carl Hanser Verlag München Wien; 2009; S.52f.
[2] Pichler; Roman: Scrum, Agiles Projektmanagement erfolgreich einsetzen; 1. Auflage; dpunkt.verlag GmbH; Heidelberg; 2008; S. 46f
[3] Wirdemann, Ralph: Scrum mit User Stories; 1. Auflage; Carl Hanser Verlag München Wien; 2009; S.51ff.
No Comments