User Stories vs. Use Cases vs. Job Stories (Beispiele)

User Stories, Use Cases, Job Stories und Anforderungsstatements sind vier Arten, festzuhalten, was Software tun sollte. Sie werden oft als Rivalen präsentiert, beantworten aber unterschiedliche Fragen auf unterschiedlichen Detailstufen. Eine User Story fragt, wer was und warum will. Ein Use Case durchläuft eine Interaktion Schritt für Schritt, einschließlich dessen, was schiefgehen kann. Eine Job Story beginnt mit der Situation, in der sich der Nutzer befindet. Eine Anforderung formuliert eine Regel, der das System folgen muss.

Dieser Leitfaden vergleicht die vier, zeigt dieselbe Funktion in jeder Variante und erklärt, wann man welche verwenden sollte. Für die Grundlagen des Schreibens von Stories siehe unseren Hub-Leitfaden zu wie man User Stories schreibt.

Schneller Vergleich

User Stories

Eine User Story ist eine kurze Beschreibung einer Fähigkeit, aus der Perspektive der Person, die sie benötigt. Das übliche Format, „Als [Nutzertyp] möchte ich [Aktion], damit [Nutzen]“, stammt vom Connextra-Team aus dem Jahr 2001 und verbreitete sich durch Mike Cohns Buch User Stories Applied. Stories entwickelten sich im Extreme Programming, wo sie bewusst kurz gehalten wurden: Ron Jeffries beschrieb jede Story als Karte, Gespräch und Bestätigung (die 3 Cs). Die Karte ist nicht die Spezifikation; im Gespräch werden Details vereinbart, und die Akzeptanzkriterien bestätigen diese.

Stärken: Stories sind klein genug, um in einem Sprint geschätzt und abgeschlossen zu werden, sind für nicht-technische Stakeholder leicht lesbar und halten den Wert („damit“) im Blick. Mike Cohn legt den Fall für sie in Vorteile von User Stories für Anforderungen.

Grenzen: Ein Backlog einzelner Stories zeigt nicht, wie sie zu einem Ablauf zusammenpassen, und das Format erleichtert es, Fehlerfälle zu übersehen. Teams beheben das Erste mit einer User Story Map und das Zweite mit gut formulierten Akzeptanzkriterien (siehe unsere User-Story-Vorlage).

Use Cases

Ein Use Case beschreibt, wie ein Akteur (eine Person oder ein anderes System) das System verwendet, um ein Ziel zu erreichen, als eine Abfolge von Schritten, zusammen mit den Wegen, auf denen diese Abfolge verzweigt oder fehlschlagen kann. Ivar Jacobson führte Use Cases Ende der 1980er Jahre ein, und Alistair Cockburns Buch Writing Effective Use Cases (2000) legte den zielorientierten, klarsprachigen Stil fest, den die meisten Teams heute verwenden (Cockburns Website).

Ein vollständiger Use Case umfasst in der Regel:

• Primärer Akteur: Wer die Interaktion startet.
• Ziel und Umfang: Was der Akteur möchte und welches System beschrieben wird.
• Voraussetzungen: Was bereits wahr sein muss.
• Auslöser: Was den Use Case startet.
• Haupterfolgsszenario: Die nummerierten Schritte, wenn alles richtig läuft.
• Erweiterungen: Alternative und Fehlerpfade, jeweils an den Schritt gebunden, an dem sie verzweigen.
• Endbedingungen oder Garantien: Was am Ende wahr ist, bei Erfolg und bei Fehlschlag.

Stärken: Der Abschnitt Erweiterungen zwingt dazu, über Fehler nachzudenken, und der gesamte Ablauf ist an einem Ort sichtbar, was für Integrationen, Zahlungen und alles, was geprüft wird, wertvoll ist. Grenzen: Use Cases dauern länger zu schreiben und aktuell zu halten, und ein Use Case ist in der Regel zu groß, um in einem Sprint gebaut zu werden.

Use Cases haben sich an agile Arbeit angepasst. In Use-Case 2.0teilen Jacobson und Kollegen jeden Use Case in „Slices“, die jeweils klein genug sind, um geplant und getestet zu werden, und die eine ähnliche Rolle wie User Stories spielen.

Job Stories (Jobs to be done)

Eine Job Story ersetzt die Persona durch die Situation: „Wenn [Situation], möchte ich [Motivation], damit ich [erwartetes Ergebnis].“ Die Idee wurde zuerst von Paul Adams im Intercom-Blog erwähnt und von Alan Klement weiterentwickelt, der sie in einem Gastbeitrag von 2013 bei Intercom erklärte, Job Stories zur Gestaltung von Funktionen nutzen. Sie wendet das Jobs-to-be-done-Denken, das mit Clayton Christensen verbunden ist, auf die Funktionsgestaltung an.

Das Argument für Job Stories ist, dass „Als beschäftigter Elternteil“ Annahmen enthält, die das Team nicht testen kann, während die Situation („Wenn ich das Haus verlassen will und merke, dass ich das Einkaufen vergessen habe“) die Dringlichkeit, die Einschränkungen und das Gefühl von „erledigt“ für den Nutzer erklärt. Zwei sehr unterschiedliche Personas in derselben Situation brauchen oft dasselbe.

Stärken: Job Stories sind gut in Discovery und Design, halten das Team auf den Kontext fokussiert und erzeugen bessere Fragen für Kundeninterviews. Grenzen: Sie sagen wenig darüber aus, wer was darf, was für Berechtigungen und Rollen wichtig ist, und die meisten Teams verwandeln sie für die Planung in User Stories oder Aufgaben.

Anforderungsstatements

Das traditionelle Format ist eine nummerierte Aussage: „Das System sperrt ein Konto nach fünf fehlgeschlagenen Anmeldeversuchen.“ Anforderungsspezifikationen sind in regulierten Branchen, öffentlichen Ausschreibungen und Festpreisverträgen nach wie vor üblich, und der aktuelle internationale Standard für ihre Formulierung ist ISO/IEC/IEEE 29148.

Agile-Teams verwenden ebenfalls Anforderungsbeschreibungen, vor allem für nicht-funktionale Anforderungen (Performance, Sicherheit, Verfügbarkeit, Barrierefreiheit), die über viele Stories hinweg gelten. Diese werden oft einmalig in der Definition of Done oder auf einer kurzen Seite zu Qualitätsattributen festgehalten, statt sie in jeder Story zu wiederholen.

Dasselbe Feature in allen drei Varianten

Feature: In einer App für gemeinsame Ausgaben unter Mitbewohnern zahlt eine Person für etwas und teilt die Kosten mit den anderen.

Als User Story

Als Mitbewohner, der für einen gemeinsamen Einkauf bezahlt hat, möchte ich die Kosten mit den Personen teilen, für die der Einkauf war, damit auf dem Saldo jeder Person ersichtlich ist, was sie mir schuldet.

• Ich kann wählen, welche Gruppenmitglieder die Kosten teilen; ich bin standardmäßig enthalten.
• Die Standardaufteilung ist gleichmäßig; ich kann auf exakte Beträge oder Prozentzahlen umstellen.
• Die App speichert keine Aufteilung, deren Anteile nicht zur Gesamtsumme passen, und zeigt an, um wie viel sie abweicht.
• Der Saldo jeder Person wird aktualisiert, sobald die Ausgabe gespeichert ist, und sie erhält eine Benachrichtigung.

Als Use Case

Use Case: Ausgabe teilen. Primärer Akteur: Zahler. Vorbedingung: Der Zahler ist angemeldet und gehört einer Gruppe mit mindestens einem weiteren Mitglied an. Auslöser: Der Zahler wählt „Ausgabe hinzufügen“.

1. Der Zahler gibt den Betrag, eine Beschreibung und das Datum ein.
2. Das System zeigt die Gruppenmitglieder an, wobei der Zahler ausgewählt ist.
3. Der Zahler wählt die Mitglieder aus, die die Kosten teilen.
4. Das System schlägt eine gleichmäßige Aufteilung vor und zeigt jeden Anteil an.
5. Der Zahler bestätigt.
6. Das System speichert die Ausgabe, aktualisiert jeden Saldo und benachrichtigt die ausgewählten Mitglieder.

• 4a. Der Zahler wechselt zu exakten Beträgen oder Prozentzahlen: Das System berechnet bei jeder Eingabe neu.
• 5a. Die Anteile addieren sich nicht zur Gesamtsumme: Das System blockiert das Speichern und zeigt die Differenz an.
• 6a. Das Gerät ist offline: Das System speichert die Ausgabe lokal, markiert sie als ausstehend und synchronisiert sie, sobald wieder eine Verbindung besteht.
• Nachbedingung bei Erfolg: Die Ausgabe wird einmal erfasst, und jeder Saldo spiegelt sie wider. Bei Fehler: Es ändern sich keine Salden.

Als Job Story

Wenn ich gerade an der Kasse für etwas bezahlt habe, das teilweise für meine Mitbewohner ist, möchte ich es festhalten, bevor ich den Betrag vergesse, damit ich ohne Nachfragen zurückbezahlt werde.

Als Anforderungsbeschreibungen

• REQ-1: Das System muss es einem Gruppenmitglied ermöglichen, eine Ausgabe mit Betrag, Beschreibung, Datum und Zahler zu erfassen.
• REQ-2: Das System muss es dem Zahler ermöglichen, eine Ausgabe gleichmäßig, nach exakten Beträgen oder nach Prozenten aufzuteilen.
• REQ-3: Das System muss eine Aufteilung ablehnen, deren Anteile nicht der Gesamtsumme entsprechen.
• REQ-4: Das System muss alle betroffenen Salden innerhalb von zwei Sekunden nach dem Speichern aktualisieren.

Schauen Sie, was jede Version zutage gefördert hat. Die User Story ist am einfachsten zu schätzen und zu planen. Der Use Case ist der einzige, der den Offline-Fall ansprach und festlegte, was gelten muss, wenn das Speichern fehlschlägt. Die Job Story deckte die eigentliche Einschränkung auf, nämlich die Geschwindigkeit an der Kasse; sie legt nahe, dass der erste Bildschirm nur nach dem Betrag fragen sollte – etwas, das keine der anderen Versionen nahegelegt hätte. Die Anforderungen fügten ein messbares Performance-Ziel hinzu, das in der Story implizit blieb.

Welche sollten Sie verwenden?

Kann man sie kombinieren?

Ja, und die meisten reifen Teams tun das. Eine praktikable Abfolge sieht so aus:

1. Nutzen Sie Job Stories während der Recherche, um Situationen und Motivationen echter Nutzer zu erfassen.
2. Ordnen Sie die resultierenden Fähigkeiten in einer Story Map als User Stories an und wählen Sie den ersten Release-Slice.
3. Für die ein oder zwei Abläufe, bei denen ein Fehler teuer ist (Zahlungen, Registrierung, Datensynchronisation), schreiben Sie einen schlanken Use Case, um die Erweiterungen zu finden, und wandeln Sie jede Erweiterung in eine eigene Story oder ein Akzeptanzkriterium um.
4. Erfassen Sie querschnittsrelevante Anforderungen (Leistung, Sicherheit, Barrierefreiheit, Compliance) einmalig als nummerierte Aussagen oder in der Definition of Done.

Faustregel: Schreiben Sie nur so viel, wie das Team braucht, um sicher das Richtige zu bauen. Ein MVP-Team aus drei Personen braucht kein Anforderungsdokument, und eine Bankintegration sollte nicht auf einem einzigen Satz beruhen.

Häufige Fehler

• Use Cases als Benutzeroberflächen-Skripte zu schreiben („Der Nutzer klickt auf den blauen Button“), was die Anforderung an ein Design bindet, das sich ändern wird.
• User Stories ohne „damit“ zu schreiben, was das Team daran hindert, eine einfachere Lösung vorzuschlagen.
• Eine Job Story als getarntes Persona zu behandeln („Wenn ich eine beschäftigte Mutter bin ...“); die Situation sollte ein Moment sein, keine Identität.
• Eine lange Anforderungsliste in ein Backlog zu kopieren, mit einer Story pro Zeile, was zu Stories ohne Nutzer und ohne Wert führt.
• Verschiedene Formate im selben Backlog zu verwenden, ohne eine Einigung darüber, welches die Quelle der Wahrheit ist.

Häufig gestellte Fragen

Nicht sicher, wie viel Spezifikation Ihr Produkt braucht? Wir helfen Gründern, Ideen in ein abgegrenztes Backlog zu verwandeln und es dann in kurzen Sprints zu bauen. Siehe unsere monatlichen Entwicklungspläne.