User Stories für (Produkt‑)Konfiguratoren

Von nanologika | 22. Januar 2026 | Kommentare deaktiviert für User Stories für (Produkt‑)Konfiguratoren
« Back to Glossary Index

User Stories für Konfiguratoren beschreiben aus Sicht einer konkreten Rolle (z. B. Käufer:in, Vertriebsmitarbeiter:in, Admin) den gewünschten Nutzen eines Produkt‑ oder CPQ‑Konfigurators (Configure‑Price‑Quote), einschließlich der relevanten Geschäftsregeln (Kompatibilitäten, Abhängigkeiten, Preise, Verfügbarkeiten) und der erwarteten Qualität (z. B. Performance, Barrierefreiheit, Genauigkeit).

Zweck & Nutzen

  • Kundennutzen fokussieren: Klarer Problem‑/Nutzenbezug für jede Interaktion im Konfigurator.
  • Fehler und Rework reduzieren: Regeln, Constraints und Randfälle frühzeitig festhalten.
  • Lieferfähigkeit sichern: Definition of Ready/Done & Akzeptanzkriterien machen die Story testbar.
  • Alignment herstellen: Vertrieb, Produktmanagement, Entwicklung, Design, Recht/Compliance auf ein gemeinsames Ergebnis ausrichten.

Grundstruktur einer User Story

Als <Rolle> möchte ich <Ziel/Handlung> um <Nutzen/Wert> zu erreichen>.

Beispiel

Als Kundin möchte ich nur kompatible Komponenten auswählen können, um Fehlkonfigurationen zu vermeiden und sofort eine valide Preis‑ und Lieferauskunft zu erhalten.

INVEST‑Kriterien für gute Stories:

  • Independent, Negotiable, Valuable, Estimable, Small, Testable.

Besondere Aspekte bei Konfiguratoren

  • Regellogik & Constraints: Kompatibilität, Pflicht-/Ausschlussregeln, Abhängigkeiten, Varianten/BOM.
  • Preisfindung & Steuern: Echtzeitpreis, Rabatte, Bündel, regionale Steuerlogik.
  • Verfügbarkeit & Lieferzeit: Lagerbestand, Fertigungszeiten, regionale Lieferfähigkeit.
  • Guided Selling: Vorschläge, Auto‑Vervollständigen, empfohlene Konfigurationen, Upsell/Cross‑Sell.
  • Validierung & Erklärbarkeit: Sofortige Rückmeldungen, verständliche Fehlermeldungen, „Warum nicht?“‑Hinweise.
  • Performance & Skalierung: Reaktionszeit trotz kombinatorischer Explosion, Caching.
  • Visualisierung & Vorschau: 2D/3D‑Render, Variantenvergleich, Vorher/Nachher.
  • Persistenz & Teilen: Konfiguration speichern, wieder aufnehmen, teilen (Link/Code).
  • Omnichannel: Konsistente Erfahrung in Web, App, POS, Vertriebstools.
  • A11y & i18n: Barrierefreiheit (WCAG), Lokalisierung, Einheiten/Normen.
  • Compliance & Datenschutz: DSGVO, Produktnormen, rechtlich korrekte Angebotsdokumente.
  • Nachvollziehbarkeit: Änderungsverlauf, Konfigurations‑Versionsstand, Regel‑Versionierung.
  • Offline‑Fähigkeit (B2B/Field Sales): Lokales Caching zentraler Regeln/Preise (mit Sync).

Typische Rollen (Personas)

  • Kund:in / Käufer:in (B2C/B2B Self‑Service)
  • Vertriebsmitarbeiter:in / Partner (CPQ/Angebotserstellung)
  • Admin / Produktmanager:in (Regelpflege, Katalog, Preise, Bundles)
  • Service/Support (Fehleranalyse, Rekonstruktion einer Konfiguration)
  • Compliance/Legal (Normen, Kennzeichnungen, Dokumentationspflichten)

Beispiele für User Stories inkl. Akzeptanzkriterien

1) Käufer:in – Kompatible Auswahl

Story:
Als Käufer:in möchte ich nur kompatible Optionen sehen, damit ich keine ungültige Kombination erstellen kann.

Akzeptanzkriterien (Gherkin‑Stil)

  • Gegeben ich habe Basisprodukt X gewählt, wenn ich eine nicht kompatible Option auswähle, dann erhalte ich eine verständliche Erklärung und die Auswahl wird verhindert.
  • Gegeben kompatible Alternativen existieren, wenn eine Option blockiert ist, dann werden passende Alternativen sichtbar hervorgehoben.
  • Gegeben ich ändere eine frühere Auswahl, wenn dadurch Konflikte entstehen, dann bietet das System automatische Korrekturvorschläge an.

2) Vertrieb – Preis & Lieferzeit in Echtzeit

Story:
Als Vertriebsmitarbeiter:in möchte ich während der Konfiguration sofort einen gesamten Listenpreis mit Rabatten und eine Lieferzeit sehen, um Kund:innen schnell qualifizieren zu können.

Akzeptanzkriterien

  • Gegeben eine vollständige valide Konfiguration, wenn ich die Kundensegmenteingabe (z. B. Vertragstyp) ändere, dann aktualisieren sich Preis/Rabatt in ≤ 300 ms.
  • Gegeben bestimmte Komponenten sind nicht verfügbar, wenn ich sie anwähle, dann zeigt das System alternative Liefertermine oder Ersatzteile an.
  • Gegeben Steuerregion = DE, wenn ich einen Preis exportiere, dann ist die Mehrwertsteuer korrekt ausgewiesen.

3) Admin – Regelpflege & Versionierung

Story:
Als Admin möchte ich Produktregeln ohne Deployment anpassen können, damit Marktänderungen (z. B. neue Bundles) tagesaktuell live gehen.

Akzeptanzkriterien

  • Gegeben eine neue Regelversion, wenn ich sie aktiviere, dann gilt sie nur für neue Konfigurationen; bestehende behalten die alte Regelversion.
  • Gegeben eine inkonsistente Regel, wenn ich speichere, dann erhalte ich eine Validierungsfehlermeldung mit Fundstellen.
  • Gegeben Rollbackbedarf, wenn ich Version N‑1 reaktiviere, dann werden alle abhängigen Regeln konsistent zurückgesetzt.

4) Käufer:in – Speichern & Teilen

Story:
Als Käufer:in möchte ich meine Konfiguration als Link teilen können, damit Kolleg:innen sie prüfen und weiterbearbeiten können.

Akzeptanzkriterien

  • Gegeben ich bin nicht angemeldet, wenn ich „Teilen“ nutze, dann erhält der Link eine Ablauffrist und enthält keine personenbezogenen Daten.
  • Gegeben eine veraltete Regelversion, wenn der Link geöffnet wird, dann weist das System auf Unterschiede hin und bietet ein Upgrade auf die aktuelle Regelbasis an (mit Vergleich).

Nichtfunktionale Anforderungen (NFA) – typische Ergänzungen

  • Performance: UI‑Antwortzeiten ≤ 300 ms, Gesamtpreis‑Recalc ≤ 500 ms bei 95. Perzentil.
  • Skalierung: ≥ X gleichzeitige Nutzer:innen, Hochlastszenarien (Kampagnen).
  • Zuverlässigkeit: 99,9 % Verfügbarkeit, Graceful Degradation bei Preisdiensten.
  • A11y: WCAG 2.2 AA (Tastatur, Screenreader, Kontraste).
  • Sicherheit & Datenschutz: DSGVO‑konforme Speicherung, minimale Datenerhebung, Anonymisierung geteilten Links.
  • Nachweisbarkeit: Audit‑Trail für Regel‑/Preisänderungen und Angebotsdokumente.
  • Internationalisierung: Sprache, Währung, Maßeinheiten, rechtliche Hinweise pro Markt.

Hinweis: NFA gehören oft als eigene Story oder als Quality Gate in jede Konfigurator‑Story.

Definition of Ready (DoR) – für Konfigurator‑Stories

  • Zielbild/Mockup vorhanden (inkl. Validierungs‑/Fehlerzustände).
  • Relevante Regeln/Constraints identifiziert (Quelle, Eigentümer:in, Priorität).
  • Datenquellen geklärt (PIM/ERP/Preisservice/Bestand) + Fallbacks.
  • Akzeptanzkriterien inkl. Negativfällen und Messgrößen definieren.
  • Abhängigkeiten (Rendering, Rule Engine, API‑Limits) adressiert.

Definition of Done (DoD)

  • Alle Akzeptanzkriterien grün (inkl. Konflikt‑/Fehlerpfade).
  • Accessibility‑Check, Cross‑Browser/Device‑Tests, i18n verifiziert.
  • Telemetrie (z. B. Time‑to‑Configure, Abbruchrate) implementiert.
  • Dokumentation & Changelog (Regeln, Preise, Versionen) aktualisiert.

Metriken & KPIs

  • Conversion Rate, Abbruchrate, Time‑to‑Configure.
  • Erstangebots‑Trefferquote, Quote‑Cycle‑Time (B2B).
  • Fehlkonfigurationsrate, Regel‑Konfliktinzidenz.
  • Umsatz/Marge pro Konfiguration, Upsell/Attach Rate.

Best Practices

  • Slice by Value: Kleine, nutzbare End‑zu‑End‑Inkremente (z. B. ein kompatibles Bundle + Preis + Lieferzeit).
  • Regeln als Daten: Trennung von Code, Versionierung, validierbar, zur Laufzeit ladbar.
  • Erklärbare Regeln: Nutzer:innen sehen warum etwas nicht kompatibel ist und wie es lösbar ist.
  • Negativpfade testen: „Keine gültige Kombination“, Timeout des Preisdienstes, Offline‑Fälle.
  • Barrierefreiheit & i18n nicht nachträglich, sondern von Beginn an.
  • Telemetrie früh einbauen: Messen, wo Nutzer:innen scheitern.
  • Security & DSGVO by design: Minimaldaten, Zweckbindung, Löschkonzept.

Anti‑Patterns

  • Riesige „Sammel-Story“ mit > 20 Regeln → untestbar, schwer lieferbar.
  • Akzeptanzkriterien ohne Datenbezug („Preis korrekt“) → unprüfbar.
  • Versteckte Abhängigkeiten zu externen Diensten ohne Fallback → fragil.
  • Regeländerungen nur via Code‑Deploy → lange Time‑to‑Market.

Vorlage (Template)

Story
Als <Rolle> möchte ich <Fähigkeit/Ziel>, um <Nutzen/Wert> zu erreichen.

Kontext & Annahmen

  • Produktbereich/Variante: …
  • Relevante Regeln/Constraints (Quelle/Eigentümer:in/Version): …
  • Datenquellen & Fallbacks: …

Akzeptanzkriterien (Beispiele im Gherkin‑Stil)

  • Gegeben <Ausgangszustand>, wenn <Aktion>, dann <Ergebnis>.
  • Gegeben …, wenn …, dann … (Negativfall).
  • Performance: <Schwellen> | A11y: <WCAG‑Aspekte> | i18n: <Sprachen/Währungen>.

Telemetry/KPIs

  • Metrik 1: … | Metrik 2: …

Test‑/Datenhinweise

  • Beispielkonfigurationen, Grenzfälle, Mockdaten.

Siehe auch

  • Epics & Use Cases, Job Stories, Gherkin/BDD
  • CPQ, PIM/ERP, BOM/Variantenmanagement
  • Constraint‑/Regel‑Engine, Guided Selling, WCAG, DSGVO
« Back to Glossary Index