Digital Garden LogoDigital Garden

Wert-/Business-Value-basiertes Story Slicing — Kompendium

🪴 (potted plant) Permanent note |

Kompendium: Wert-/Business-Value-basiertes Story Slicing

Ziel: Unser Team soll Items weniger „technisch geschnitten“ planen, sondern entlang von Business Value / Outcome. Damit werden Backlog, Epics und Stories kleiner, unabhängig testbar und liefern früher sichtbar Nutzen.

Dieses Kompendium ist als Techniken-Atlas gedacht: Du nimmst eine konkrete Initiative/ein Item, folgst dem Vorgehen und erzeugst daraus bessere (wertgetriebene) Slices.

1) Was meinen wir mit „Wert“?

Wert (Business Value) zeigt sich typischerweise als verbesserter Zustand / messbare Wirkung – nicht als „wir haben X gebaut“. In der Praxis gilt:

  • Wert entsteht beim Ausliefern (spürbare Veränderung im System/Verhalten), nicht beim Sammeln von Arbeit.
  • Wert ist sichtbar/vermittelbar: Der „Buyer“ (Stakeholder/Nutzer/Organisation) entscheidet, ob es Wert ist.
  • Outcome > Output: Geschichten sind dann wertbasiert, wenn sie nachweislich Fortschritt in Richtung eines Outcomes sind.

PKMS-Impulse, die diese Haltung stützen (als Gedankengerüst, nicht als alleinige Methode):

  • „Wert-Tenets“ (verbesserter Zustand, Wert im Auge des Betrachters)
  • Value Stream / Value Delivery Fokus (Wert beim Ausliefern)
  • Roadmap-Reflexion: Roadmaps sollten eher auf Outcome als auf Output verstanden werden (sonst baut man „Commitment-Fallen“).

2) Warum „technisches Schneiden“ oft schiefgeht

Wenn wir große Themen horizontal nach technischen Schichten schneiden (z.B. „API“, „DB“, „UI“, „Tests“ als getrennte Stories), entstehen typischerweise:

  • Entkopplungen: Ein Slice bringt erst Wert, wenn mehrere andere parallel fertig sind.
  • Lange Feedback-Loops: Nutzer-/Business-Feedback kommt zu spät.
  • Unsichtbarer Wert: Management/Team sieht „Output“, aber nicht „Outcome“.
  • Abhängigkeiten: Reihenfolge wird zur Blockade statt zur Planung.

Das ist der Kernfehler: Wir schneiden „Arbeit“, nicht „Value“.

3) Splitten vs. Slicen (kleine Begriffs-Leitplanke)

Viele Teams verwechseln „splitting“ und „slicing“:

  • Splitting: ein großes Item in kleinere Teile teilen, die einzeln sinnvoll sind (oft „pizzaförmig“: jeder Teil ist für sich essbar).
  • Slicing: vertikal/through-the-stack arbeiten, sodass jeder Slice end-to-end einen dünnen, aber echten Wert liefert („vertikale Kuchen-Scheibe“).

Wenn Teams explizit von „technischen Slices“ weg wollen: Slicing (vertikal nach Value) ist in der Regel der bessere Default.

4) Das Grundprinzip für wertbasiertes Story Slicing

Eine Story ist gut geschnitten, wenn sie:

  1. einen messbaren Fortschritt in Richtung Business/Outcome liefert,
  2. selbständig testbar / lieferbar ist,
  3. genug „durch die Schichten“ geht, um am Ende beobachtbar wertbringend zu sein.

Das deckt sich mit den „Best practices“ aus den Quellen:

  • Story splits sollten nicht nach technischen Layern entstehen, sondern vertikal durch UI/Backend/DB/Test arbeiten.
  • Eine Story ist wertbasiert, wenn sie als Inkremement von Value gilt (INVEST „Valuable“).
  • Wenn eine „unsplittable“ Story eigentlich eine Task/Komponenten-Arbeit ist, braucht es meist Kombination mit anderen Value-Anteilen statt noch kleinerer technischer Zerlegung.

5) Technik-Katalog: Items anders schneiden (wertorientiert)

5.1 Value-First: Outcome/Business Impact als Startpunkt

Idee: Starte nicht bei „Feature-Teile“, sondern bei der Frage:

Welchen Business Outcome wollen wir verbessern (messbar oder zumindest beobachtbar)?

Praktisch:

  • Definiere 1 Outcome-Metrik (oder 1 klare Zielwirkung).
  • Definiere „Wer/wo spürt das Ergebnis?“ (Stakeholder/Persona).
  • Übersetze dann in „Slice-Formulierungen“: „Was kann der Nutzer nach diesem Slice konkret können/erleben?“

Warum das hilft:

  • Du erzeugst automatisch eine Cut-Linie gegen reine technische Arbeit („Was liefert das als Ergebnis?“).

5.2 Vertical Slice: Through-the-stack (End-to-end Wert)

Idee: Ein Slice muss eine nutzbare Veränderung erzeugen, nicht nur einen technischen Baustein.

Check:

  • Kann das Team am Ende eines Sprints (oder Inkrements) wirklich sagen: „Wir haben eine beobachtbare Verbesserung geliefert“?
  • Berührt der Slice dafür genug Ebenen, um den Nutzer-/Business-Outcome auszulösen?

Merksatz:

  • „Thin, end-to-end, testable“ schlägt „API first, UI later“.

5.3 Split by Value statt Split by Technical Layer

Idee: Wenn deine Story beim Zerlegen aussieht wie „UI-Layer Story“, „DB-Layer Story“ oder „API-Layer Story“, ist sie sehr oft eine Task.

Alternative:

  • Slice nach Nutzung: Persona + Workflow + (wenn relevant) relevante Business Rules.
  • Das Ergebnis muss ein „kleines Stück Nutzwert“ sein.

5.4 SPIDR (schnelles Muster für wertbasierte Zerlegung)

SPIDR ist ein besonders nützliches Vorgehen, weil es dir mehrere Achsen gibt, um wertbasierte Slices zu finden:

  • Spikes: kurz untersuchen, wenn Unsicherheit blockiert (z.B. „können wir das überhaupt so lösen?“).
  • Paths: unterschiedliche Workflow-Pfade (Happy Path vs. alternative Wege).
  • Interfaces: unterschiedliche Plattform/Interaktion/Modus (z.B. „erst Mobile Web“).
  • Data: eingeschränkter Datentyp/Umfang (z.B. „nur aktive Kunden“, „nur eine Region“).
  • Rules: Business Rules/Validierungen/Ausnahmen – erst die Kernregel, später die Randfälle.

Wichtig:

  • SPIDR ist kein „Tech-Mapping“. Es bleibt wertorientiert, solange jeder Slice echte Value-Credibility liefert (testbar/lieferbar).

5.5 INVEST-Check (Qualitätssicherung fürs „Slicable“)

Aus INVEST-Logik lässt sich ein sehr pragmatischer Qualitätscheck ableiten:

  • Valuable: Liefert messbaren/visible Nutzen oder reduziert Risiko sinnvoll?
  • Testable/Estimable: Kann man eine Definition of Done testen und halbwegs schätzen?
  • Independent/Small: Ist der Slice so klein, dass er in einem Sprint „durchlieferbar“ ist (und nicht blockiert)?

Wenn „Valuable“ oder „Testable“ scheitert:

  • entweder ist es noch keine Story, sondern Technik/Task,
  • oder du musst kombinieren (statt weiter zu zerlegen),
  • oder den Slice so ändern, dass er beobachtbaren Value produziert.

5.6 Impact Mapping (Wert-Ausrichtung + Cut-Liste)

Impact Mapping ist ein sehr starkes „Business Value Cut“-Werkzeug.

Es baut eine Kette (hierarchisch):

  • Goal (warum)
  • Actors (wer)
  • Impacts (wie verändern sich Verhalten/Ergebnisse)
  • Deliverables (was wir tun, um den Impact zu treiben)

Cut-Logik:

  • Items, die sich nicht über diese Kette begründen lassen, sind Cut-Kandidaten (oder gehören woanders hin).

Warum das für Teams gut ist:

  • Es zwingt zur Ursache-Wirkung-Argumentation,
  • und hilft, Backlog-„Technik-Default“ zu verhindern.

5.7 „MVF“/Minimum Viable Functionality (kleinstes nutzbares Wertstück)

Idee: Du suchst nicht „kleine Teilaufgaben“, sondern das kleinste Funktionsinkrement, das Value sichtbar macht.

Wenn du immer wieder Split-Resultate bekommst, die keiner alleine nutzen kann:

  • dann bist du wahrscheinlich in horizontalen Aufgaben-Splits gelandet,
  • oder du musst die Akzeptanzkriterien/Definition of Done „value-first“ formulieren.

5.8 Volatility-based Splitting (stabil vs. volatil schneiden)

Wenn ein Item viele Teile hat, die sich unterschiedlich schnell ändern:

  • trenne stabile vs. volatile Bereiche,
  • und slice so, dass das Team schnell in dem Teil lernen/liefern kann, der wirklich volatil ist.

Wertbezug:

  • Das reduziert Risiko und Change-Kosten,
  • und macht Delivery schneller (Time-to-Value).

6) Workshop-/Arbeitsflow: So schneiden wir ein Item value-basiert

Schritt 1: Item benennen (was ist „das Große“?)

  • Epic / Initiative / Story (wie ihr es gerade im Backlog habt)

Schritt 2: Business Value Card ausfüllen (5 Minuten)

  • Ziel/Outcome (messbar oder beobachtbar)
  • Stakeholder/Persona (wer profitiert)
  • Baseline (wo stehen wir heute)
  • Zielzustand (was ändert sich)
  • „Definition of Done“ in Value-Sprache (was ist danach anders)

Schritt 3: Kandidaten-Slices generieren (15 Minuten)

Erzeuge pro Item mehrere Slice-Kandidaten, nicht nur „eine bessere Unterteilung“.

Leitfragen (wähle 2-3 davon, nicht alle):

  • Was ist der kleinste beobachtbare Value-Sprung nach diesem Slice?
  • Welche User-Journey-Schritte (oder Workflow-Pfade) sind unabhängig voneinander?
  • Welche Business Rules / Ausnahmen kann man zuerst vereinfachen (Rules)?
  • Welcher Datensatz- oder Umfangs-Subset liefert zuerst Value (Data)?
  • Welche User-Interface-Variante kann zuerst bereit sein (Interfaces)?
  • Welche Risiko-Unklarheit blockiert aktuell so sehr, dass ein Spike sinnvoll ist (Spikes)?

Wichtig: Jeder Slice soll so formuliert werden, dass er als „mini Version“ des Outcomes wirkt (nicht als reiner Task).

Schritt 4: Slice-Qualität prüfen (INVEST + Value-Credibility)

Für jeden Kandidaten, 5-Minuten-Check:

  1. Valuable? Liefert der Slice einen sichtbaren/prüfbaren Nutzen oder reduziert sinnvoll Risiko?
  2. Testable/Done? Gibt es eine klare Definition of Done in Outcome-Sprache?
  3. Independent/Small? Kann das Team den Slice am Ende wirklich liefern, ohne dass „alles andere noch fehlt“?
  4. Through-the-stack? Berührt der Slice genug, damit am Ende ein echter End-to-End Effekt beobachtbar ist?

Wenn ein Punkt klar scheitert:

  • entweder ändere den Slice (z.B. vereinfachen, erst Kernregel/Data),
  • oder kombiniere ihn mit anderen Bausteinen, sodass Value zurückkommt.

Schritt 5: Cut-Liste erstellen (Was schneiden wir konsequent weg?)

Ziel: „Weniger, aber besser.“

Setze für die Cut-Liste diese Kategorien:

  • Nicht traceable: kein nachvollziehbarer Weg vom Goal -> Impact -> Deliverable (klassisch mit Impact Mapping sichtbar machen).
  • Kein Value Increment: wirkt wie Infrastruktur/Task, liefert aber nicht end-to-end beobachtbare Verbesserung.
  • Zu horizontal: wird technisch geliefert, aber der Nutzer/Stakeholder merkt am Ende keinen echten Fortschritt.

Konsequenz:

  • Items aus der Cut-Liste gehen raus oder werden umgeschnitten (z.B. als Spike, oder als Enabler Story, die direkt in ein Value-Slice „einrastet“).

Schritt 6: Konkrete Slices in Story-Sprache bringen

Formatiere jeden Slice als wertbasiertes Story-Fragment:

  • Persona/Stakeholder
  • was sie nachher konkret können/erleben
  • warum das dem Business/Outcome hilft (so dass-Teil)

Wenn du merkt, dass du nur technische Schritte beschreibst:

  • halte inne und formuliere zuerst die beobachtbare Nutzer-/Business-Änderung,
  • dann erst (minimal) die notwendige „durch die Schichten“ Umsetzung.

Schritt 7: Priorisieren nach Value-Fortschritt (und Risiko)

Priorisiere Slices typischerweise so:

  • die, die früh sichtbaren Value liefern,
  • oder die, die das größte Risiko klären (Spikes),
  • oder die, die viele Folge-Slices erst möglich machen (Dependencies, aber immer mit Value-Begründung).

Merke: Priorität ist dann „gut begründet“, wenn du sie jederzeit mit Outcome/Impact erklären kannst, nicht nur mit Aufwand/Komplexität.

7) Team-Templates (zum Ausfüllen)

Business Value Card (kurz)

Felder:

  • Outcome/Metric: Welche messbare oder beobachtbare Wirkung?
  • Baseline: Wo stehen wir heute?
  • Target: Was ist nach dem Slice anders?
  • Stakeholder/Persona: Wer profitiert (wer spürt den Unterschied)?
  • Assumption: Was nehmen wir an, dass Value entsteht?
  • Definition of Done (Value): Woran merken wir „es war wertvoll“?

Slicing Checklist (1 Seite, 30 Sekunden)

Für jeden Slice:

  • „Kann das Team Ende des Inkrements einen echten Value-Effekt zeigen?“
  • „Ist es durch die Schichten geschnitten (end-to-end), nicht nur horizontal nach Technik?“
  • „Sind WENN/als Test die Acceptance Criteria so, dass wir es prüfen können?“
  • „Wenn wir nur diesen Slice liefern: Haben wir schon einen Fortschritt im Outcome?“

Cut-Liste (3 Kategorien)

  • Nicht traceable
  • Kein Value Increment
  • Zu horizontal / zu abhängig

8) Umgang mit „technischen“ Items, ohne sie zu tarnen

Technische Arbeit verschwindet nicht. Aber sie braucht die richtige Rolle:

  • Wenn es Unsicherheit gibt: als Spike schneiden, mit klarer Antwort/Entscheidung.
  • Wenn es notwendig ist, damit Value überhaupt entsteht: als Enabler, aber so verknüpft, dass ein Value-Slice am Ende nutzbar ist.
  • Wenn es nur Infrastruktur ohne sichtbaren Outcome ist: umformulieren oder parken, bis ein Value-Slice es „braucht“.

Der Qualitätshebel ist die Wert-Formulierung:

  • Erst Outcome/Value-Sprung,
  • dann die minimal notwendigen technischen Schritte, um ihn auszuliefern.

9) Mini-Beispiel (vom technischen Epic zum wertbasierten Slice)

Technisch (typischer Anti-Pattern):

  • „Implementiere Login-API, DB-Tabelle, Tests“

Wertbasiert (richtige Richtung):

  • „Als Nutzer kann ich mich anmelden, damit ich sicher auf meinen Bereich zugreifen kann.“

Slicing dazu (Beispielhaft):

  • Rules/Interfaces/Data: erst Basis-Anmeldung ohne komplexe Sonderfälle,
  • Paths: erst Happy Path, dann Fehler-/Retry-Pfade als eigener Slice,
  • Ziel: Nach jedem Slice ist ein nutzbarer Value-Effekt am Ende sichtbar.

10) Quellen (Internet + PKMS)

Internet (Story Splitting / Slicing / Value)

PKMS (Wert-/Value-Gedanken, als Orientierung)

  • „Million Dollar Consulting - Wissensbasis … 4.5 Wert-Tenets (Grundsätze)“ (im PKMS-Vault auffindbar)
  • „Value Stream Mapping“ (im PKMS-Vault auffindbar)
  • „Outcome based roadmaps“ / Roadmap-Reflexion (im PKMS-Vault auffindbar)

Linking