71% aller Softwareunternehmen setzen agile Methoden ein. 58% von ihnen tun dies, weil sie so einfacher mit den sich ändernden Prioritäten und Anforderungen umgehen können. 51% aller agilen Teams verwenden User Stories mit Akzeptanzkriterien zur Repräsentation der Anforderungen [SwissQ, 2014].
In vielen Projekten sind aber mehr und strukturiertere Informationen zu den Anforderungen notwendig, als User Stories mit Akzeptanzkriterien sie bieten. Das führt zu Problemen in der Kommunikation zwischen den agilen Teams und den Fachabteilungen. Diese haben oft schon recht gute Vorstellungen, was sie brauchen und möchten das auch vollständig und strukturiert mitteilen. Auf der anderen Seite wünschen sich agile Teams immer wieder mehr Unterstützung und Struktur beim Ermitteln und Dokumentieren der Anforderungen. User Stories alleine reichen dafür nicht aus.
Ist es erforderlich, entscheidet das Team selbst, ob es weitere Spezifikationsartefakte benötigt.
Je nach Bedarf können dies Elemente aus der agilen Welt sein wie …
- Epics und Themes: Zur Zusammenfassung mehrerer User Stories zu einem Thema
- Features: Zur Gliederung der User Stories aus Kunden- bzw. Marketingsicht
- Personas: Zur Beschreibung von Anwendergruppen
Oder Elemente aus dem klassischen Requirements Engineering, wie …
- Use Cases: Zur Beschreibung der Interaktion zwischen Anwender und System
- Modelle: Zur grafischen Darstellung von Abläufen, Datenstrukturen etc.
- UI Mockups: Zur Visualisierung der zukünftigen Benutzerschnittstelle
Ziel ist es, das Set an Artefakten zu finden, mit dem das Team am besten arbeiten kann.
Abb. 1.: Unterschiedliche Artefakte werden je nach Notwendigkeit im Projekt kombiniert.
Gerade Use Cases können in agilen Projekten sehr gut eingesetzt werden. Ein Use Case (Anwendungsfall) beschreibt immer eine Interaktion mit dem System, die einen Nutzen für den Anwender liefert. Im einfachsten Fall besteht der Use Case nur aus einem Titel, einem Auslöser, der Angabe der wichtigsten Schritte und den wesentlichen Akzeptanzkriterien. Der Titel kann dabei wie eine User Story formuliert werden:
Ein solcher Use Case kann nun entweder wie eine User Story direkt ins Backlog übernommen, oder erst in Tasks aufgeteilt werden. Eine Aufteilung ist immer dann sinnvoll, wenn der Use Case zu groß für die Umsetzung in einer Iteration ist. Es kann dann beispielsweise ein Task für jeden Schritt im Anwendungsfall erstellt werden. Wenn nötig können zum Use Case noch UI Mockups, Daten- und Schnittstellenbeschreibungen usw. angefügt werden.
Agile Use Cases sind so ein klarer und guter Andockpunkt für weitere Informationen. Sie sind ein Weg, mehr Struktur in die Anforderungen zu bringen, ohne die Agilität zu verlieren. Probieren Sie es doch einfach mal einige Sprints lang aus!
