Warum User Stories innovativer sind als Use Cases


Björn Schuster, Senior Consultant

Wer kennt sie nicht: die Use Cases. Heiss geliebt oder zutiefst verhasst. An vielen Orten überleben sie auch – oder gerade – heute. Viele verwechseln sie mit User Stories (bekannt aus Extreme Programming, Scrum, Kanban oder anderen agilen Frameworks).

Oft wird die Diskussion geführt ob User Stories die Use Cases abgelöst haben oder ablösen sollten. Ich habe eine konkrete Meinung: User Stories sind innovativer als Use Cases.

Um zu verstehen wie ich zu diesem Schluss komme, sollten wir uns zuerst die Use Cases etwas genauer anschauen.

Use Cases

Ein „Standard Use Case“ besteht aus verschiedenen Teilen (und ich meine hier nicht das Use Case Diagramm; das ist als Übersicht der Use Cases sicher wichtig, aber für einen Use Case nicht zwingend erforderlich [1]):

  • Akteur
  • Absicht des Akteurs
  • Interaktionen des Akteurs mit dem zu entwickelnden System
    • Standardablauf
    • Alternative Abläufe
    • Fehlerfälle
  • Vorbedingungen
  • Nachbedingungen
  • Involvierte Geschäftsobjekte und evtl. Geschäftsfunktionen

Soweit so gut. In der Praxis habe ich leider sehr oft erlebt, dass der Akteur selber irgendwie beschrieben wird aber die Absicht des Akteurs entweder mit einem „Standardsatz“ erledigt oder gleich ganz leer gelassen wird. Es ist ja auch viel spannender, befriedigender und in den meisten Firmen angesehener eine Lösung zu liefern und zu beschreiben.

Beispiel 1 – Standard Geldautomat

Schauen wir uns dieses Schema anhand des allseits beliebten Beispiels „Geldabheben am Geldautomaten“ an (Happy-Path):

Akteure Kunde der Bank (Primärer Akteur)
Bank-System (Sekundärer Akteur)
Absicht Kunde der Bank möchte Bargeldbezug unabhängig von Schalteröffnungszeiten und Schalterlokation tätigen
Vorbedingungen Kunde der Bank hat Bankkarte (z.B. Maestro)
Geldautomat hat Strom, ist eingeschaltet und zeigt den Begrüssungsbildschirm an.
Standardablauf
  1. System zeigt „Bitte Karte einführen“ im Bildschirm an
  2. Kunde führt Bankkarte in den Kartenleser des Systems ein
  3. System prüft Karte auf Lesbarkeit und Korrektheit
  4. System fragt Kunde nach seinem PIN
  5. Kunde gibt PIN über Tastatur ein
  6. System verifiziert PIN anhand Informationen auf der Bankkarte
  7. System zeigt die verfügbaren Dienstleistungen an
  8. Kunde wählt die Dienstleistung „Geldabheben“ aus
  9. Das System fragt nach dem gewünschten Betrag
  10. Der Kunde gibt den gewünschten Betrag ein
  11. Das System überprüft via dem Bank System ob der gewünschte Betrag auf dem Kundenkonto verfügbar ist
  12. Das System prüft ob der gewünschte Betrag im Geldautomaten verfügbar ist
  13. Das System teilt dem Kunden mit, dass das Geld ausgezahlt wird
  14. Das System gibt die Bankkarte an den Kunden heraus
  15. Das System zahlt den gewünschten Betrag aus
  16. Das System stellt eine Quittung aus
Nachbedingung Standardablauf Der Kunde hat den gewünschten Bargeldbetrag erhalten
Der ausbezahlte Bargeldbetrag ist vom Konto abgebucht
Der Kunde hat seine Bankkarte wieder
Das System hat einen entsprechenden Log-Eintrag geschrieben
Das System hat seinen internen Zähler über verfügbare Anzahl an Geldscheinen aktualisiert
Geschäftsobjekte Konto
Bankkarte
Kontotransaktion
Kunde

Was ist nun das Problem an diesem Use Case?

Nichts – wenn man einen herkömmlichen, normalen, seit Jahren existierenden Geldautomaten erhalten möchte.

Beispiel 2 – Erweiterter Geldautomat

Was nun, wenn wir uns anschauen, wie Geldautomaten auch heute schon teilweise funktionieren (Happy-Path):

Akteure Kunde der Bank (Primärer Akteur)
Bank-System (Sekundärer Akteur)
Absicht Bargeldbezug unabhängig von Schalteröffnungszeiten und Schalterlokation
Vorbedingungen Kunde hat QR-Code gelöst
Geldautomat hat Strom, ist eingeschaltet und zeigt den Begrüssungsbildschirm an.
Standardablauf
  1. System prüft periodisch alle Sekunde ob ein QR-Code vor die Kamera gehalten wird
  2. Kunde hält QR-Code vor die Kamera des Systems
  3. System erkennt QR-Code
  4. System prüft QR-Code auf Lesbarkeit und Korrektheit
  5. System zeigt Kunden dass, es einen QR-Code gefunden hat
  6. System prüft Gültigkeit des QR-Codes (wurde noch nicht verwendet)
  7. Das System überprüft via dem Bank System ob der gewünschte Betrag auf dem Kundenkonto verfügbar ist
  8. Das System prüft ob der gewünschte Betrag im Geldautomaten verfügbar ist
  9. Das System teilt dem Kunden mit, dass das Geld ausgezahlt wird
  10. Das System gibt die Bankkarte an den Kunden heraus
  11. Das System zahlt den gewünschten Betrag aus
  12. Das System stellt eine Quittung aus
  13. Das System teilt dem Kunden mit, dass der QR-Code nun nicht weiter gültig ist
Nachbedingung Standardablauf Der Kunde hat den gewünschten Bargeldbetrag erhalten
Der ausbezahlte Bargeldbetrag ist vom Konto abgebucht
Der verwendete QR-Code wurde als benutzt im System markiert und kann nicht erneut verwendet werden
Das System hat einen entsprechenden Log-Eintrag geschrieben
Das System hat seinen internen Zähler über verfügbare Anzahl an Geldscheinen aktualisiert
Geschäftsobjekte Konto
QR-Code
Kontotransaktion
Kunde

Dies ist nun ein gänzlich anderer Use Case, richtig? Richtig!

Aber ist es auch ein anderes Problem das gelöst wird? Eher nicht. Es handelt sich immer noch um das Problem, dass ein Bankkunde Bargeld benötigt und dies auch ausserhalb der Schalteröffnungszeiten beziehen möchte.

Gehen wir noch einen Schritt weiter. Selbst der zugrundeliegende Geschäftsprozess dazu würde recht wahrscheinlich vorschreiben, dass sich der Kunde authentifiziert (Karte und PIN). Doch dies ist für das gewählte Beispiel 2 gar nicht erforderlich. Es ergeben sich sogar weitere Einsatzgebiete mit dem zweiten Beispiel: Eltern können ihren Kindern für den Notfall einen der QR-Codes auf das Handy speichern und die Kinder können jederzeit Bargeld beziehen. Ein weiterer Fall ist, dass jemandem das Portemonnaie gestohlen wurde. Dieser Person kann nun ein QR-Code Übermittelt werden und schon kommt diese Person wieder zu Bargeld.

Wir könnten sogar noch einen Schritt weitergehen und auf Lösungen kommen, die gänzlich auf Hardware der Bank verzichten und z.B. jeden Laden mit Kartenterminal oder vielleicht sogar jede Privatperson zu einer Bargeldquelle für unsere Kunden machen.

User Stories

Um die innovative und kreative Freiheit des Entwicklungsteams nicht einzuschränken werden User Stories meist durch folgende Schablone beschrieben:

Als Rolle/Akteur möchte ich ein Ziel erreichen/etwas tun können damit ich einen Mehrwert habe.

Dadurch rückt der Fokus zuerst auf das grundlegende Verständnis des Problems des Kunden. Erst wenn dieses Problem verstanden wurde werden mögliche Lösungen erarbeitet.

Wichtig sind hierbei auch die Akzeptanzkriterien. Diese bilden Leitplanken bei der Lösungssuche und geben die minimal zu erfüllenden Kriterien einer Lösung vor.

Die User Story könnte beispielsweis lauten:

Als angesagter Hipster möchte ich jederzeit bequem an Bargeld herankommen, damit ich bei meinem samstäglichen Einkauf auf dem rustikalen (und leider technologisch rückständigen) Bauernmarkt meine Einkäufe bezahlen kann.

Akzeptanzkriterien:

  • Es muss kein grosser Umweg gemacht werden für den Bargeldbezug (der Hipster von heute ist mit dem Velo unterwegs – stromlos versteht sich)
  • Der Bargeldbezug muss unseren als Bank wichtigen Sicherheitsrichtlinien entsprechen
  • Das zu beziehende Bargeld muss auf dem Konto verfügbar sein und entsprechend direkt abgebucht oder zumindest reserviert werden

Dabei kann auch mittels anderer kreativer Mittel wie z.B. Design Thinking oder Ideation auf die fachliche Lösung gekommen werden.

Fazit

Wir sehen also: dadurch, dass der Use Case die Lösung beschreibt anstatt das Problem, wird der Freiheitsgrad des implementierenden Teams erheblich eingeschränkt und es muss ein sehr grosses Vertrauen darin bestehen, dass die Person, die den Use Cases erfasst hat, nicht nur das zugrundeliegende Kundenbedürfnis verstanden hat, sondern auch die aktuell perfekteste und innovativste Lösung gefunden und beschrieben hat; dies alles unter Berücksichtigung der aktuell möglichen technischen Aspekte und den fachlichen sowie Kunden-Bedürfnissen.

Wie gross ist die Wahrscheinlichkeit dafür?

Wenn ich mir die Ergebnisse aus der Vergangenheit und die verschiedenen CHAOS-Reports [2] anschaue, komme ich zu dem Schluss, dass der Use Case Ansatz vielleicht nicht ganz so erfolgreich war.

Zusammengefasst: Use Cases beschreiben eine Lösung, User Stories ein Problem, die Lösung wird durch das Team in Zusammenarbeit mit dem Product Owner erarbeitet. Dadurch können wirklich neue, innovative Lösungen entstehen. Diese müssen dann nur noch „ausprobiert“ werden und aus dem gelernten die Lösung verbessert werden; ein echter „Research and Development“ (R&D) Ansatz eben.

Zur Dokumentation der erarbeiteten Lösung können allerdings Use Cases verwendet werden. Hierbei eigenen sich jedoch modellbasierte Ansätze besser als dokumentenbasierte.

Wie man zu guten User Stories kommt

Mehr zu guten User Stories und wie man zu diesen kommt – und alle weiteren Tätigkeiten rund ums agile Requirements Engineering – erfahren Sie in einem unserer Kurse:

Oder beispielsweise am Ideation Workshop an der Upfront Thinking Konferenz (http://www.upfrontthinking.ch).

Literatur

[1] Cockburn, Alistair, Writing Effective Use Cases, Addison-Wesley Professional; 1 edition (October 15, 2000)
[2] Standish Group, CHAOS Report, http://www.standishgroup.com/

5 thoughts on “Warum User Stories innovativer sind als Use Cases”


  • michael.rechberger@six-group.com' Michael sagt:

    User Stories sind unheimlich stark bei Systemen, welche mit konkreten Menschen als Akteuren interagieren. Aber wie sieht das deiner Meinung nach aus bei Systemen, welche ausschliesslich mit anderen Systemen agieren, z.B. via API oder durch das Generieren von Files oder anderen Daten (z.B. in einer DB)? Dort stösst man mit User Stories oftmals an Grenzen und die guten alten Use Cases gewinnen an Attraktivität. Oder wie sehen das andere?

    • Hallo Michael, danke für deinen Kommentar.
      Ich kenne solche Überlegungen sehr gut aus der Praxis. Oft ist dann das Problem, dass das System zu klein gefasst ist; Die API, Files oder Daten werden von irgendeinem Akteur benötigt (vielleicht nicht direkt die von diesem System generierten). In der Praxis, gerade in grösseren Firmen sind die Aufgaben die die IT-Systeme erfüllen sollen über viele verschiedenen Applikationen verteilt. Da wird es dann wirklich schwierig den Use Case oder auch schon alleine den Akteur dahinter zu sehen; das ist dann aber aus meiner Sicht ein Problem der System-/Applikationslandschaft. Brauche ich dann wirklich für jede Teilapplikation einen eigenen Use Case (oder eben User Story)?
      Ein weiterer Punkt ist aus meiner Sicht auch, dass Use Cases – so wie ich sie verstehe – eine Interaktion eines Akteurs mit dem System beschreiben um ein Ziel zu erreichen. Wenn es sich bei der Interaktion nur um „Anfrage senden“ und „Antwort erhalten“ handelt (und das meistens recht technisch) stellt sich mir schon die Frage, ob ein Use Case wirklich das richtige Mittel ist.
      Es gibt aber tatsächlich Systeme, die eine Dienstleistung für andere Firmen anbieten (z.B. Börse), da ist es dann vielleicht wirklich schwierig den gesamten Prozess der Leistungserbringung für einen (menschlichen) Akteur beschreiben zu können. In diesem Fall wurden (wie eigentlich auch bei grossen Applikationslandschaften) die gesamte Dienstleistung irgendwo aufgetrennt (und ein Teil ausgelagert). Die Use Cases die hierbei auftreten sind dann meist wieder recht technisch orientiert und beschreiben eben die eine Lösung. Genau das Problem, auf das der Artikel eigentlich hinweisen wollte: Use Cases beschreiben eher eine Lösung als das Problem eines Akteurs – also das „Warum“ es das System oder diese Systemfunktionalität benötigt.

      • michael.rechberger@six-group.com' Michael sagt:

        Hoi Bjorn. Vielen Dank für dein Feedback. Du triffst den Nagel auf den Kopf. Die Applikationen in meinem Kontext bereiten Finanzinformationen nach bestimmten (teilweise sehr komplexen) Regeln auf und liefern diese über standardisierte Schnittstellen an unsere Kunden (Finanzinstitute). Genau haben wir die Erfahrung gemacht, dass wir mit Stories an den Anschlag kommen. Gibt es hier aus deiner Erfahrung (oder anderer) Ansätze, die Abhilfe schaffen können?

        • Hallo Michael,
          Ich habe in einem ähnlichen Kontext beispielsweise Entscheidungsbäume verwendet um Mappingregeln zu dokumentieren. Aus diesen Bäumen wurde dann immer ein oder mehrere Äste via einer „User Story“ umgesetzt (in dem Fall eben nicht nach dem Standard Format).
          Auch wäre evtl. eine Einteilung nach Geschäftsobjekten möglich und ein entsprechendes Mapping auf die Ausgabestruktur.

Schreibe einen Kommentar