In vielen Diskussionen höre ich die Aussage:

„Use Cases und User Stories können dasselbe enthalten.“

Auf den ersten Blick klingt das plausibel.
Beide beschreiben Anforderungen. Beide beschreiben Verhalten. Beide werden in der Softwareentwicklung eingesetzt.

Aber was passiert, wenn wir ein echtes, nicht triviales Beispiel nehmen und versuchen, es in beiden Formen darzustellen?

Statt theoretisch zu diskutieren, schauen wir uns ein konkretes Beispiel an.

Ein realer Use Case

Der folgende Use Case beschreibt das Anlegen eines Auftrags.
Er ist leicht anonymisiert, aber fachlich vollständig.

# UC-002: Auftrag anlegen

**Primärer Akteur:** Sachbearbeiter  
**Sekundäre Akteure:** Buchhaltung, Qualitätssicherung  
**Ziel:** Neuen Auftrag anlegen  
**Status:** Dokumentiert  

## Vorbedingungen

- Der Benutzer ist eingeloggt  
- Der Benutzer hat die Berechtigung, Aufträge zu erstellen  
- Der Benutzer hat die Detailansicht eines Kunden geöffnet  

## Nachbedingungen

### Erfolgsfall

- Der Auftrag wird erfolgreich gespeichert und erhält eine Auftragsnummer  
- Der erstellte Auftrag wird angezeigt  

### Fehlerfall

- Es wird eine Fehlermeldung angezeigt, die den Fehler beschreibt  
- Es wird kein Auftrag erstellt  

## Hauptablauf

1. Der Benutzer klickt auf **Auftrag erstellen**  
2. Das System validiert den Kunden (siehe GR-001)  
3. Das System validiert den Standort (siehe GR-002)  
4. Das System validiert die Kanal-/Erfassungsart-Kombination (siehe GR-003)  
5. Das System erstellt den Auftrag mit Standardwerten (siehe GR-004)  
6. Das System validiert das Wunschlieferdatum (siehe GR-005)  
7. Das System setzt Lieferdatum und Tour anhand des Lieferkalenders  
8. Das System setzt die Lieferadresse (Standardadresse des Kunden)  
9. Das System setzt den Status auf **NEU**  
10. Das System speichert den Auftrag und sperrt ihn für den aktuellen Benutzer  
11. Das System zeigt den Auftrag an  

## Alternativabläufe

### 1a. Auftrag ohne vorgewählten Kunden erstellen

1. Der Benutzer klickt auf **Auftrag erstellen**  
2. Das System öffnet einen leeren Auftrag  
3. Der Benutzer wählt einen Kunden aus  
4. Weiter mit Schritt 2 des Hauptablaufs  

### 2a. Kundenvalidierung schlägt fehl

1. Das System zeigt eine Fehlermeldung an (z.B. „Kunde ist inaktiv“)  
2. Der Auftrag wird nicht erstellt  

### 3a. Standortvalidierung schlägt fehl

1. Das System zeigt eine Fehlermeldung an (z.B. „Standort ist gesperrt“)  
2. Der Auftrag wird nicht erstellt  

### 6a. Lieferdatum ungültig (elektronische Erfassung)

1. Das System erstellt den Auftrag trotzdem, markiert ihn aber als **BLOCKIERT**  
2. Der Auftrag muss manuell freigegeben werden  

### 6b. Abholauftrag

1. Das System überspringt die Lieferdatum-Validierung  
2. Die Tour wird auf **ABHOLUNG** gesetzt  
3. Weiter mit Schritt 8  

### 6c. Express-/Sonderauftrag

1. Das System prüft nur, ob das Datum nicht in der Vergangenheit liegt  
2. Die Tour wird auf **EXPRESS** gesetzt  
3. Weiter mit Schritt 8  

### 6d. Standort geändert

1. Das System prüft, ob der Kunde eine aktive Tourenplanung am neuen Standort hat  
2. Falls ja: normale Validierung  
3. Falls nein:
   - keine Validierung  
   - Tour wird auf **EXPRESS** gesetzt  

## Geschäftsregeln (Auszug)

### GR-001: Kundenvalidierung

- Kunde muss aktiv sein  
- Keine Sperren auf Kunde, Organisation oder Gruppe  

### GR-002: Standortvalidierung

- Standort darf nicht gesperrt sein  
- Lieferdatum muss nach Aktivierungsdatum liegen  

### GR-003: Kanal-/Erfassungsart-Validierung

- Manche Erfassungsarten erfordern einen Kanal  
- Manche verbieten einen Kanal  
- Sonst ist der Kanal optional  

### GR-004: Standardwerte

- Status = NEU  
- Auftragstyp = STANDARD  
- Erfassungsart = Telefon  
- Kanal = keiner  
- Lieferdatum = nächstmöglich  

### GR-005: Lieferdatum-Validierung

- Standard: Datum muss im Lieferkalender sein  
- Express: Datum darf nicht in der Vergangenheit liegen  
- Ungültig (elektronisch): Auftrag wird blockiert

Schon in dieser Form sieht man:

  • ein klarer Ablauf
  • explizite Alternativen
  • zentrale Regeln
  • vollständige Transparenz

Alles ist an einem Ort sichtbar.

Jetzt das gleiche mit User Stories

Wir starten mit einem Epic.

Als Sachbearbeiter
möchte ich Aufträge erfassen
damit Kundenbestellungen abgewickelt werden können

Dann leiten wir User Stories ab.

Als Sachbearbeiter
möchte ich einen Auftrag für einen Kunden erstellen
damit ich eine Bestellung erfassen kann

# Akzeptanzkriterien
- Kunde muss aktiv sein
- Standort muss gültig sein
- Kanal und Erfassungsart müssen konsistent sein
- Auftrag wird mit Standardwerten erstellt
- Lieferdatum wird validiert
- Auftrag wird gespeichert und angezeigt
Als Sachbearbeiter
möchte ich eine Fehlermeldung sehen
wenn der Kunde ungültig ist
damit ich keine falschen Aufträge erfasse

Als Sachbearbeiter
möchte ich Aufträge mit ungültigem Lieferdatum blockieren
damit sie nicht falsch verarbeitet werden

Als Sachbearbeiter
möchte ich Abholaufträge erstellen
damit Kunden Ware selbst abholen können

Als Sachbearbeiter
möchte ich, dass Kanal und Erfassungsart validiert werden
damit die Herkunft eines Auftrags korrekt ist

Um den gesamten fachlichen Umfang abzudecken, brauchen wir:

  • viele User Stories
  • viele Akzeptanzkriterien
  • implizite Abhängigkeiten zwischen ihnen

Was hat sich verändert?

Beide Varianten beschreiben denselben fachlichen Inhalt.

Aber die Struktur ist komplett unterschiedlich.

Bei User Stories:

  • Verhalten ist auf viele Einheiten verteilt
  • Abläufe sind implizit
  • Alternativen sind verstreut
  • Regeln sind in Kriterien versteckt oder dupliziert

Um das System zu verstehen, muss man sich den Ablauf im Kopf zusammensetzen.

Beim Use Case:

  • Verhalten ist explizit beschrieben
  • der Ablauf ist durchgängig sichtbar
  • Alternativen sind klar strukturiert
  • Regeln sind zentral definiert

Können User Stories dasselbe enthalten?

Ja.

Aber nur, wenn man:

  • viele Stories schreibt
  • sehr viele Akzeptanzkriterien ergänzt
  • diszipliniert arbeitet
  • ständig synchronisiert

In der Praxis führt das zu:

  • Fragmentierung
  • Inkonsistenzen
  • geringerer Verständlichkeit

Die Information ist noch da.
Aber sie ist nicht mehr als Ganzes sichtbar.

Warum ist das wichtig?

Bei einfachen Features ist der Unterschied klein.

Aber in echten Business-Anwendungen:

  • greifen Regeln ineinander
  • hängen Abläufe voneinander ab
  • sind Sonderfälle entscheidend

Dann wird Fragmentierung zum Problem:

  • Missverständnisse nehmen zu
  • Fehler entstehen
  • Entwicklung wird langsamer

Und mit AI wird das noch relevanter.

AI funktioniert am besten mit:

  • klarer Struktur
  • explizitem Verhalten
  • vollständigem Kontext

Use Cases liefern genau das.

Fazit

User Stories und Use Cases können denselben fachlichen Inhalt beschreiben.
Aber sie liefern nicht die gleiche Klarheit.

User Stories beschreiben Absicht.
Use Cases beschreiben Verhalten.

Solange Systeme einfach sind, funktioniert beides.

Sobald sie komplex werden, wird der Unterschied sichtbar.

Und wenn man versucht, einen vollständigen Use Case in User Stories zu pressen,
reduziert man die Komplexität nicht.

Man verteilt sie nur.