Im Rahmen von Agile werden beiden Methoden eingesetzt. Oft besteht Unklarheit über den Unterschied zwischen den beiden Methoden und wie sie die Anforderungen eines Projektes abstecken. Auf den ersten Blick erscheint der Use Case als sinnvoller, da die Anforderungen für den Entwicklungsaufwand, insbesondere die Interaktion mit dem System, genauer beschrieben werden. Dagegen erscheint die User Story auf den ersten Blick zu vage und lässt viele Details offen. Dies ist allerdings das Konzept der User Story, sie fokussiert das zu erreichende Ziel aus Sicht des Benutzers und den Nutzen, welchen diese Zielerreichung mit sich bringt. Die Lösung wird bewusst offen gelassen, resp. kann mit entsprechenden Akzeptanzkriterien eingegrenzt werden. User Stories werden zu Beginn der Umsetzung in kleinere Aufgaben (Tasks) zerteilt, auf dem Task-Board transparent gemacht und nach deren Priorität abgearbeitet. Sind alle Tasks zu einer Story umgesetzt, ist die Story fertig.
Niemals sollten User Stories, so wie sie initial formuliert wurden, direkt als Arbeitspaket aufgefasst werden. Denn dadurch verwandelt sich die grösste Stärke der User Stories in eine grosse Schwäche: User Stories lassen initial einen zu grossen Spielraum zu. Sie sind eine Aufforderung zur Diskussion, welche gemeinsam im Team geführt wird, demit der optimal Lösungsraum definiert wird. Ein weiterer Vorteil der User Story ist, dass die Kommunikation mit dem Kunden vereinfacht.
Um die Anforderungen an ein Produkt zu beschreiben, empfehlen wir eine Kombination von User Stories, gekoppelt an eine Customer Journey und ggf. einem Business Domain Model. Dazu einige Architektur-Diagramme und viel Domänenwissen bei Kunden und Entwicklern. Das Erstellen von Personas hilft ebenfalls, den Anforderungen Leben einzuhauchen, auch wenn bisher noch nichts entwickelt wurde.
