User Stories: Treibstoff für die Softwareentwicklung

Ein zentraler Bestandteil agiler Softwareentwicklung sind User Stories. Diese Komponenten rücken fortlaufend jene Menschen in den Mittelpunkt der Arbeit, für die letztlich entwickelt wird: die Endbenutzer. In unserem Blogbeitrag klären wir, was gute User Stories ausmacht und wie sie in das agile Framework eingebunden werden.

Zielgruppe rückt ins Zentrum

Ein Grundgedanke der agilen Softwareentwicklung ist es, den Menschen in den Mittelpunkt des Prozesses zu stellen. Dabei geht es nicht nur um die Personen, die unmittelbar an der Arbeit beteiligt sind, also Entwicklerteams und Auftraggeber. Auch und vor allem diejenigen, die mit den erarbeiteten Features nach Ende des Projektes umgehen sollen, rücken ins Zentrum. User Stories bilden hier einen Leitfaden für die Projektteams, der ihnen in den einzelnen Entwicklungsstadien immer wieder vor Augen führt, was die Endbenutzer an Funktionen brauchen und wie diese ausgestaltet sein sollen. Als benutzerorientierte Zielmarken verschaffen User Stories der täglichen Programmierarbeit erst ihren Sinn: Welcher Entwicklungsschritt schafft welchen Wert? Das Team kann sich gemeinsam über die gesuchten Lösungen austauschen und festlegen, wer woran arbeiten soll. Jede neue User Story bringt den Entwicklungsprozess in Schwung und trägt als kleine, aber wichtige Arbeitseinheit des agilen Frameworks dazu bei, dass die übergeordnete Einheit, die als Epic zielgerichtet vorankommt.

Einfache Sprache, große Wirkung

Wie aber wird eine User Story selbst entwickelt? In Zusammenarbeit mit dem Auftraggeber stellt der Product Owner des jeweiligen Projektes die Anforderung auf. Diese sollte in einfacher, allgemeiner Sprache aus der Sicht des Endbenutzers formuliert werden. Anders als es die Bezeichnung User Story vermuten lässt, geht es nicht darum, eine längere „Geschichte“ zu schreiben, sondern zunächst in wenigen Sätzen festzuhalten, was die generelle Anforderung ist. Das Team reichert diese dann im Laufe des Entwicklungsprozesses mit den nötigen Details an. Essenziell ist, dass die folgenden drei Leitfragen in der Story geklärt werden:

• Für welchen Kunden- bzw. Endbenutzertyp wird entwickelt?
• Was wünscht sich dieser User-Typus an Features?
• Welchen Nutzen erhofft sich der User davon?

Oftmals wird dieser Dreiklang mit den Schlagworten „Kundentyp – Anforderungen – Zweck“ umrissen. Dementsprechend könnte zum Beispiel, bezogen auf die Entwicklung eines Onlineshops, eine typische User Story wie folgt lauten: „User X möchte als Fan der Marke Y eine Vergleichsfunktion verschiedener Produkte haben, um sich im Kaufprozess besser entscheiden zu können.“ Damit wäre die grobe Schlagrichtung für das Entwicklerteam klar, ein Tool zu bauen, welches diesen Vergleich ermöglicht, indem der User mehrere Artikel dort einfügen und übersichtlich nebeneinanderhalten kann. Welche Vergleichsparameter konkret dabei zur Verfügung stehen und welche Produktarten miteinander vergleichbar sein sollen, klärt das Entwicklerteam in Abstimmung mit dem Auftraggeber und etwaigen Test-Usern. Letztere können generell in Umfragen oder persönlichen Interviews ihre Vorstellungen künftiger Features benennen und bereits Entwickeltes bewerten.

Qualität von User Stories prüfen

Ist eine User Story aufgestellt, tun Entwicklerteams gut daran, diese vor dem Start der eigentlichen Arbeit auf bestimmte Qualitätskriterien hin abzuklopfen. Dazu kursieren in der Welt der agilen Methoden verschiedene Modelle, an denen sich ein Team orientieren kann. Das wohl am meisten verbreitete ist das INVEST-Modell, bei dem jeder Buchstabe des Begriffs für eine Anforderung an eine gute User Story steht:

• I wie Independent: Damit User Stories vernünftig priorisiert und auf Teammitglieder verteilt werden können, sollten sie so unabhängig wie möglich voneinander sein. Trennschärfe ist gefragt!
• N wie Negotiable: Die Stories sollen verhandelbar bleiben, also so offen formuliert werden, dass sie zur kreativen Diskussion über Lösungswege im Team anregen und keine in sich geschlossene Handlungsaufforderung darstellen.
• V wie Valuable: Das Entwicklungsziel einer User Story sollte auf jeden Fall zur Wertschöpfungskette des Auftraggebers beitragen und im Sinne seines Business Value priorisiert werden können.
• E wie Estimatable: Der zeitliche und entwicklungstechnische Aufwand zur Umsetzung einer User Story sollte für das Projektteam gut einschätzbar
• S wie Small: In Ergänzung zum vorhergehenden Aspekt sollen die einzelnen Anforderungen klein genug bleiben, um im Sprint umgesetzt werden zu können.
• T wie Testable: Damit das an die Entwicklungsphase angeschlossene Testing problemlos abläuft, sollten die Anforderungen einer User Story so beschaffen sein, dass das Ergebnis nach klaren Kriterien getestet werden kann.

Ergänzend gibt es noch weitere Modelle – etwa das KISS-Modell, nach dem die Devise „Keep It Simple, Stupid!“ gilt: Gibt es mehrere Erklärungen für einen bestimmten Sachverhalt, dann ist die einfachste davon zu bevorzugen, also jene, die mit den wenigsten Annahmen und Variablen auskommt. Auch das SMART-Modell findet vielfach Anwendung, sagt aber letztlich nichts anderes als das INVEST-Konzept aus: User Stories sollen demnach spezifisch formuliert, in ihren Zielen messbar, erreichbar sowie realistisch sein und mit einem fixen Datum zur Finalisierung terminiert werden.

Bausteine im agilen Framework

Hat eine User Story den Qualitätstest bestanden, ist sie bereit zur Bearbeitung im agilen Workflow. Wie dies geschieht, hängt davon ab, nach welcher agilen Methodik ein Team arbeitet. Bei Scrum beispielsweise werden User Stories einzelnen Sprints zugeordnet und in deren Verlauf bearbeitet. Sie sollen den zeitlichen Ablauf eines Sprints planbarer machen und damit das Maß an Agilität steigern. Zusammengefasst werden mehrere Stories in Epics, die wiederum eine übergeordnete Initiative bilden. Auf jeder dieser Ebenen signalisieren User Stories den Wert der konkreten Entwicklungsschritte und stellen den Kontext zum ursprünglichen Anlass des Projektes her. Trifft sich das Entwicklerteam zur Iterationsplanung, legen alle Beteiligten zusammen fest, welche Stories in welchem Sprint bearbeitet werden sollen und welche Aufgaben jeweils zu vergeben sind. Ebenso werden die Stories in diesem Schritt nach Aufwand und Komplexität kategorisiert, um einzuschätzen, wie lange die jeweiligen Entwicklungsschritte dauern und wie einzelne Aufgaben aufzuteilen sind.

Eine User Story abschließen

Klar ist, dass nach Abschluss eines Sprints auch die Maßnahmen zur Umsetzung der darin enthaltenen User Stories vorerst beendet sein sollten. In einem Review stellen die jeweiligen Entwickler ihre Ergebnisse vor und es wird entschieden, ob diese tatsächlich an die Auftraggeber ausgeliefert werden können. Doch auch wenn dies geschieht: Letztlich ist eine User Story erst dann wirklich abgeschlossen, wenn ihr Inhalt nicht nur vom Entwicklerteam realisiert, sondern auch in der Praxis von den Endbenutzern wie gewünscht angenommen wurde. Ist dies nicht der Fall, muss entweder die Story selbst angepasst oder zumindest ihre technologische Umsetzung überarbeitet und in einen neuen Sprint integriert werden. Dann beginnt die Geschichte im Sinne der User von Neuem.

Bild: freepik