Global IT Consultancy Xebia and Digital Specialist SwissQ Join Forces. Read full press release >

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 – strohmlos 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 Worksop an der Upfrontthinking Konferenz (https://www.upfrontthinking.ch).

Literatur

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

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


Leave a Reply