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:
- Man beschreibt die Use Cases nur grob, ähnlich dem Beispiel oben. Statt eines Use Case Dokuments könnte man dafür auch Karten verwenden.
- Man nutzt Use Cases Slices zunächst als grobes Planungsinstrument, z.B. zur Releaseplanung: welche Slices sollen im Release X umgesetzt werden?
- Aus den Use Case Slices entwickelt man Epics, beispielsweise das Epic „Kunde findet Buch“.
- 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.
Diskussion
7 Antworten zu “Use Cases und User Stories – Verbündete oder Feinde?”
Schreibe einen Kommentar
Bertil Muth
Kontaktieren Sie Bertil MuthBertil 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.
Wissen, das bewegt!
Verpasse keinen der spannenden Artikel mehr auf blog.hood-group.com und melde dich für unseren Newsletter an! Erfahre alle 2 Wochen als Erster von den neuesten Branchentrends, erhalte exklusive Experten-Tipps und bleib über unsere Veranstaltungen immer auf dem Laufenden. Alles direkt in dein Postfach.
Jetzt abonnieren und keine wichtigen Insights mehr verpassen!
Use Cases bieten darüber hinaus noch wesentlich mehr, als das, was der Autor hier beschreibt.
Mit Extension Points und Include-Beziehungen kann ich Anforderungen durch bessere Strukturierung hervorragend beherrschein. Dies geht mit User Stories, die typischerweise auf Karten notiert und Wände geheftet werden nicht so einfach.
[…] Use Cases und User Stories – Verbündete oder Feinde? aus dem Hood-Blog […]
Wie steht ihr zu Use-Cases in Verbindung mit User-Stories zum dokumentieren von Nicht funktionalen Anforderungen?
Danke für die Frage. Meiner Meinung nach legen Use Cases den Schwerpunkt auf die funktionalen Abläufe – da liegt ihre Stärke. Es ist aber möglich, Use Cases mit sog. „Special Requirements“ zu verknüpfen – nicht-funktionale Anforderungen, die sich auf den Use Case beziehen. Wenn es sich um übergreifende, nicht auf einzelne Use Cases limitierte nicht-funktionale Anforderungen handelt, halten wir sie separat (als Teil der sog. „Supporting Information“).
Verwendet man ein UML-Diagramm, dann muss man den Begriff „Kunde“ in den Use Case Namen gar nicht, da es aus dem Diagramm klar hervorgeht, um welchen Akteur es sich handelt, also in diesem Fall der Kunde.
Sehr interessanter Artikel, wir stehen nämlich gerade an dem Punkt. Eine Frage dazu: UserStories werden bis zu letzt in den Details ja noch diskutiert (Empfehlungen vom Team, Rücksprachen mit dem Kunden, etc.). Aus meiner Sicht müssten die Details spätestens wenn die Story umgesetzt ist, im UseCase ergänzt werden. Aus meiner Sicht ist eine Story ein flüchtiges Artefakt, was wie auch hier beschrieben steht eher zur Planung gedacht ist.
Das kann man machen, wenn diese Details auch wirklich langfristig interessant sind.
Eine andere Möglichkeit wären z.B. Akzeptanzkriterien, die mittels Gherkin formuliert & automatisiert getestet werden.