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 |
|
| 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 |
|
| 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:
- Agile Requirements Engineering - CPRE RE@Agile Primer
- User Stories definieren & schneiden
- Certified Scrum Product Owner
- Professional Scrum Product Owner
- Product Owner Expert Skills
- SAFe® 4.0 Product Manager/Product Owner with PMPO Certification (SPMPO)
Oder beispielsweise am Ideation Workshop an der Agile Leadership Day Konferenz (https://agileleadershipday.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/