Zusammenfassung & Übersicht
Eine User Story (US) ist ein kurzes, einfaches Beschreibungswerkzeug, das in der Produktentwicklung, insbesondere innerhalb agiler Frameworks wie Scrum und Kanban, verwendet wird, um den Backlog zu organisieren. Sie dient dazu, eine Anforderung / Funktionalität aus der Perspektive des Endbenutzers zu beschreiben. Ihr Hauptziel ist es, Wert zu liefern, indem sie den Fokus auf die Benutzererfordernisse legt und nicht auf die technischen Details, die oft für den Product Owner und das Team in den Backlogs gehalten werden. Eine klassische User Story setzt sich meist aus drei Elementen zusammen: einer Beschreibung der Zielgruppe (der "wer"), einem Bedürfnis (dem "was") und dem Nutzen bzw. dem Zweck (dem "warum"). Ein typisches Format für eine User Story ist: "Als ROLLE, möchte ich WUNSCH, um GRUND."
Stell dir eine Brücke vor, nicht irgendeine Brücke, sondern eine, die die Welt der Entwickler mit der Welt der Anwender verbindet. Diese Brücke ist aus Worten gewebt, geschaffen aus Verständnis und dem Wunsch, Technologie nutzbar zu machen. Im Herzen dieser Verbindung stehen die User Stories, kleine Narrative, die große Träume fangen. Doch was macht diese kurzen Erzählungen so mächtig in der Welt des Scrum, und wie nutzen Teams sie, um Produkte zu schaffen, die nicht nur funktionieren, sondern begeistern?
Dieser Artikel nimmt dich mit auf eine Reise in das Herz der agilen Produktentwicklung. Entdecke die Kunst und Wissenschaft hinter den User Stories, diese kleinen Wortperlen, die den Schlüssel zur Schaffung bedeutungsvoller, benutzerzentrierter Softwareerlebnisse halten. Bereite dich darauf vor, eingeweiht zu werden in die Geheimnisse, wie durch einfache Sätze Brücken gebaut werden, die die Lücke zwischen dem, was ist, und dem, was sein könnte, überbrücken.
Tauche ein in die Welt, in der jedes Wort zählt, jede Erzählung einen Zweck hat, und lerne, wie du diese Technik meistern kannst, um Produkte zu kreieren, die mehr sind als ihre Teile – Produkte, die Geschichten erzählen.
User Story Definition
Eine User Story ist ein kurzes, beschreibendes Format vor allem aus der agilen Softwareentwicklung, das eine (Software-)funktion aus der Sicht eines Endbenutzers in alltagssprachlicher Form festhält, ohne umfangreich auf eine Spezifikation zu setzen. Sie zielt darauf ab, Mehrwert zu liefern, indem sie den Fokus auf die spezifischen Bedürfnisse des Benutzers legt, und formuliert wird sie oft nach dem Schema: "Als [Rolle], möchte ich [Ziel/Funktion], um [Nutzen] zu erreichen." Dies hilft, die Entwicklungsarbeit auf die tatsächlichen Anforderungen der Anwender auszurichten und fördert zugleich eine enge Zusammenarbeit im Team sowie mit Stakeholdern. Sie müssen in einem Sprint umsetzbar sein, sonst gelten sie als Epics und müssen weiter refined werden, bis sie passend sind, dies erfolgt oft durch kleinere User Stories. Damit sie als fertig gelten, müssen sie der Definition of Done genügen.
Erstellung: Eine gute User Story schreiben
Die Beschreibung der Story orientiert sich immer am oben gezeigten Format. Damit ist die Formulierung der User Story schon sehr verständlich und sowohl für Stakeholder wie auch das Scrum Team eine gemeinsame Sprache, was die Umsetzung der User Story erleichtert.
Akzeptanzkriterien helfen immer dabei, Features zu zerlegen und in die präzise Klarheit zu gehen, was die Umsetzung der User Story erleichtert.
INVEST
Wohl fast zum Standard gehört das INVEST Akronym, welches sich eignet, um gut die User Story formulieren zu können. Eine gut formulierte User Story sollte klar und präzise sein, sodass die Teammitglieder sie verstehen. Das INVEST-Prinzip dient als wertvolle Richtschnur, um sicherzustellen, dass Anforderungen schnell und effektiv Wert für alle Beteiligten generieren. Sie beinhaltet:
Independent
Unabhängig: Jede Anforderung muss für sich allein stehen können, ohne dass die Realisierung anderer Voraussetzung für ihren Nutzen ist. Dies vermeidet die Abhängigkeit von mehreren Elementen für die Erzeugung von Wert und minimiert das Risiko, innerhalb einer Iteration nichts ausliefern zu können, sollten Herausforderungen auftreten.
Negotiable
Verhandelbar: Eine Anforderung ist flexibel und offen für Diskussionen. Sie ist niemals so detailliert festgelegt, dass keine Anpassung mehr möglich ist. Die bewusste Wahl einer offenen Beschreibung ermöglicht es, Inhalte schnell und effizient zu überarbeiten, um aufkommende Missverständnisse durch mangelnden Austausch zu vermindern.
Value
Wertstiftend: Der Hauptzweck jeder Anforderung ist es, einen eigenständigen Mehrwert zu schaffen, nicht lediglich als Mittel zu einem anderen Zweck zu dienen. Dies trägt zur Schaffung des Produktincrements bei, welches am Ende eines Sprints bereitstehen sollte.
Estimation
Schätzbar: Eine klare Schätzung ist notwendig, um das Ausmaß zu verstehen. Während Story Points häufig genutzt werden, sind sie laut Scrum Guide nicht obligatorisch.
Size
Angemessen groß: Eine Anforderung muss passend dimensioniert sein, um innerhalb einer Iteration umsetzbar zu sein. Zu umfangreiche Anforderungen werden als Epics klassifiziert und müssen in kleinere, handhabbare Teile zerlegt werden, typischerweise während des Refinements.
Test
Testbar: Eine solide Anforderung ermöglicht die Überprüfung durch Tester, Endanwender oder andere Stakeholder. Dabei helfen Akzeptanzkriterien aus der Perspektive des Benutzers, um die Durchführbarkeit von Tests zu garantieren und dem Product Owner die Kommunikation seiner Erwartungen zu erleichtern.
Zusammenfassung für die INVEST Kriterien
Du hast eben also die sogenannten INVEST Kriterien kennengelernt. Betrachtest du sie noch etwas genauer, dann wirst du erkennen, dass dort bereits viel für agile, interative und inkrementelle Entwicklung als Grundstein gelegt ist. Deswegen wird sie absolut gerne in der agilen Softwareentwicklung verwendet.
Die 3 C's
Card
Die "Story Card" kennst du bestimmt als Form bestimmt am ehesten, wenn du an eine User Story denkst. Denn das ist schließlich das Artefakt, mit dem du in Berührung kommst. Diese Sicht des Anwenders ist die geschriebene Karte bzw. die Abbildung in einem elektronischen Tool.
Conversation
Communication ist ein wichtiger Bestandteil, es geht dabei um das eingangs erwähnte Kommunikationsversprechen. Sie ist verhandelbar und es darf und soll darüber gesprochen werden. Zudem soll sie auch den Austausch darüber fördern.
Confirmation
Wir wollen erkennen, wann wir fertig sind. Wann ist der Wunsch umgesetzt? Die dafür verwendeten Akzeptanzkriterien zeigen uns genau das an.
Lösung und Zielorientierung
Ein spannender Punkt, den du bei vielen Teams findet und auf den du unbedingt mal achten solltest: sind deine Product Backlog Items und damit die Anforderungen zielorientiert oder lösungsorientiert?
Eine Entscheidung über die richtige oder falsche Verwendung einer der beiden Varianten kannst du nur für deinen Kontext fällen. Du nutzt immer eine der beiden Varianten bei der Formulierung der User Story. Und es hängt von deiner Umgebung ab. Machen wir ein Beispiel:
Zielorientierung bei einer User Story
Als Verkehrsteilnehmer möchte ich schnell von A nach B gelangen, um eine möglichst wenig Zeit zu verlieren.
Lösungsorientierung bei einer User Story
Als Autofahrer möchte ich mit dem Auto von A nach B gelangen, um meinen Zielort zu erreichen.
Natürlich wirst du nun argumentieren, dass die Rollen unterschiedlich sind und es vielleicht ja auch in deinem Kontext total klar ist, dass der Autofahrer von A nach B mit dem Auto gelangen soll und nicht mit dem Dreirad. Absolut klar und logisch für mich - darum geht es mir hier an der ersten Stelle gar nicht. Ich möchte einfach nur Bewusstseins schaffen für:
Die User Storys in Scrum
Agil: User Story Map
Mit einem Story Map und der Technik des Story Mappings, kannst du deinen Scrum Master bitten einen Workshop durchzuführen, in dem sie Sicht des Nutzers abgebildet wird und ihr ein gemeinsames Verständnis der Anforderungen über Klebezettel sauber darstellen könnt.
Innerhalb eines Sprints muss eine US umgesetzt sein, wenn diese im Sprint geplant wird.
Akzeptanzkriterien
Das Festlegen von Akzeptanzkriterien ist extrem wichtig, um ein gemeinsames Verständnis zu entwickeln. Die User Story definiert diese "Akzeptanztests" direkt mit auf der Karte (siehe 3C's - Conformation), damit jederzeit Teammitgliedern sofort klar ist, wann etwas akzeptiert sein wird. Manchmal entstehen kleinere User Storys daraus, da so auch erkannt werden kann, wenn US anhand von diesen Akzeptanzkriterien geschnitten werden kann.
Abgrenzung zum Epic
Eine große User Story kann ein Epics sein. Das ist nicht klar definiert, wird aber von anderen Frameworks und auch Erfahrungen aufgegriffen. Meistens gibt es zwei Sichten:
- Ein EPIC wird solange refined und verkleinert, bis es umsetzenbar ist
- Ein EPIC ist eine Art Container, innerhalb dessen weitere Abarbeitung stattfndet
Beispiele für User Stories
Folgende User Stories sind gute Beispiele, so dass die User hier im Fokus stehen.
Als Administrator möchte ich mich in die Oberfläche einloggen, um Benutzer anlegen zu können.
Als HR Mitarbeiter möchte ich Job Interviews dokumentieren, um das Wissen über die Kandidaten festhalten zu können.
Mehr darüber erfahren, neugierig auf Scrum? Die letzten Aussagen und Fragen!
- Entwicklungsteam heißt im Scrum Guide nicht mehr so, es wird nur noch Scrum Team und die Rolle / Verantwortlichkeit Entwickler unterschieden.
- Das Schreiben einer User Story dauert zunächst nur wenige Minuten.
- Beispiele für User Stories sind immer vom Kontext abhängig
- Je nach Domäne oder Branche gibt es unterschiedliche Typen von Akzeptanzkriterien
- Bekommt die User Story viele Story Points, dann lohnt es sich, diese zu schneiden (wenn möglich)
- User Stories helfen beim Verständnis von Anwendern und entstammen dem Extreme Programming
