Die Entwicklung eines neuen Produkts oder die Implementierung einer neuen Funktion sollte lohnend sein und Innovationen fördern. Wenn ein Entwicklungsteam jedoch stattdessen in der Erstellung umfangreicher Anforderungsdokumentationen mit erdrückend starren Richtlinien feststeckt, ist dies nicht immer der Fall. Traditionelle Softwareentwicklungsmethoden basierten stark auf der Einhaltung eines vorgegebenen Anforderungskatalogs für jede einzelne Funktion eines Produkts, einer Dienstleistung oder einer Anwendung. Dies fesselte die Teams an strenge Richtlinien und ließ ihnen kaum Spielraum für spontane Anpassungen auf Basis von Echtzeitdaten oder Kundenfeedback.

Ende der neunziger Jahre begannen Entwicklungsteams dann, agile Projektmanagementmethoden und die Idee einer kundenorientierten Vorgehensweise einzuführen. „Anwendergeschichte“ wurde geboren.

Eine User Story ist Eine kurze, in zwei bis drei Sätzen gehaltene Beschreibung einer oder mehrerer Funktionen eines Softwaresystems aus der Perspektive des Kunden/Endnutzers. User Stories sind in einfacher Sprache verfasst, d. h. sie enthalten keine übermäßig technischen Begriffe und sind daher leicht lesbar und verständlich. alle – nicht nur die Entwickler. Eine User Story für eine Fitness-App könnte beispielsweise lauten: „Als iOS-Nutzer möchte ich Daten mit einer Apple Watch synchronisieren, um meinen Kalorienverbrauch genauer zu erfassen.“

Diese Beschreibungen konnten von einem oder mehreren Beteiligten verfasst werden, darunter das Entwicklungsteam, Manager oder Kunden/Nutzer. Da User Stories flexibel sein und die Bedürfnisse der Nutzer widerspiegeln sollen, wurden sie oft auf Karteikarten oder Haftnotizen festgehalten und regelmäßig überarbeitet oder geändert.

Durch die Erstellung vereinfachter und nachvollziehbarer Anforderungsbeschreibungen konnten sich die Entwicklungsteams darauf konzentrieren, die von ihren Nutzern gewünschten Funktionen und Aktualisierungen schnell bereitzustellen.

Was ist eine User Story in agilen Umgebungen?

Stellen Sie sich vor, Sie planen eine Autoreise und müssen jede einzelne Wegbeschreibung aufschreiben, bevor Sie überhaupt das Haus verlassen. Und selbst wenn Sie dann losfahren, müssen Sie sich strikt an diese Anweisungen halten, selbst wenn unterwegs eine bessere Route oder eine interessante Sehenswürdigkeit auftaucht. So ähnlich war es früher, vor der agilen Softwareentwicklung.

User Stories wurden entwickelt, um die traditionelle Anforderungsdokumentation zu ersetzen. Deren Erstellung war für Teams extrem zeitaufwendig und schränkte Entwickler oft von Anfang an auf eine einzige Vorgehensweise ein. Alle Anforderungen mussten in der Planungsphase detailliert ausgearbeitet werden, und die Entwickler waren an diese Vorgaben gebunden, ungeachtet etwaiger Änderungen oder auftretender Probleme. User Stories vereinfachen die Arbeit von Entwicklern und Produktionsteams an neuen Produktaktualisierungen und Funktionen, indem sie kleine, regelmäßige Updates in den Vordergrund stellen, die sich daran orientieren, was dem Endnutzer den größten Nutzen bringt.

Um es mit den Worten von Mike Cohn, einem der Gründer von Agile, zu sagen Scrum-Methoden Eine User Story sollte „den Fokus vom Schreiben über Anforderungen zum Sprechen darüber verlagern“. Extreme Programming (XP) Der Autor und Schöpfer war der Ansicht, dass es für Entwicklungsteams vorteilhafter sei, einen „gerade ausreichenden“ Ansatz zu verfolgen, der sich darauf konzentriert, den Nutzern einen beständigen Mehrwert zu bieten.

Agile User Stories boten Teams deutlich mehr Flexibilität und ermöglichten es ihnen, ihren Kunden kontinuierlich neue Funktionen und Updates bereitzustellen – oft in Echtzeit. Anstelle großer Produkt-Releases legte die agile Softwareentwicklung Wert darauf, die Ergebnisse in kleinere, besser handhabbare Einheiten zu unterteilen, um die Kunden zu begeistern und den Produkt-Backlog voranzubringen. Dies half auch, das häufige Problem zu vermeiden, zu viel preiszugeben und an etwas zu arbeiten, das möglicherweise nicht im besten Interesse der Nutzer liegt.

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

In der agilen Methodik sind User Stories Bestandteil eines sogenannten Epics. Epics beschreiben ein größeres Arbeitspaket, das in einzelne User Stories unterteilt wird. Diese Epics sind wiederum Teil einer übergeordneten Initiative, die mehrere verwandte Epics und deren User Stories umfasst. Initiativen und Epics ermöglichen es Teams, verschiedene User Stories anhand gemeinsamer Ziele zu organisieren.

Kehren wir zu unserem Beispiel mit der fiktiven Fitness-App zurück. Unsere Beispiel-User-Story beschrieb, wie ein iOS-Nutzer Daten von seiner Apple Watch synchronisieren möchte. Eine separate User-Story könnte sich hingegen auf Android-Nutzer und andere Fitness-Tracker konzentrieren. Beide User-Storys könnten dann unter einem Epic wie „Verbesserung der Fitness-Tracking-Funktionalität für den Start im ersten Quartal“ zusammengefasst werden. Die übergeordnete Initiative könnte in diesem Fall lauten: „Nutzerzahl um 3 % steigern“.

Gemeinsam tragen User Stories dazu bei, Epics voranzutreiben, wodurch Teams letztendlich vollständige Initiativen mit kontinuierlichen Verbesserungen für den Endnutzer realisieren können. Dadurch sind Teams in der Lage, Updates häufiger bereitzustellen und sogar schneller auf Anfragen von Nutzern und Kunden zu reagieren.

Die Vorteile agiler User Stories

Die Verwendung agiler User Stories gegenüber der traditionellen Anforderungsdokumentation bietet vier wesentliche Vorteile:

1. Mehr Flexibilität für das Entwicklungsteam. User Stories befreien das Entwicklungsteam von der Notwendigkeit, starre und einschränkende Dokumentationen zu befolgen, die zu Beginn des Produktionsprozesses erstellt wurden. Dadurch wird verhindert, dass Entwickler auf eine einzige Lösung festgelegt werden, und sie erhalten die Flexibilität, an innovativen Funktionen und Updates zu arbeiten.
2. Software-Updates erfolgen schneller. Agile Entwicklung konzentriert sich auf die Bereitstellung kleiner, aber kontinuierlicher neuer Funktionen und Updates anstatt auf den traditionellen Ansatz, alles auf einmal zu implementieren. Dies hält das Entwicklungsteam motiviert, da der Produkt-Backlog kontinuierlich vorangetrieben wird. Zudem müssen Entwickler keine Zeit mehr mit dem Schreiben langer und detaillierter Anforderungsdokumentationen verbringen.
3. Die Teams können sich auf das konzentrieren, was am wichtigsten ist – den Nutzer. User Stories helfen Entwicklungsteams, sich auf die für den Nutzer wichtigsten Funktionen zu konzentrieren. Sie ermöglichen es den Teams außerdem, schneller und in Echtzeit auf Nutzeranforderungen zu reagieren, da Aktualisierungen in kleineren Abschnitten erfolgen. Ziel von User Stories ist es, dass die Teams einen Schritt zurücktreten und verstehen, was die Nutzer von dem jeweiligen Dienst erwarten und benötigen.

Die 3 Cs von User Stories

Ein weiterer XP-Entwickler, Ron Jeffries, popularisierte die Idee, User Stories in die von ihm so genannten „3 Cs“ zu unterteilen. Laut Ron sollten User Stories alle diese drei wesentlichen Elemente enthalten:

Karte

Die Karte ist eine kurze, 2-3 Sätze umfassende Beschreibung der jeweiligen User Story. Die Karte muss folgende Punkte ansprechen: WHO (eine bestimmte Benutzerrolle), Was (die gewünschte Aufgabe oder Handlung), und Warum (der Nutzen aus der Erledigung dieser Aufgabe oder Handlung).

Gespräch

Das Gespräch stellt eine vereinbarte Diskussion zwischen allen Beteiligten dar – einschließlich Endnutzer, Produktions- und Entwicklungsteams sowie dem Product Owner. Ziel dieser Zusammenarbeit ist es, ein gemeinsames Verständnis zu schaffen und den Wert der einzelnen User Story zu bestimmen. Die Inhalte dieses Gesprächs sollten in die Dokumentation der User Story einfließen.

Bestätigung

Die Bestätigung ist ein Abnahmetest, in dem der Product Owner bestätigt, dass die User Story anhand einer vorab festgelegten Definition von „Fertig“ erfüllt wurde. Sie stellt die spezifischen Bedingungen dar, die erfüllt sein müssen, um die Ziele der User Story zu erreichen.

Wie man mit dem Schreiben von User Stories beginnt

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

1. Sprechen Sie mit Ihren Nutzern: Es mag offensichtlich klingen, aber einer der besten Wege, User Stories zu erstellen, ist, mit Ihren Nutzern ins Gespräch zu kommen. So finden Sie heraus, was sie von Ihrem Produkt oder Ihrer Dienstleistung erwarten und wie Sie sie zufriedenstellen können.
2. Eine Definition für „Fertig“ festlegen: Auf diese Weise ermittelt der Product Owner, ob die User Story abgeschlossen ist und ob die beschriebene Aufgabe nun vom Zielbenutzer ausgeführt werden kann.
3. Definiere die WHO : Das „Wer“ sollte die spezifische Rolle beschreiben, für die die User Story gedacht ist. Diese Rolle sollte einen realen Endbenutzer (wie den iOS-Benutzer in unserem Beispiel) widerspiegeln und keine Teammitglieder wie Entwickler umfassen. Bei mehreren Benutzertypen empfiehlt es sich, mehrere User Stories zu erstellen.
4. Definiere die Was : Das „Was“ steht für eine Aktion oder eine spezifische Aufgabe. In unserem Beispiel ist die Aktion die Synchronisierung von Daten mit einer Apple Watch.
5. Definiere die Warum : Das „Warum“ sollte die Vorteile der Nutzergeschichte beschreiben, wie zum Beispiel die genauere Kalorienerfassung in unserem Beispiel.
6. Benutzergeschichten in einfacher Sprache schreiben: User Stories sollten leicht verständlich und nachvollziehbar sein. Sie sollten die Perspektive und die Wünsche des Zielnutzers klar widerspiegeln, ohne dabei übermäßig kompliziert zu sein.

Beispiele und Vorlagen für User Stories

Die meisten User Stories folgen dem gleichen Grundformat bzw. der gleichen User-Story-Vorlage.

„Als [ wer/Rolle ], ich möchte [ was/Aktion ] damit ich kann [ warum/nutzen ].'

Unser vorheriges Beispiel passt genau in diese Gliederung: „Wie [ WHO: [iOS-Nutzer], ich möchte [ Was: Daten mit einer Apple Watch synchronisieren], damit ich [ Warum: „Verbrannte Kalorien genauer erfassen.“

Diese Vorlage lässt sich auf verschiedenste Produkte und sogar auf spezifische Nutzertypen innerhalb eines Produkts anwenden. Die vorgegebene Struktur ist zwar nicht zwingend erforderlich, kann Ihnen aber als Ausgangspunkt dienen, um die benötigten User Stories für Ihr Produkt zu formulieren.

Scheuen Sie sich nicht, mehrere User Stories zu erstellen – im Gegenteil, es wird sogar empfohlen! Indem Sie Ihre User Stories in übergeordneten Epics und Initiativen organisieren, kann Ihr Team stetige und kontinuierliche Produktverbesserungen sicherstellen, die den Wünschen und Bedürfnissen Ihrer Nutzer entsprechen.