Die Entwicklung eines neuen Produkts oder die Implementierung einer neuen Funktion sollte lohnend sein und Innovationen fördern. Wenn ein Entwicklungsteam jedoch stattdessen lange Anforderungsdokumentationen mit erdrückend starren Richtlinien schreiben muss, ist dies möglicherweise nicht immer der Fall. Traditionelle Softwareentwicklungsmethoden beruhten in hohem Maße darauf, einem vorgegebenen Satz von Anforderungen für jede einzelne Funktion eines bestimmten Produkts, einer bestimmten Dienstleistung oder Anwendung zu folgen. Dadurch waren die Teams an strenge Richtlinien gebunden und hatten kaum Flexibilität, spontane Anpassungen auf der Grundlage von Echtzeitdaten oder Kundenfeedback vorzunehmen.

Dann, in den späten neunziger Jahren, begannen Entwicklungsteams, agile Projektmanagementmethoden und die Idee eines kundenorientierten 'Benutzer Geschichte' wurde geboren.

Eine User Story ist eine kurze, 2-3-Satz-Beschreibung einer oder mehrerer Funktionen eines bestimmten Softwaresystems aus der Sicht des Kunden/Endbenutzers. User Stories werden in „einfacher Sprache“ geschrieben, d. h. es gibt keine übermäßig technischen Begriffe, sodass sie leicht gelesen und verstanden werden können von alle – nicht nur die Entwickler. Eine User Story für eine Übungs- oder Workout-App könnte beispielsweise lauten: „Als iOS-Benutzer möchte ich Daten mit einer Apple Watch synchronisieren, damit ich den Kalorienverbrauch genauer verfolgen kann.“

Diese Beschreibungen können von einem oder mehreren Stakeholdern verfasst werden, darunter das Entwicklungsteam, Manager oder Kunden/Benutzer. Da User Stories flexibel sein und die Bedürfnisse des Benutzers widerspiegeln sollen, werden sie häufig auf eine Notizkarte oder einen Haftnotizzettel geschrieben und regelmäßig überarbeitet oder geändert.

Durch die Erstellung vereinfachter und nachvollziehbarer Anforderungsbeschreibungen konnten sich die Entwicklungsteams auf die schnelle Bereitstellung der von ihren Benutzern gewünschten Funktionen und Updates konzentrieren.

Was ist eine User Story in Agile?

Stellen Sie sich vor, Sie planen eine Autoreise, müssen aber jede einzelne Richtung auflisten, bevor Sie überhaupt Ihr Haus verlassen. Wenn Sie dann losfahren, müssen Sie diesen Anweisungen folgen, auch wenn unterwegs eine bessere Route oder eine interessante Touristenattraktion auftaucht. So war es in etwa, bevor es agile Softwareentwicklung gab.

User Stories wurden entwickelt, um die traditionelle Anforderungsdokumentation zu ersetzen, deren Erstellung die Teams ewig dauerte und die Entwickler oft von Anfang an auf eine einzige Vorgehensweise beschränkte. Alle Anforderungen mussten während der Planungsphase detailliert ausgearbeitet werden, und die Entwickler mussten diese Anforderungen befolgen, egal ob es im Laufe der Zeit Änderungen oder Probleme gab. User Stories helfen dabei, die Arbeit von Entwicklern und Produktionsteams an neuen Produktaktualisierungen und -funktionen zu vereinfachen, indem sie kleine, regelmäßige Aktualisierungen hervorheben, die darauf basieren, wovon der Endbenutzer am meisten profitiert.

Mit den Worten von Mike Cohn, einem der ursprünglichen Gründer von Agile und Scrum-Methoden , sollte eine User Story „den Fokus vom Schreiben über Anforderungen auf das Sprechen über sie verlagern.“ Extreme Programming (XP) Autor und Ersteller waren der Ansicht, dass es für Entwicklungsteams vorteilhafter sei, einen „gerade genug“-Ansatz zu verfolgen, der sich auf die Bereitstellung eines gleichbleibenden Mehrwerts für die Benutzer konzentriert.

Agile User Stories verschafften den Teams viel mehr Flexibilität und ermöglichten es ihnen, ihren Kunden kontinuierlich neue Funktionen und Updates bereitzustellen – oft in Echtzeit. Statt großer Produktveröffentlichungen lag bei der agilen Softwareentwicklung der Schwerpunkt darauf, die Ergebnisse in kleinere, überschaubarere Einheiten aufzuteilen, die die Kunden bei Laune hielten und den Produktrückstand voranbrachten. Dies half auch dabei, das häufige Problem zu vermeiden, zu viel preiszugeben und an etwas festzustecken, das möglicherweise nicht im besten Interesse des Benutzers ist.

Stories, Epics und Initiativen: Wie agile User Stories Projekte voranbringen

In der agilen Methodik sind User Stories Teil eines sogenannten Epics. Epics beschreiben einen größeren Arbeitsumfang, der dann in einzelne User Stories zerlegt wird. Diese Epics fallen dann unter den Schirm einer noch größeren Initiative, die mehrere verwandte Epics und ihre User Stories enthält. Initiativen und Epics ermöglichen es Teams, verschiedene User Stories basierend auf gemeinsamen Zielen zu organisieren.

Kehren wir zu unserem Beispiel von vorhin mit der imaginären Workout-App zurück. Unsere Beispiel-User-Story hat detailliert beschrieben, wie ein iOS-Benutzer Daten von seiner Apple Watch synchronisieren möchte. Eine separate User-Story könnte sich jedoch auf Android-Benutzer und andere Fitness-Tracker konzentrieren. Beide User-Storys könnten dann unter ein Epic fallen, wie etwa „Fitness-Tracking-Funktionalität für den Start im ersten Quartal verbessern“. In diesem Fall könnte die übergreifende Initiative lauten: „Benutzerzahl um 3 % erhöhen“.

Zusammen helfen User Stories, Epics voranzutreiben, was es Teams letztendlich ermöglicht, vollständige Initiativen mit kontinuierlichen Verbesserungen für den Endbenutzer abzuschließen. Teams können dann häufiger Updates bereitstellen und sogar schneller auf Benutzer- und Kundenanfragen reagieren.

Die Vorteile agiler User Stories

Die Einführung agiler User Stories bietet gegenüber der herkömmlichen Anforderungsdokumentation vier wesentliche Vorteile:

1. Erhöhte Flexibilität für das Entwicklungsteam. User Stories befreien das Entwicklungsteam von der Notwendigkeit, starren und restriktiven Dokumentationen zu folgen, die zu Beginn des Produktionsprozesses geschrieben wurden. Dadurch wird verhindert, dass Entwickler auf eine einzige Lösung festgelegt werden, und sie haben die Flexibilität, an innovativen Funktionen und Updates zu arbeiten.
2. Software-Updates sind schneller. Bei der agilen Entwicklung liegt der Schwerpunkt auf der Bereitstellung kleiner, aber konsistenter neuer Funktionen und Updates, statt auf dem traditionellen, größeren Ansatz, alles auf einmal zu implementieren. Dies hält das Entwicklungsteam motiviert, da sichergestellt wird, dass der Produktrückstand voranschreitet. Außerdem müssen Entwickler ihre Zeit nicht mehr damit verbringen, lange und umfassende Anforderungsdokumentationen zu schreiben.
3. Die Teams können sich auf das Wesentliche konzentrieren: den Benutzer. User Stories helfen Produktionsteams, sich auf die Funktionen zu konzentrieren, die für den Benutzer am wichtigsten sind. Sie ermöglichen es den Teams auch, schneller auf Benutzeranforderungen in Echtzeit zu reagieren, da Updates in kleineren Segmenten erfolgen. Die Absicht von User Stories besteht darin, dass Teams wirklich einen Schritt zurücktreten und verstehen, was Benutzer von dem jeweiligen Dienst wollen und brauchen.

Die 3 C's der User Stories

Ein anderer XP-Entwickler, Ron Jeffries, machte die Idee populär, User Stories in das zu unterteilen, was er als „Die 3 Cs“ bezeichnete. Laut Ron sollten alle User Stories diese drei wesentlichen Elemente enthalten:

Karte

Die Karte ist die kurze Beschreibung der spezifischen User Story in 2-3 Sätzen. Die Karte muss die WHO (eine bestimmte Benutzerrolle), Was (die gewünschte Aufgabe oder Aktion) und Warum (der Nutzen aus der Erledigung dieser Aufgabe oder Aktion).

Gespräch

Das Gespräch stellt eine versprochene Diskussion zwischen allen Beteiligten dar – einschließlich dem Endbenutzer, den Produktions- und Entwicklungsteams und dem Produktbesitzer. Das Ziel dieser Zusammenarbeit besteht darin, ein gemeinsames Verständnis zu schaffen und den Wert der einzelnen User Story zu bestimmen. Was während dieses Gesprächs besprochen wird, sollte sich in dem widerspiegeln, was für die Karte geschrieben wird.

Bestätigung

Die Bestätigung ist ein Abnahmetest, bei dem der Product Owner bestätigt, dass die User Story auf Grundlage einer vorgegebenen Definition von „erledigt“ erfüllt wurde. Sie stellt die spezifischen Bedingungen dar, die erfüllt sein müssen, um die Ziele der User Story zu erfüllen.

So beginnen Sie mit dem Schreiben von User Stories

Wenn Sie bereit sind, mit dem Schreiben von User Stories zu beginnen, sollten Sie einige wichtige Punkte beachten.

1. Sprechen Sie mit Ihren Benutzern: Es mag offensichtlich klingen, aber eine der besten Möglichkeiten, mit der Erstellung von User Stories zu beginnen, besteht darin, Gespräche mit Ihren Benutzern zu führen. Auf diese Weise können Sie herausfinden, was sie von Ihrem Produkt oder Ihrer Dienstleistung erwarten und was Sie tun können, um sie zufrieden zu stellen.
2. Legen Sie eine Definition von „Erledigt“ fest: So stellt der Product Owner fest, ob die User Story abgeschlossen ist und die beschriebene Aufgabe nun vom Zielbenutzer erledigt werden kann.
3. Definiere das WHO : Das „Wer“ sollte sich auf eine bestimmte Rolle beziehen, für die die User Story bestimmt ist. Die Rolle sollte einen echten Endbenutzer widerspiegeln (wie den iOS-Benutzer in unserem Beispiel), was keine Mitglieder Ihres Teams wie einen Entwickler einschließt. Wenn es mehrere Benutzertypen gibt, möchten Sie möglicherweise mehrere Stories erstellen.
4. Definiere das Was : Das „Was“ stellt eine Aktion oder eine bestimmte Aufgabe dar. In unserem Beispiel ist die Aktion das Synchronisieren von Daten mit einer Apple Watch.
5. Definiere das Warum : Das „Warum“ sollte den Nutzen der User Story beschreiben, wie in unserem Beispiel die genauere Kalorienverfolgung.
6. Schreiben Sie User Stories in einfacher Sprache: User Stories sollten leicht nachvollziehbar und verständlich sein. Sie sollten die Perspektive und Wünsche des Zielbenutzers klar widerspiegeln, ohne zu kompliziert zu sein.

Beispiele und Vorlagen für User Storys

Die meisten User Stories folgen demselben Grundformat oder derselben User Story-Vorlage.

'Als ein [ Wer/Rolle ], Ich möchte [ was/Aktion ] damit ich kann [ Warum/Nutzen ].”

Unser Beispiel von vorhin passt genau in dieses Schema: „Als [ WHO: als iOS-Benutzer] möchte ich [ Was: Daten mit einer Apple Watch synchronisieren], damit ich [ Warum: „Verfolgen Sie den Kalorienverbrauch genauer.“

Diese Vorlage kann auf alle möglichen Produkte und sogar auf bestimmte Benutzertypen innerhalb dieses Produkts angewendet werden. Diese spezifische Struktur ist zwar nicht notwendig, kann Ihnen aber dabei helfen, darüber nachzudenken, welche User Stories für Ihr Produkt erforderlich sind.

Scheuen Sie sich nicht, mehrere User Stories zu erstellen – es ist sogar erwünscht! Indem Sie Ihre User Stories in umfassenden Epics und Initiativen organisieren, kann Ihr Team stetige und fortlaufende Produktverbesserungen sicherstellen, die den Wünschen und Bedürfnissen Ihrer Benutzer entsprechen.