Benutzergeschichte

Eine Benutzergeschichte (user story) beschreibt ein Stück Funktionalität aus der Sicht des Benutzers:

Beispiel: Nach Klicken auf den Submit-Knopf sollen die Eingaben mit Plausibilitätsregeln geprüft werden. Wird kein Fehler gefunden, wird das Ticket in die Datenbank eingefügt.

Der Kunde möchte natürlich sicher sein, daß die Benutzergeschichte richtig implementiert wird. Um diese Nachprüfbarkeit zu erreichen, spezifiziert oder besser implementiert der Kunde Akzeptanztests, die ihm erlauben, dies auf einfache Weise zu entscheiden.

Auch wenn es keine "optimale Größe" für eine Benutzergeschichte gibt, repräsentiert sie typischerweise einen Aufwand von etwa 2 bis 3 Tagen. Dies bedeutet, dass ein Programmiererpaar eine Benutzergeschichte sowie die zugehörigen Akzeptanztests innerhalb von 2 bis 3 Tagen implementieren kann. Ob es immer 2 bis 3 Tage sind ist von Team zu Team unterschiedlich.

Die Programmierer schätzen den benötigten Aufwand für eine Benutzergeschichte indem sie zunächst die Aufgaben herausfinden, die für die Implementierung notwendig sind. Der Aufwand für jede dieser Aufgaben wird dann geschätzt. Schließlich werden diese Einzelaufwände zusammengezählt und ergeben den Aufwand für die Benutzergeschichte. Basierend auf dieser Schätzung kann der Benutzer dann den Aufwand in Kosten übersetzen. Dies wiederum ermöglicht es ihm eine vernünftige Entscheidung zu treffen hinsichtlich der Implementierungsreihenfolge der Benutzergeschichten und auch ob eine Benutzergeschichte dann überhaupt implementiert wird.

Aufteilen einer Benutzergeschichte

In jedem Releasezyklus implementieren die Programmierer mehrere Benutzergeschichten. Manchmal stellt es sich heraus, das Zeit übrig ist, oder dass eine Benutzergeschichte nicht mehr vollständig in das laufende Release hineinpasst. In beiden Fällen sollte dann die Benutzergeschichte in zwei Teile aufgeteilt werden: ein Teil, der noch im laufenden Releasezyklus implementiert wird, und ein Teil, der in das nächste Release verschoben wird.

In jedem Fall muß die Entscheidung in Zusammenarbeit mit dem Benutzer getroffen werden. Er ist es schließlich, der entscheidet, was implementiert wird.

Abhängigkeiten

In seltenen Fällen, denkt man vielleicht, gibt es Abhängigkeiten zwischen zwei Benutzergeschichten. Nehmen wir einmal folgendes Beispiel:

Benutzergeschichte 1: Zeige eine Liste aller registrierten Benutzer.

Benutzergeschichte 2: Füge einen neuen registrierten Benutzer hinzu.

Auf den ersten Blick sieht es so aus, als ob die Benutzergeschichte 1 implementiert werden kann, nachdem Benutzergeschichte 2 fertig ist. Wenn man jedoch genauer hinschaut, muß man jedoch nur eine einzige Aufgabe zur Benutzergeschichte 1 hinzufügen, um einige Benutzer zu haben, die angezeigt werden können.

Wenn zum Beispiel die Benutzer in einer SQL Datenbank gespeichert werden, dann könnte man ein SQL Skript schreiben, das die Tabelle "Users" füllt. Dafür braucht man nur wenige Minuten, dafür ermöglicht es, die Benutzergeschichte 1 zuerst zu implementieren - oder aber ein zweites Programmiererpaar für die Benutzergeschichte 2 parallel einzusetzen.

Beispiele

Hier zwei Beispiele aus der Praxis (Hinweis: wir verwenden grundsätzlich Englisch innerhalb unseres Unternehmens):

Tipps

• Eine Benutzergeschichte sollte aufgeteilt werden, wenn sie länger als etwa 2 bis 3 Tage benötigt, um implementiert zu werden.
• Wenn eine Benutzergeschichte nicht mehr auf eine Karte passt, sollte man sie aufteilen.
• Für Benutzerschnittstellen kann man eine einfache Zeichnung an die Karte antackern.