Sobald man Software entwickelt, stellt sich die Frage, wie man eigentlich mit Wünschen und Ideen von Entwicklern, Kunden, Führungskräften, Produktmanagern, also den Stakeholdern umgeht.

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 ist es an dieser nicht zu viel Zeit zu investieren.

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, also der Person die die Anforderungen kennt und festlegt, große User Stories in kleinere zu zerlegen.

Spätestens wenn eine User Story in eine Iteration bearbeiteten bearbeitet wird, sollte sie also gut verstanden sein, vielleicht auch schon kurz davor. Das bedeutet, dass das Entwicklungsteam weiß, was das Ziel der Umsetzung ist und woran es erkennen kann, dass es dieses Ziel erreicht hat. Häufig sind dann auch weitere Wissensquellen als Anlagen zu einer User Story vorhanden: Vielleicht ein User-Interface-Entwurf, vielleicht eine Spezifikation eines Gesetzgebers, vielleicht Formeln in einer Excel-Tabelle. Hier ist erlaubt, was dem Team hilft – ohne es von Beginn an in seiner Kreativität und Lösungsfindung einzuschränken.

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

Die User Story bleibt dabei auf der Ebene der Benutzerperspektive: Sie sollte also von allen Menschen mit Domänenhintergrund verstanden werden können – und deswegen auch nicht technisch sein. Gedanklicher Kniff: Stellen Sie sich vor, ein Kunde ohne technischen Hintergrund sollte sie verstehen können. Eine Kommunikationsbrücke zwischen Entwickler und Fachperson also.

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.