Eine User Story ist eine in einfacher Sprache formulierte Projekt-Anforderung. Sie ist bewusst kurzgehalten und umfasst in der Regel nicht mehr als zwei oder drei Sätze. Wie in den letzten Blogs erwähnt, bilden sie im Rahmen der agilen Zusammenarbeit ein zentrales Element. Dabei wird jede User-Story auf sogenannte eine Story-Card geschrieben. Sie sollte sollte den direkten Kundenutzen beschreiben und in enger Kooperation mit diesem formuliert worden sein. Die User Story ist der wichtigste Baustein, für die inhaltliche Steuerung eines agilen Vorhabens.
Wie im Blog Clevere Backlogs als Erfolgsfaktor für agiles Arbeiten und Digitalisierung bereits erwähnt, bildet die User Story eines der wichtigsten Werkzeug, um agile Projekte inhaltlich zu steuern. Sie transportiert die Wünsche des Kunden an ein Produkt oder eine Lösung.
Zischen einem Epic und den Tasks
Am Anfang steht immer der Product Owner. Er ist nah an den relevanten Stakeholdern und leitet aus deren Bedürfnissen Anforderungen ab oder entwickelt aus einer geschäftsbezogenen Vision seine Roadmap. Daraus ergibt sich der sogenannte Nordstern des agilen Vorhabens. Er gibt dem Team Orientierung und zeigt den Sinn und Zweck der Arbeiten auf. Zu Beginn ist es für den Product Owner meist einfacher, das Grosse und Ganze zu skizzieren. Die Roadmap zerteilt er in mehrere sogenannte Epics, die wiederum mehrere Anforderungen und User Stories umfassen können.
In einem agilen Framework sind Epics grosse Arbeitsbereiche. Tasks dagegen bilden die kleinste Arbeitseinheit. Somit könnten agile Anforderungen, die inhaltlich korrespondieren, hierarchisch aufgebaut sein.
Epic
Epic ist eine Geschichte auf höchster Abstraktionsstufe. Für einen Sprint ist sie zu groß. Der Product Owner zerlegt sie deshalb in mehrere kleinere User Stories.
User Story
Eine User Story enhält Anforderungen, geschrieben als kleine handhabbare Texte. Auf dieser Basis schätzt das Team den Realisierungsaufwand ein.
Task
Entwickler und Tester zerlegen User Stories in weitere Aufgaben. Wenn eine Aufgabe eine vereinbarte Zeitspanne überschreitet, kann sie in zusätzliche Aufgaben aufgeteilt werden.
Wie ist eine User Story aufgebaut?
User Stories schaffen bei Projektbeginn Klarheit über das Ziel, indem die Kundenanforderungen festgehalten werden.
Sie ist quasi eine Benutzergeschichte und beschreibt knapp und bündig die Anforderung des Kunden in Textform. Die Idee ist, dass der Kunde sich auf die Beschreibung seiner Bedürfnisse konzentrieren kann, ohne an formale Vorgaben gebunden zu sein. Dennoch gibt es minimale Strukturen welche folgendermassen aussehen könnten: „Als <Rolle> möchte ich <Funktion> um/weil <Nutzen>.“
Rolle („wer fordet etwas an?“)
Idealerweise beschreibt der zukünftige Nutzer des Systems oder der Nutzniesser der zukünftigen Lösung die Anforderungen. Damit sind Hintergründe und die grossen Ziele für den Entwickler transparent.
Funktion (Was wünscht sich der Anforderer?)
Je klarer und präziser der Wunsch in der User Story Platz findet, desto hilfreicher sind die Informationen für das Team, um die Anforderungen zu realisieren.
Nutzen (Warum ist das für den Geschäftsfall wichtig?)
Die Beschreibung des Grundes der Anforderung stellt dem Entwicklerteam weitere Informationen zur Verfügung.
Zusätzlich beschreibt der Kunde sogenannte Akzeptanzkriterien, welche festhalten, was erfüllt sein muss, damit die Anforderung als erfolgreich realisiert gilt.
vom einfachen Post-it bis zur Softwarelösung: finden Sie ihren persönlichen Weg zur perfekten User Story
Die Magie einer guten User Story
Formuliert man Anforderungen in Ich-Form, passiert etwas ganz Besonderes: Der Leser versetzt sich automatisch in die beschriebene Rolle hinein. Paul McCartney wurde in einem Interview einmal gefragt, warum die Songs der Beatles so beliebt seien. Unter anderem behauptete er, das sei darauf zurückzuführen, dass so viele Pronomen in ihren Liedern vorkommen. Denken Sie mal über die Lieder nach: She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car usw. Seiner Meinung nach konnten sich die Leute so besser mit den Liedern identifizieren. Gleiches gilt für die User Stories: Das Team versteht warum etwas umgesetzt werden muss.
Weiter hilft die einfache aber immer gleichbleibende Struktur dem Product Owner beim Priorisieren. Wäre der Backlog ein grosses Durcheinander, wäre es schwierig, herauszufinden, was das gewünschte Feature ist, wer es benötigt und was der Nutzen davon ist.
Einige Beispiele von User Storys
| Als… | möchte ich… | damit … |
| Linien-Controller | Habe ich geräteunabhängig jederzeit die Möglichkeit auf wichtige Real-Time Kennzahlen zu zugreifen | Ich die Betriebskosten frühzeitig steuern kann |
| Betriebsverantwortlicher | Sehe habe ich Überblick über alle an der Produktion beteiligten Lieferanten | Ich die Supply Chain optimieren kann |
| Als Kunde | Möchte ich sehen unter welchen Bedingungen ein Produkt produziert wurde | ich nachhaltig einkaufen kann |
| Sachbearbeiter | Möchte ich all die mir zugewiesenen Arbeiten in einem persönlichen Dashboard sichtbar machen | Ich effizient arbeiten kann |
Der Unterschied zwischen User Story und Use Case
User Stories sind nicht zu verwechseln mit Use Cases. Letztere kommen aus der klassischen Softwareentwicklung und stellen ebenfalls Anforderungen in natürlicher Sprache und im Kontext der Nutzer dar. Der Unterschied ist jedoch, dass Use Cases alle Erfolgs- und Misserfolgsszenarien des formulierten fachlichen Problems darstellen. Das Use Case bildet somit den gesamten Rahmen und beinhaltet mehrere Szenarien, die zu einer bestimmten fachlichen Anforderung passen. Eine User Story hingegen beschreibt ein ganz konkretes Szenario.
In eigener Sache: Interessieren Sie sich für Digitalisierung und digitale Transformation? Zögern Sie nicht, regelmässig auf unserer B2S University nach spannenden Informationen zu suchen oder schauen Sie bei einem unserer „Digital Afterworks“ vorbei.