Die User Story gewinnt immer mehr an Bedeutung bei der Formulierung von Anforderungen, nicht nur bei der agilen Produktentwicklung. Vor allem deswegen, weil allein schon der Name auf die Wichtigkeit hindeutet, Anforderungen und daraus resultierende Produkte anwenderzentriert zu strukturieren und zu entwickeln und die Nutzer:innen in den Vordergrund zu stellen. Diese Nutzersicht ist wichtig, weil wir dem Umsetzungsteam Bedarfe der Nutzer:innen vermitteln wollen und uns bei der Formulierung der Anforderungen erst möglichst spät dem konkreten Lösungsraum nähern. Das wird insbesondere im agilen Kontext so gelebt.

Auch der Aspekt der frühen Feedbackschleifen durch die Nutzer:innen spielt hier eine Rolle. Um das Feedback sammeln und bewerten zu können, benötigen wir einen klar formulierten Mehrwert für die einzelnen Iterationen und Produktinkremente.

Die Satzschablone

Die Satzschablone stellt sicher, dass Anforderungssteller:innen oder Anforderungsvermittler:innen, die eine Anforderung formulieren, die folgenden drei Fragen beantworten können:

1. Wer benötigt etwas und wer ist Nutzer:in, der geforderten Funktionalität?
2. Was bzw. welche Funktion wird benötigt?
3. Warum wird die Funktion benötigt und welchen Nutzen bringt die Implementierung der Funktion?

Durch diese Art der Formulierung wird keine feste Lösung vorgegeben, sondern der Bedarf und der Mehrwert für die konkreten Benutzer:innen wird vermittelt. Gemeinsam mit dem Team kann auf dieser eine Umsetzung diskutiert und weiter detailliert werden.

Das alleine ist für die Anforderungsvermittlung im Kontext der heutigen Produktentwicklung oft nicht ausreichend. Wir benötigen klare Akzeptanzkriterien in einer User Story um ein gemeinsames (explizites) Verständnis im Team zu fördern.

Akzeptanzkriterien

Bei der Formulierung der Akzeptanzkriterien müssen wir sehr konkret in den Lösungsraum einsteigen. Hier geht es darum, angelehnt an konkrete fachliche Testfälle, klare Abnahmekriterien zu definieren.

Auch für die Formulierung der Akzeptanzkriterien gibt es mehrere Empfehlungen aus der Praxis

• Einfach in Prosa in natürlicher Sprache

• Formuliert nach Satzschablone für Systemanforderungen. Mehr Infos dazu auch hier: Anforderungen spezifizieren und modellieren – Anforderungsfabrik

• Formulierung nach Gherkin-Syntax

Neben diesen eher formalen Qualitätskriterien einer User Story ist es allerdings wichtig zu verstehen, welchen Mehrwert diese Art der Formulierung von Bedarfen und Anforderungen hat.

Das 3C-Modell

Im Ursprung der agilen Ansätze wurden Themen für die Umsetzung auf Karten geschrieben. Diese Karten konnten gut sichtbar und für alle transparent an Wände geklebt und im Verlauf der Umsetzung in entsprechende Quadranten oder Spalten gehangen werden (z.B. nach Kanban).

Im heutigen Zeitalter der Remote Arbeit und der Zusammenarbeit in global verteilten Teams ist das nur noch selten möglich. Trotzdem herrscht das Konzept der Karten für die Verwendung von User Stories im Rahmen der agilen Produktentwicklung weiterhin vor. Das Konkrete und für die Umsetzung Relevante soll kurz, klar und zielgerichtet formuliert werden. Backlog Items für das Product Backlog agiler Teams nutzen diesen Ansatz. Das zeigt alleine, dass nahezu in jedem Ticket-Tool die Karten- und Kanbanansicht eingestellt werden kann, wie bspw. in Jira von Atlassian.

Ron Jeffries fasste in seinem 3C-Modell (Card, Conversation, Confirmation – Karte, Diskussion, Bestätigung) zusammen, worauf im Kern bei einer User Story zu achten ist:

Card (Karte)

Eine User Story sollte so prägnant formuliert sein, dass die Beschreibung auf eine (physische) Karte oder Haftnotiz passt. Das wird im agilen Kontext damit begründet und ermöglicht, da bereits durch den regelmäßigen und iterativen Austausch im Team viel implizites Wissen und gemeinsames Verständnis vorherrscht und nur noch das Nötigste explizit formuliert werden muss.

Conversation (Diskussion)

Die User Story soll eine Diskussion und weitere Detaillierung der Anforderung zwischen allen Beteiligten, insbesondere aber im Entwicklungsteam, anstoßen. Die Zusammenarbeit und das gemeinsame Erarbeiten von Details und Lösungen für die Umsetzung steht bei der agilen Arbeitsweise im Vordergrund. Weitere Erkenntnisse, die bei der Diskussion über die User Stories entstehen, können auf der Karte ergänzt oder in konkrete Akzeptanzkriterien innerhalb der User Story beschrieben werden. Im agilen Kontext wird hierzu oft der Begriff des „Refinement-Meeting“ oder der „Story-Time“ für diesen regelmäßigen Austausch im Team verwendet.

Confirmation (Bestätigung)

Auch eine User Story stellt eine konkrete Anforderung dar und muss nach Umsetzung getestet und validiert werden. Vor der Umsetzung und spätestens zur konkreten Planung (nach Scrum u.a. im Sprint Planning) wird geprüft, ob alles ausreichend beschrieben und die notwendigen Abnahmetests, z.B. über die Akzeptanzkriterien, beschrieben wurden. Das Team verständigt sich so über den konkreten Liefergegenstand, welcher nach Umsetzung auf Basis der User Story bestätigt und abgenommen werden kann.

In jedem Fall sollten die Qualitätskriterien an eine User Story für jedes Team individuell definiert und abgestimmt werden. Im agilen Kontext werden diese im „Definition of Ready“ (DoR) zusammengefasst. Entwicklungsteams können auf der einen Seite viel Expertise in der fachlichen wie auch technischen Domaine besitzen, sodass ein Großteil selbstständig erarbeitet werden kann und nur wenig durch die Anforderungsvermittlung vorgegeben werden muss.

Auf der anderen Seite gibt es Entwicklungsteams, die mehr fachliche und technische Vorgaben benötigen. Der Informationsgehalt einer User Story ist hier größer. So können in einer User Story bspw. Architektur-Vorgaben, konkrete GUI Designs oder Prototypen enthalten sein.

INVEST-Kriterien

Die INVEST-Kriterien bieten einen guten Startpunkt für die Definition einer Anforderung. Dabei handelt es sich um ein Akronym, wobei jeder Buchstabe für eine Eigenschaft der Anforderung steht. Die INVEST-Kriterien werden primär im agilen Kontext und bei der Verwendung von User Stories genutzt.

Fazit

Da es in der Anforderungsvermittlung keinen standarisierten Prozess gibt und auch die Arbeitsprodukte und Entwicklungsartefakte im Rahmen der Anforderungsvermittlung sehr individuell gestaltet werden können, ist es sehr wichtig zu Beginn die Qualitätskriterien und Dokumentationsrichtlinien mit den Beteiligten festzulegen. Nur so kann der/die Anforderungsvermittler:in (z.B. in der Rolle des Product Owner, Business Analyst, Requirements Engineer) erkennen, wann die Dokumentation einer Anforderung vollständig ist.

Bei der Nutzung von User Stories ist es wichtig, neben den formalen Aspekten die Herkunft dieses Konzeptes und die grundlegenden Gedanken dabei zu verstehen. Die Basis dazu bilden die Satzschablone mit klaren Aktzeptanzkriterien, die Berücksichtigung der INVEST-Kriterien und der 3Cs. Unter richtiger Anwendung kann so die Kommunikation mit den relevanten Stakeholdern und dem Team gefördert, zielgerichteter im Team zusammengearbeitet und als Resultat innovativere Lösungen gefunden werden.