Share ZU:
15 May 2013 @ Bertil Muth

Use Cases und User Stories – Verbündete oder Feinde?

Sind Use Cases und User Stories dasselbe?

Und wenn nein, was sind dann die Unterschiede? Kann man sie in der Praxis miteinander verbinden, oder sollte man sich lieber für eine Seite entscheiden?
Zunächst: dasselbe sind sie nicht.
Use Cases

Bei Use Cases geht es darum, Interaktionen von Nutzern mit einem System so zu beschreiben, dass das Ziel der Nutzer klar wird. Nutzer können dabei sowohl Menschen als auch andere technische Systeme sein.
Als Kunde eines Online-Buchhandels ist es z.B. mein Ziel, ein Buch zu kaufen.
Welche Interaktionsschritte sind nun notwendig, um das Ziel zu erreichen? Im Gutfall etwa folgende:

1. Kunde findet Buch.
2. Kunde legt Buch in Warenkorb.
3. Kunde geht zur Kasse.
4. Kunde gibt seine Adressdaten und Zahlungsdaten ein.
5. Kunde bestätigt Kauf.
6. System zeigt bestätigten Kauf und versendet Email mit Kaufbeleg an Kunden.

Je nach Einsatzzweck kann man Use Cases auch sehr viel detaillierter beschreiben, insbesondere ist natürlich auch noch eine Beschreibung der Fehlerfälle notwendig.

User Stories

User Stories erfreuen sich gerade im agilen Bereich großer Beliebtheit. Für die Beschreibung von User Stories hat sich folgende Vorlage eingebürgert :
“Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>.”
Beispiel: “Als Kunde des Online-Buchhandels möchte ich Bewertungen anderer Käufer lesen, um mich für oder gegen den Kauf eines Buches entscheiden zu können.”

Was sind nun Unterschiede zwischen Use Cases und User Stories?

  • Traditionell werden Use Cases oft sehr detailliert beschrieben, um als Anforderungsspezifikation oder Dokumentation der Systemfunktionalität benutzt zu werden. User Stories werden dagegen bewusst nicht als Dokumentationsinstrument eingesetzt, sondern lediglich als Basis, um persönlich über Anforderungen zu reden.
  • User Stories werden als Planungsinstrument eingesetzt, das heißt so lange “kleingeschnitten”, bis sie in einem festgelegten Zeitraum einer Iteration umgesetzt werden können. Dadurch sind sie klein und kompakt, im Vergleich zu Use Cases mangelt es ihnen aber oft an Kontextinformationen.

Diese Unterschiede lassen es so erscheinen, als würde man Äpfel mit Birnen vergleichen: ein schwergewichtiges Dokumentationsinstrument mit einem leichtgewichtigen Planungsinstrument. Prominente Methodiker wie Martin Fowler und Alistair Cockburn gehen daher mittlerweile davon aus, dass es sich um zwei verschiedene Instrumente handelt, die sich nicht gegenseitig ausschließen, sondern je nach Einsatzzweck und auch ergänzend zu einander verwendet werden können. Ich stimme dem zu.
Aber wie verwendet man sie denn geschickt zusammen, wenn man das will, wie sieht der Zusammenhang aus? Auf diese Frage erhält man leider nur selten eine Antwort.

Der Zusammenhang

Der Zusammenhang zwischen User Stories und Use Cases wird deutlich, wenn man die fehlenden Stücke des Puzzles ergänzt, d.h. wenn man Use Cases um Planungsaspekte ergänzt und User Stories um Kontextaspekte. Dafür nenne ich zwei Beispiele, sicher findet man im Universum der Instrumente weitere.

  • Im Use Case 2.0 Ansatz von Ivar Jacobsen wird der Begriff der “Use Case Slices” verwendet. Slices dienen dazu, die Umsetzung von Use Cases zu planen. Ein Slice ist im Wesentlichen ein Schnitt durch einen Use Case, der in einer Iteration umgesetzt werden kann. Ein Slice ist also, wie eine User Story, ein Planungsinstrument – er kann aus einem oder mehreren Interaktionsszenarien bestehen, oder aus dem ganzen Use Case.
  • Im agilen Bereich werden häufig “Epics” als grobgranulare Erzählungen verwendet, um feingranulare User Stories in einen Kontext zu setzen. Die Zuordnung von User Stories zu Epics kann z.B. über das Instrument der Story Maps erfolgen. Interessant an diesem Instrument für unser Thema ist, dass die Epics manchmal auch als “Aktivitäten” bezeichnet werden, und entlang eines Ablaufs waagrecht angeordnet werden. Erkennen Sie die Ähnlichkeit zu Interaktionsszenarien wie dem oben für Use Cases beschriebenen?

Kombinierte Verwendung von Use Cases und User Stories

Eine kombinierte Verwendung beider Instrumente, Use Cases und User Stories, im agilen Bereich könnte nun beispielsweise wie folgt aussehen:

  1. Man beschreibt die Use Cases nur grob, ähnlich dem Beispiel oben. Statt eines Use Case Dokuments könnte man dafür auch Karten verwenden.
  2. Man nutzt Use Cases Slices zunächst als grobes Planungsinstrument, z.B. zur Releaseplanung: welche Slices sollen im Release X umgesetzt werden?
  3. Aus den Use Case Slices entwickelt man Epics, beispielsweise das Epic “Kunde findet Buch”.
  4. Man verwendet Story Maps, um von den Epics zu den User Stories zu gelangen, und benutzt User Stories als feines Planungsinstrument (z.B. zur Iterationsplanung). Beispielweise könnte es eine User Story geben für “Kunde findet Buch über Suche”, und eine andere Story für “Kunde findet Buch über persönliche Empfehlung des Systems”.


Fazit: sowohl Nutzer von User Stories als auch von Use Cases können von einem Wechsel der Perspektive profitieren. Wenn Sie Use Cases verwenden: müssen Sie wirklich ein Dokument schreiben, oder wäre auch eine stichpunktartige Aufzählung der Schritte auf einer Karte ausreichend, um den Kontext zu verstehen? Wenn Sie User Stories verwenden: haben Sie Probleme damit, den Kontext zu verstehen, und wenn ja, wären Use Cases vielleicht eine Ergänzung, die Ihnen helfen würde? Jenseits von festgefahrenen Wertvorstellungen und ideologischen Grabenkämpfen lohnt sich sachlich betrachtet immer der Blick auf die andere Seite..

Haben Sie Interesse an diesem Thema?
Dann kontaktieren Sie uns. Möchten Sie mehr zum Thema “User Cases und User Stories” erfahren? Dann empfehle ich Ihnen, eines unserer beliebten Trainings zum Requirements Engineering zu besuchen. Ob der Intensivworkshop zur IREB® CPRE-Foundation Level Zertifizierung, oder das Training zum Certified Agile Requirements Specialist (CARS), es ist sicher etwas für Sie dabei.

Bertil Muth

Kontaktieren Sie Bertil Muth

Bertil Muth arbeitet als Agiler Coach, Scrum Master und Trainer. Mit Leidenschaft setzt er sich für konstruktive Zusammenarbeit, dezentralisierte Entscheidungsfindung und technische Exzellenz in der Produktentwicklung ein.