Schreibt man alles in ein Word-Dokument mit sauberer Gliederung? Nutzt man Skizzen oder Prozessmodellierungswerkzeuge? Machen wir ein Grobkonzept, dann ein Feinkonzept, stimmen es mit dem Kunden ab und fangen dann an zu arbeiten? Oder doch eine Excel-Tabelle oder einen Projektplan mit Tätigkeiten?
Eine beliebte Variante zur Arbeit mit Anforderungen in agilen Projekten nennt sich „User Story“: Eine User Story sind wenige Sätze natürlicher Sprache, um als Gedankenstütze für eine Anforderung zu dienen.
Ein Beispiel für eine User Story:
Als Vertragshändler möchte ich alle Gebrauchtwagen auflisten können, um diese meinen Kunden anzubieten.
Könnte das Team diese Anforderung umsetzen? Vermutlich nicht. Die beschriebene Anforderung ist recht vage, nur grob umrissen. Eine Idee, die es zu durchleuchten gilt. Das Grundprinzip dahinter: Ein guter und kontinuierlicher Dialog der Beteiligten ist wichtiger als eine detaillierte, niedergeschriebene, im Voraus für das Projekt völlig durchdrungene Spezifikation.
Man kann sich so eine User Story wie ein „Aufhänger für eine Funktionalität“ vorstellen. Die Funktionalität wird sichtbar, anfassbar, begreifbarer. Aber eben nicht vollständig definiert. Das verhindert allein schon die Unschärfe von Sprache und auch die Komplexität von Softwareentwicklung. Besser wir investieren hier nicht allzuviel Zeit.
Doch mit so großer Unschärfe kann auch das beste Team der Welt nicht wirklich effizient arbeiten. Die User Story enthält zwar wer was warum möchte – aber nicht was genau und schon gar nicht wie genau.
Vom Groben ins Feine.
Wann wird solch eine Idee namens User Story nun also konkreter? Kurz bevor wir die umschriebene Anforderung der User Story umsetzen möchten, sollte sie klein und konkret sein. Um dahin zu gelangen, machen agile Teams häufig so genannte Backlog Refinement Besprechungen. In diesen Besprechungen geht es darum, das Verständnis zu vertiefen und gemeinsam mit dem Product Owner, große User Stories in kleinere zu zerlegen.
Ich bin fertig und mache dann mal Feierabend für heute.
Woher weiß ein Team nun, ob es das Ziel einer User Story erreicht hat? Wann ist die Funktionalität fertig? Das klärt das agile Team im Dialog mit seinem Product Owner. User Stories werden während dieses Dialogs häufig durch schriftliche Akzeptanzkriterien ergänzt. Das sind stichpunktartige Kriterien, die erfüllt sein sollten, damit der Product Owner eine User Story als fertig akzeptiert. Eine Art Checkliste oder für diese eine User Story geltende Ergänzung der Definition of Done.
Ein Beispiel:
Als Vertragshändler möchte ich alle Gebrauchtwagen auflisten können, um diese meinen Kunden anzubieten.
Akzeptanzkriterien:
– Die Liste zeigt alle noch nicht verkauften Fahrzeuge an
– Die Liste ist nach Kaufpreis sortiert
– Wenn keine Fahrzeuge vorhanden sind, erscheint ein Hinweistext
Ein bisschen mehr Technik bitte.
Wann wird es nun endlich technisch? Wo entsteht die Lösungsidee? Welche Architektur braucht es und welche Anpassungen im Code? Alle konkreten, technischen Tätigkeiten wird ein agiles Team in der Sprintplanung oder in einer Iteration selber identifizieren und als so genannte „Tasks“, also kleine Schritte zur Implementierung solch einer Anforderung, an eine User Story hängen. Das ist elegant, denn so sind fachliches Problem und technische Lösung bis zur Sprintplanung getrennt. Wir verwenden so nämlich keine Zeit auf technische Überlegungen, die vielleicht doch nie umgesetzt werden, weil sich die Marktanforderungen ändern und damit die Prioritäten unseres Backlogs.
Nun: Wie sähe wohl Ihr aktuelles oder nächstes Projekt mit dem Konzept von User Stories aus? Was wäre anders? Was schwieriger, was leichter? Viel Erfolg beim Ausprobieren.