klauskuenen.de | Innovation, eCommerce, Strategie
Innovation, eCommerce, Strategie

User Stories vs. Use Cases

Ein Artikel zur Differenzierung von Use Cases und User Stories

Die Autorin Ursula Meseberg kommt darin zu dem Fazit, dass Use Cases im Einsatz bei der agilen Entwicklung ein wesentlicher Erfolgsfaktor sind.

Mein Favorit sind die User Stories

Nur hier bildet sich die Bedürfnisse der Kunden ab. Bei der Entwicklung von Use Cases besteht die Gefahr, dass bereits zu Beginn aus Produktsicht skizziert wird. Damit werden schon an dieser Stelle die Weichen für eine zu Produktbezogene Betrachtung und Bewertung gestellt.

Hier der gesamte Artikel:

Use Case 2.0: Agile Projektplanung mit Use Case Slices

Ein ungehobener Schatz

Use Case 2.0 ist eine skalierbare, agile Technik zur Entwicklung von Anforderungen, mit denen sich die inkrementelle Systementwicklung steuern lässt. Ihre Besonderheit liegt in der Integration etablierter Techniken des Requirements Engineering in eine agile Vorgehensweise. Damit bieten Use Cases auch in agilen Projekten Vorteile, die diese so nicht erwartet haben.

Sind Use Cases (oder Anwendungsfälle) überhaupt noch ein zeitgemäßes methodisches Konzept? Ivar Jacobson definierte 1987 auf der OOPSLA [1] einen Use Case als „a special sequence of transactions, performed by a user and a system in a dialogue“. Heute, mehr als 25 Jahre später, sind Use Cases noch immer quicklebendig, und zwar nachweislich: So zeigt eine Studie aus dem Jahr 2013 [2], dass derzeit 73 Prozent der befragten Unternehmen Use Cases einsetzen. Ein Viertel davon seit mehr als zehn Jahren. Deutsche Unternehmen stehen damit nicht allein: Nach einer ebenfalls 2013 durchgeführten Umfrage in der Schweiz [3] verwenden dort 51 Prozent der Befragten Use Cases für die Spezifikation von Anforderungen. Das ist naheliegend, denn sie beantworten aus Sicht des Anwenders die Frage, was das geplante System leisten soll.

Agil nur mit User Stories?

Anders sieht es in Unternehmen aus, die sich für agiles Vorgehen entschieden haben. Hier werden zum Erfassen der Anwenderwünsche User Stories eingesetzt. 2001 grenzte Ron Jeffries [4] mit seiner 3C-Formel „soziale“ User Stories von der „dokumentarischen“ Anforderungserhebung mit Use Cases ab. Das erste C steht für Card, also Karte. User Stories sollen so kurz und prägnant sein, dass sie auf reale Karten (z. B. Haftnotizen oder Karteikarten) passen. Dieser Platz sollte ausreichen, um dem Team klarzumachen, was das Ziel bei der Umsetzung der Story ist.

User Stories sind keine Anforderungen, die so weit verfeinert sind, dass mit einem Satz alles gesagt ist. Es wird lediglich ein einzelner Satz festgehalten. Was der Kunde darüber hinaus zur Anforderung zu sagen hat, wird nicht aufgeschrieben, sondern in Gesprächen geklärt. Dafür steht das zweite C: Conversation. Stories werden in der Regel sogar mehrmals besprochen, zum Beispiel im Verlauf eines Anforderungsworkshops, in einer Schätzklausur und während der Sprint-Planung.

Um einen Nachweis zu haben, ob die Stories in der vom Anwender gewünschten Weise implementiert wurden, werden für jede Story Akzeptanzkriterien festgehalten. Und dafür steht das dritte C: Confirmation. Für die Formulierung von User Stories werden Textschablonen vorgeschlagen wie: „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> zu erhalten.“ Und für die Rückseite: „Angenommen <Vorbedingungen>, wenn <Aktion>, dann <Ergebnis>.“ Das bedeutet: Auf der Rückseite stehen die Akzeptanztests, die die implementierte User Story bestehen muss.

User Stories werden für die Projektplanung priorisiert. Das wichtigste Kriterium dafür ist der Anwendernutzen. Je umfangreicher agile Projekte werden, desto stärker tritt das Manko von User Stories zu Tage: Teams beklagen, dass das Big Picture, also der Überblick über die Systemfunktionalität, verloren geht. Use Cases, dargestellt in Use-Case-Diagrammen der UML, zeigen gerade hier ihre Stärke. Sie geben einen Überblick über das Verhalten eines Systems und zeigen auf, wie es benutzt wird. Nach heutigem Verständnis fasst ein Use Case alle Folgen von Anwender-System-Interaktionen zusammen, die auftreten können, wenn ein Anwender ein fachliches Ziel mit einem geplanten System erreichen will.

Ein Use Case ist also ein spezifisches Verhalten eines Systems, das dazu beiträgt, ein Business-Ziel zu erreichen. Nicht nur die User Story ist darauf fokussiert, einen Wert für den Anwender zu schaffen. Auch Use Cases stellen den Anwendernutzen in den Vordergrund. Warum passen aber Use Cases scheinbar nicht zu modernen, agilen Entwicklungstechniken? Sie sind in der Regel zu umfangreich, um in einem typischen Sprint von zwei bis drei Wochen realisiert zu werden. Und: Ein Use Case bildet meist den Kontext für mehr als eine Anforderung.

Zahllose Quellen im Internet beschäftigen sich mit der Ableitung von User Stories aus Use Cases. Aber Zweifel sind angebracht: Ist es wirklich sinnvoll, ein Konzept in ein anderes zu transformieren, eine sprachliche Form in eine andere zu „übersetzen“? Wäre es nicht vernünftiger, in derselben methodischen Welt zu bleiben? Kann man nicht auch direkt mit Use Cases agil planen? Ja, man kann.

Agilität mit Use Case 2.0

Im Dezember 2011 veröffentlichten Ivar Jacobson, Ian Spence und Kurt Bittner das Konzept Use Case 2.0 [5]. Es beschreibt eine skalierbare, agile Technik zur Entwicklung von Anforderungen, mit denen sich die inkrementelle Systementwicklung steuern lässt. Die Prinzipien des Konzeptes sind:

  • Beschreibe Dinge einfach – mit Geschichten (durch „Storytelling“).
  • Verstehe das „Big Picture“.
  • Stelle den Nutzen in den Mittelpunkt.
  • Baue das System scheibchenweise („in Slices“).
  • Liefere das System in Inkrementen.
  • Beachte die Bedürfnisse des Teams.

Die Problemlösung für agile Projektplanung mit Use Cases liefert die Technik des „Slicings“ – das Aufschneiden eines Use Case in kleinere Einheiten, die sich dann innerhalb eines Sprints realisieren lassen. Wie funktioniert also scheibchenweises Bauen?

Erinnert sei noch mal an die Definition: „Ein Use Case ist eine Folge von Aktionen eines Systems, die ausgeführt wird, um ein sichtbares Ergebnis von Wert für Anwender oder andere Stakeholder zu generieren.“ Die Aktionsfolgen eines Use Case werden herkömmlich mit einem Textverarbeitungsprogramm dokumentiert. Häufig setzt man dazu spezielle Dokumentvorlagen ein. Darin wird zunächst das Hauptszenario beschrieben – das heißt der erfolgreiche Durchlauf eines Use Case. Dann beschreibt man die alternativen Szenarien. Sie definieren, was passiert, wenn Ereignisse eintreten, die den geraden Weg zum Erfolg verhindern. Use Case 2.0 verwendet eine andere Terminologie, die eine eher grafisch orientierte Beschreibungstechnik nahelegt.

Und Schnitt …

In Use Case 2.0 wird für jeden Use Case zunächst jeweils der „Basic Flow“ festgehalten. Er entspricht dem herkömmlichen Hauptszenario, ist also eine Folge von Schritten, die auf „geradem“ Weg zum erfolgreichen Abschluss des Use Case führt. Zu einigen Schritten und Schrittfolgen des Basic Flow gibt es im Regelfall Alternativen, das heißt bedingungsabhängige Abweichungen vom „geraden“ Weg. Diese Umwege werden als „Alternative Flows“ bezeichnet.

Jeder Weg vom Start eines Use Case bis zu seinem Ende – egal, ob er geradlinig ist oder über ein paar Umwege führt, wird, sofern er denn sinnvoll ist und einen Nutzen für den Anwender schafft, als „Story“ bezeichnet. Jede Story sollte eine Geschichte eines Anwenders bei der Benutzung des Systems erzählen. Um eine Story im Sinne von Use Case 2.0 von der User Story agiler Methoden im Folgenden unterscheiden zu können, sei sie hier „Use Case Story“ genannt.

Wie hilft dieses Verständnis der Struktur von Use Cases bei der agilen Projektplanung? Je nach Umfang werden eine oder mehrere Use Case Stories zu einer Planungseinheit – einem Use Case Slice – zusammengefasst.

 

Zu einem Use Case Slice gehören aber nicht nur Use Case Stories in Form von Start-Ende-Flows durch den Use Case. So wie bei agilen Methoden zu einer User Story immer Akzeptanzkriteren definiert werden, ist auch ein Use Case Slice ohne Testfall nicht vollständig. Das heißt, zu ihm gehört immer mindestens ein Testfall. Dabei können zwei Use Case Slices die gleichen Use Case Stories enthalten, sich aber durch ihre Testfälle unterscheiden.

Die so gebildeten Use Case Slices eigenen sich als Planungseinheiten sowohl für einen Backlog-orientierten agilen Ablauf, wie ihn Scrum definiert, als auch für Workflow-orientiertes Vorgehen etwa nach Kanban. Er ist unter anderem auch im Rahmen des Scaled Agile Framework (SAFe) einsetzbar. Der Einsatz mit Scrum soll hier exemplarisch vertieft werden.

Use Case 2.0 und Scrum

Wie greifen das Use Case Slicing und Scrum ineinander? Ein aus Use Case Stories und Testfällen gebildetes Use Case Slice wird als Backlog-Item in das Product Backlog der agilen Entwicklung eingestellt. Bevor der Scrum-Ablauf beginnen kann, muss das Product Backlog zu einem gewissen Grad gefüllt sein. Es sind also Use Cases identifiziert und daraus Use Case Slices abgeleitet. Use Case 2.0 setzt nicht voraus, dass zu Beginn eines Projekts alle Use Cases vollständig definiert werden. Um erste Backlog-Items zu gewinnen, genügt es, einige zentrale Use Cases zu identifizieren.

Zuerst sind die Stakeholder des Projekts – also alle, die an dem Projekt ein Interesse haben – zu identifizieren. Dazu zählen auch die Anwender beziehungsweise die Akteure, die direkt mit dem System arbeiten. Ihre Ziele müssen verstanden werden. Denn Use Cases dienen immer dazu, Ziele der Anwender zu erreichen. Auf dieser Grundlage kann man damit beginnen, Use Cases zu ermitteln. Dafür eignet sich ein Workshop mit den Stakeholdern. Ausgangspunkt bei der Entwicklung von Use Cases sind natursprachliche Use-Case-Beschreibungen („Narratives“). Bei der Entwicklung von Use Cases kann man ein Top-down-Vorgehen (vom Use Case ausgehend einzelne Schritte und alternative Abläufe finden) oder ein Bottom-up-Vorgehen (per Brainstorming alle möglichen Abläufe sammeln und zum Use Case zusammenfassen) wählen oder beide Vorgehensweisen kombinieren.

Sobald eine Reihe stabiler Use Cases identifiziert ist, lässt sich parallel zur weiteren Use-Case-Analyse damit beginnen, die gefundenen Use Cases durch Storytelling der Anwender genauer zu verstehen, ihre Flows detailliert zu beschreiben und Use Case Stories zu bilden. Hilfreich ist es, bei der Beschreibung der Abläufe bereits die Testfälle „mitzudenken“, sie also zur gleichen Zeit wie die Use Case Flows zu entwickeln. Sobald Use Case Stories definiert sind, können Stakeholder, Entwickler und Tester in Zusammenarbeit Slices bilden. Das erste sollte immer auf dem Basic Flow aufbauen. Slices sind so klein zu wählen, dass sie sich in einem Sprint umsetzen lassen. Ein Use Case muss allerdings nicht komplett „aufgeschnitten“ werden. Es reicht aus, die Slices zu bilden, die für den Arbeitsfortschritt notwendig sind und die restlichen Use Case Stories erst bei Bedarf weiter aufzuspalten.

Die Slices werden in das Product Backlog – also in den Bestand aller zu realisierenden Backlog Items – übernommen. Dort muss sie der Product Owner nach den Kriterien Priorität, Wert, Risiko und Notwendigkeit gewichten. Liegen gewichtete Backlog Items vor, kann der Entwicklungsprozess nach Scrum beginnen, während gleichzeitig dazu an der Entwicklung und dem Slicing weiterer Use Cases gearbeitet wird. Wenn Use Cases noch nicht in Slices unterteilt sind, lassen sie sich bereits als Platzhalter-Slice ins Backlog aufnehmen und später „klein schneiden“. Sobald das Product Backlog vorbereitet ist, kommt das Entwicklerteam zum Zug: Es schätzt die hoch priorisierten Slices im Product Backlog, wählt Slices für den nächsten Sprint aus und übernimmt sie ins Sprint Backlog – genau so, wie es auch mit User Stories umgehen würde. Das Sprint Backlog wird abgearbeitet, bis das erste potenziell lieferfähige Produktinkrement fertig ist (das wird vermutlich gerade einmal den Basic Flow eines ersten Use Case umfassen) – und dann geht es mit der Planung für den nächsten Sprint weiter.

In kleineren Projekten kann das Entwicklerteam Ermittlung, Beschreibung und das Slicing von Use Cases und damit die Fortschreibung des Product Backlog selbst übernehmen. Jacobson empfiehlt Scrum-Teams, 5 bis 10 Prozent ihrer Zeit in die Pflege des Backlogs zu investieren. Für große Vorhaben bietet sich ein arbeitsteiliges, parallelisiertes Vorgehen an: Die Entwicklung und das Slicing von Use Cases sind typische Aufgaben des Requirements Engineering. Sie können parallel zur Entwicklung nach Scrum ablaufen, um das Product Backlog kontinuierlich „aufzufüllen“.

Use Cases eignen sich gut zur Release-Planung, Use Case Slices gut zur Planung kleinerer Inkremente innerhalb eines kompletten Releases. Das Konzept Use Case 2.0 hilft somit, die Granularität der Entwicklung zu verfeinern. Jedes Inkrement baut auf dem vorhergehenden auf und bringt entweder mehr Funktionen oder verbessert die Qualität vorheriger Versionen.

Plädoyer für Use Cases

Sogar einer der Urheber des agilen Manifests, Alistair Cockburn, benennt drei „echte, schmerzhafte und teure Probleme“ [6], die die ausschließliche Verwendung von User Stories statt Use Cases in agilen Projekten bringt:

  • User Stories bieten den Entwicklern keinen Kontext.
  • Sie geben dem Projektteam keine Hinweise auf den Grad der Fertigstellung.
  • User Stories stellen keinen ausreichenden Mechanismus bereit, um vorausschauend die Schwierigkeiten von noch nicht getaner Arbeit zu ermitteln.

Statt also User Stories als Liste in einem Backlog zu sammeln, geben einem Use Case Slices durch die übergeordnete Use-Case-Ebene und eventuelle Use-Case-Diagramme der UML einen Gesamtüberblick über das System sowie über die Abhängigkeiten und Zusammenhänge der Anforderungen. Diese übergeordneten Instanzen ermöglichen eine bessere Nachvollziehbarkeit und Strukturierung der Anforderungen, noch bevor die eigentliche Entwicklung begonnen hat. Im Projekt helfen Use Cases dabei, sich einen Überblick über schon fertige Systemteile zu verschaffen.

Oft wird die für die Stakeholder mangelnde Lesbarkeit von Use Cases angeprangert. Man sollte generell nie Stakeholder mit der Dokumentation von Use Cases und Use-Case-Diagrammen allein lassen. Es reicht also nicht, nur Dokumente zu generieren, sie dem Stakeholder zu schicken und auf ein Feedback zu hoffen. Das gilt auch für Use Case 2.0. Stattdessen sollten Teams miteinander reden – das Prinzip der Konversation, also das zweite C der User Stories, ist auch hier sinnvoll.

Das Use-Case-2.0-Konzept eignet sich sowohl für agile Entwicklung als auch für das klassische Wasserfallmodell, weil es skalierbar ist. Kleine Teams, die eng zusammenarbeiten, können ihre Use-Case-Beschreibungen auf das Notwendigste beschränken. Große, verteilte Teams können aufwendige Beschreibungen und Dokumente erstellen. Wie detailliert die Anforderungen an das zu entwickelnde System dokumentiert werden, hängt also vom Team ab.

Fazit

Use Cases sind nicht ohne Grund so beliebt: Für viele Unternehmen bilden sie das Mittel der Wahl für die Stakeholder-Kommunikation. Sie helfen dabei zu verstehen, wie ein System dazu beiträgt, die vom User angestrebten Ziele zu erreichen und die gewünschten Ergebnisse zu erzeugen. Der noch wenig bekannte Mehrwert von Use Case 2.0 liegt in der Integration etablierter Techniken des Requirements Engineering in eine agile Vorgehensweise. Damit bieten Use Cases auch in agilen Projekten viele Vorteile.

Ursula Meseberg

Literatur

  1. Ivar Jacobson: Object Oriented Development in an Industrial Environment, OOPSLA – Proceedings, October 4-8, 1987, ACM 0-89791-247-0/87/0010-0183
  2. HK Business Solutions, Fraunhofer IESE: Ergebnisbericht „Use Cases in der Praxis“, 2013
  3. SwissQ Consulting in Kooperation mit der Universität St. Gallen: Requirements Trends & Benchmarks Schweiz, 2013
  4. Ron Jeffries; Essential XP: Card, Conversation, Confirmation (30.08.2001)
  5. Ivar Jacobson, Ian Spence, Kurt Bittner; Use Case 2.0 (E-Book), Ivar Jacobsen International 2011
  6. Alistair Cockburn; Why I still use use cases (01.09.2008)

 

Über 

Keine Kommentare

Hinterlassen Sie eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.