Die User Story als Mittel zu Beschreibung von Anforderungen hat sich in der agilen Welt inzwischen etabliert. Sie ist schlank, hat auf einer Storycard Platz und wird z.B nach dem Muster Als [Rolle] will ich [Feature] um [Motivation] aufgeschrieben.
Sie beschreibt somit auf einfache Weise eine Funktionalität aus der Sicht des Benutzers, der sie sich wünscht. Um das allseitige Verständnis zu erhöhen, wird auch noch die Motivation, also was will der Benutzer damit erreichen bzw. anstellen, mitgegeben.
Das ist wirklich schlank und rank im Vergleich zu ausführlichen, detaillierten Anforderungsbeschreibungen und man fragt sich vielleicht, wie das gut gehen soll? Nun, einerseits wird diese Story noch durch die Beschreibung von Details, Abnahmekriterien, Tests und nichtfunktionalen Anforderungen ergänzt … üblicherweise auf der Rückseite der Storycard, dass alles schön beisammen bleibt. Andererseits ist eine solche User Story nach Mike Cohn lediglich eine gegenseitige Vereinbarung zwischen dem Entwicklungsteam und dem Product Owner über zu führende Gespräche.
Oft entsteht eine User Story, wenn jemand eine Idee hat. Dann sind die Anforderungen vielleicht noch recht vage und grob. Schritt für Schritt werden sie in gemeinsamen Gesprächen und Diskussionen mit allen Beteiligten (Product Owner, Anwender, Kunden, Architekten, Entwickler, …) verfeinert, ehe eine solche Story geschätzt und umgesetzt werden kann.
Und selbst während der Umsetzungsphase wird bis zum letzten Moment weiter miteinander geredet, um die Anforderungen so zu implementieren, dass das entsteht, was wirklich hilft und gebraucht wird.
Wie aber erlebt die User Story selbst diesen Prozess? Was geht in ihr vor? Wie fühlt sie sich dabei?
Dieses Pecha Kucha, uraufgeführt auf den XPDays 2011, könnte etwas Licht ins Dunkel der User Story-Forschung bringen:
Auch veröffentlicht auf www.holisticon.de