LoopsWork
Interactive Guide
Ein durchgängiges End-to-End-Beispiel

CART 1.0: vom Purpose zum nächsten Build.

So greifen Build, Value und Learning am selben Warenkorb ineinander.

CART 1.0 · Überblick in 2 Minuten

Eine Änderung. Drei Loops. Die nächste Verbesserung.

Mengen im Warenkorb ändern: Verfolge dieselbe Produktänderung vom Purpose bis zur nächsten kleinen Spec. Öffne nur die Stationen, die du vertiefen möchtest.

Durchgängiges Lehrbeispiel. Daten, Jira-IDs, Repository-Pfade und Budgets sind illustrative Annahmen; es wird kein realer Shop betrieben.

BUILD → VALUE → LEARNING → BUILDDie Reihenfolge erklärt den Zusammenhang. Messplanung und Lernen beginnen bereits während Build.

01Problem / PurposeKunden sollen Mengen korrigieren und den Gesamtpreis verstehen.Build

Eine konkrete Einkaufssituation

Eine Kundin hat zwei Packungen Kaffee gewählt, benötigt aber nur eine. Sie soll die Menge direkt im Warenkorb ändern und sofort den gültigen Gesamtpreis einschließlich Versand sehen können. Unklare Summen und umständliche Korrekturen sollen seltener zum Abbruch führen.

Purpose: Einkäufe vor dem Checkout verständlich und korrigierbar machen. Die erwartete Wirkung wird vor dem Bauen formuliert und später gemessen.

02Pitch / BudgetEin kleiner Warenkorb-Beitrag mit fünf Teamarbeitstagen und 50 € KI-Budget.Build

Vorschlag und Entscheidungsrahmen

PitchVereinbarung
CART 1.0Artikel hinzufügen, Mengen ändern, entfernen, Bestand beachten und Versand transparent berechnen.
ErwartungCheckout-Beginn von 58 % auf mindestens 62 % geeigneter Warenkorb-Sitzungen verbessern.
BudgetMaximal 5 Teamarbeitstage + 50 € KI-Kosten; Prüfpunkt nach halbem Verbrauch.
Außerhalb des UmfangsRabattcodes, Zahlung und geräteübergreifende Synchronisierung.
EntscheidungPO priorisiert im Mandat; Team verantwortet technischen Weg und Qualität. Bei Budgetdruck Umfang in der Spec Clinic neu vereinbaren.

Investitionsrahmen vertiefen ↗

03Small SpecCART-QTY 1.0 konkretisiert die Mengenänderung aus CART 1.0.Build

CART 1.0 bleibt die bestätigte Gesamtspec. Für den folgenden Agentenauftrag wird die Mengenänderung als kleiner, separat prüfbarer Ausschnitt vereinbart. Seine Kriterien referenzieren die AK-IDs der Gesamtspec.

SPEC CART-QTY 1.0 · Status: bestätigt
Owner: Product Owner + Fachpartner · technischer Vertrag: Team
Bezug: CART 1.0 / AK-02, AK-03, AK-04, AK-05, AK-06
Ziel: Menge einer bestehenden Position ändern; Summen konsistent halten.
Nicht enthalten: neue Produkte, Rabattcodes, Zahlung.

PUT /cart/items/{productId}
Body: { "quantity": 2 }
200: aktualisierter Warenkorb mit serverseitig berechneten Summen
400: keine ganze Zahl oder negative Menge
404: Artikel unbekannt
409: Bestand überschritten; Warenkorb bleibt unverändert
quantity = 0: Position entfernen; leere Summe = 0, Checkout deaktiviert.

Beispiel: 2 × 1.490 Cent Kaffee + 490 Cent Versand = 3.470 Cent.
Versand: 490 Cent unter 5.000 Cent Warenwert, ab 5.000 Cent kostenfrei.
Messung: cart_quantity_changed erst nach erfolgreicher Zustandsänderung.
Fehler: Anzeige und gespeicherter Warenkorb bleiben konsistent.

Vollständige CART-1.0-Spec lesen und kopieren ↗

04Small ContextEin Auftrag, eine bestätigte Spec, wenige relevante Dateien.Build

Beispielhafte Abbildung in Jira

ArbeitseinheitInhalt
CART-10 · CART 1.0Übergeordneter Auftrag mit Purpose, Budget und Verweis auf die führende Spec.
CART-12 · SubtaskMengenänderung nach CART-QTY 1.0 umsetzen und nachweisen.
CART-13 · SubtaskUnabhängiger Review derselben Spec- und Code-Version.

Ein Jira-Subtask bündelt einen begrenzten Auftrag mit prüfbarem Ergebnis. Er ersetzt keine Spec. Getrennte kleine Arbeitseinheiten erlauben getrennte Agentenläufe; gemeinsame Schnittstellen und die führende Spec bleiben verlinkt. Nicht jeder Subtask muss ein eigenständig veröffentlichbares Feature sein.

Kontextpaket für CART-12 (illustratives Repository):
• bestätigte CART-QTY 1.0 + relevante Kriterien aus CART 1.0
• src/cart/updateQuantity.ts
• src/cart/totals.ts
• tests/cart/updateQuantity.test.ts
• Vertrag der Bestandsschnittstelle + Testbefehl
Nicht mitsenden: gesamtes Jira-Projekt, fremde Features, alte Spec-Entwürfe.
Stoppen bei: unklarer Preisquelle, widersprüchlichem Bestand oder zusätzlichem Scope.

Jira und Confluence im Zusammenhang ↗

05Agent AssignmentDer Workmaster erhält einen begrenzten Auftrag mit Stop-Regeln.Build

Konkreter Agentenauftrag

Rolle: Workmaster · Task: CART-12
Arbeitsgrundlage: bestätigte CART-QTY 1.0, Referenz CART 1.0.
Auftrag: Implementiere die Mengenänderung, ohne andere Warenkorbfunktionen zu ändern.
Nutze nur das Kontextpaket aus Station 4; fordere fehlende Verträge an.
Grenzen: keine neuen Abhängigkeiten, keine Preis- oder Bestandsregeln ändern.
Tests und Akzeptanzkriterien dürfen nicht abgeschwächt werden.
Budget: höchstens 3 Korrekturversuche innerhalb des zugewiesenen Restbudgets.
Stop: Spec-Widerspruch, neuer Scope, fehlende Daten oder Budgetende → Team fragen.
Liefere: Diff, Testbefehl + Resultat, AK-Zuordnung, offene Risiken.
Keine Produktionsfreigabe. Unabhängiger Prüfer erhält einen separaten Kontext.

Workmaster · Anpassbare Prompt-Vorlage

06BuildRed → Green → Refactor für dieselbe kleine Änderung.Build

Zuerst beschreibt ein fehlschlagender Test die Mengenänderung. Der Workmaster implementiert anschließend das kleinste passende Verhalten und vereinfacht es bei weiterhin grünen Tests.

// Illustrative implementation sketch — server-side prices and stock.
function updateQuantity(cart, product, quantity) {
  assertIntegerAtLeastZero(quantity);
  assertWithinStock(quantity, product.stock);
  const next = replaceOrRemoveLine(cart, product.id, quantity);
  return calculateTotalsInCents(next);
}

Das Ergebnis bleibt ein prüfbarer Diff zu CART-QTY 1.0. Preisquelle, Cent-Berechnung, Fehlerverhalten und das vereinbarte Messereignis gehören zum Auftrag. Erst der Review bestätigt den technischen Stand.

07Tests & ReviewKriterien werden automatisiert geprüft und unabhängig bewertet.Build
AKPrüffallErwartung
AK-02Menge 2 → 0; zusätzlich −1 und 1,5 prüfen.Position entfernt; ungültige Mengen abgewiesen.
AK-036 Kaffee bei Bestand 5.409, Warenkorb unverändert.
AK-04Menge von 1 auf 2 ändern.Summe 3.470 Cent inkl. Versand, Anzeige konsistent.
AK-054.999 / 5.000 Cent490 / 0 Cent Versand.
AK-06Letzte Position entfernen.Summe 0, Checkout deaktiviert.

Der separate Prüfer betrachtet auch Gegenfälle, Zustandswechsel und Integration. Ein menschlicher Reviewer prüft Spec, Code und Testbelege gemeinsam und entscheidet über die technische Freigabe. Die Nachweise nennen Spec-Version, AK-ID und geprüften Commit.

Vorhandene Demo-Prüffälle selbst ausführen ↓ · Die Browserdemo ersetzt keine Server- oder Integrationstests.

08AcceptanceDer Fachpartner bestätigt das vereinbarte Verhalten.Build

An Tag 5 prüft der Fachpartner im Acceptance Slot die Einkaufsfälle auf der vorbereiteten Testversion: Menge ändern, Versandgrenze überschreiten und den letzten Artikel entfernen. Er bestätigt die AKs oder gibt konkrete Abweichungen zurück.

Menschliche Entscheidung

„Die vereinbarten Kriterien sind für diesen Stand erfüllt.“ Das ist fachliche Abnahme. Es ist noch kein Nachweis der Produktwirkung und keine automatische Produktionsfreigabe. Neue Wünsche werden separat priorisiert.

Acceptance Slot ↗

09DeploymentEine freigegebene Version wird kontrolliert aktiviert.Build

Nach technischer und fachlicher Freigabe entscheidet der benannte Freigabeverantwortliche über die Aktivierung für eine begrenzte Nutzergruppe. Spec, Commit, Release und Gruppenzuordnung werden gemeinsam dokumentiert.

  • Messereignisse und Zuordnung nach der Aktivierung kontrollieren.
  • Fehler- und Performance-Signale beobachten; Rücknahmeweg bereithalten.
  • Bei Störung sofort reagieren; das nächste Value Review ist keine Wartepflicht.
10MonitoringBetriebssignale und Produktmessung betrachten dieselbe aktivierte Änderung.Value

Alle folgenden Werte und Auslöser sind illustrative Beispieldaten.

SignalBeobachtung / RegelReaktion
Änderungsfehler0,6 % · Schutzgrenze ≤ 1 %Bei > 1 % über 10 Minuten Team alarmieren und Aktivierung prüfen.
Performance p951,2 s · Schutzgrenze ≤ 1,5 sBei anhaltender Überschreitung Ursache untersuchen und Ausweitung pausieren.
ZustandsfehlerAn Tag 8 bleibt nach Mengenänderung eine Summe zeitweise veraltet.Nächste Arbeit pausieren; separater Fix mit Regressionstest, 0,5 Teamtag und 5 € KI-Budget.
ProduktmetrikCheckout-Beginn je geeigneter Warenkorb-Sitzung; Events je Sitzung deduplizieren.Release, Gruppe und Messfenster zuordnen; keine Wirkung aus fehlerhaften Events ableiten.
Fehlende EvidenceAbgeschlossene Käufe und Preisbeschwerden noch unvollständig.Datenlücke mit Owner festhalten.

Technische Stabilität ist eine Voraussetzung. Ob Kunden und Business profitieren, wird in der Scorecard geprüft.

11Value Loop / Scorecard58 % erwartet als Ausgangswert, mindestens 62 % als Ziel, 64 % beobachtet.Value

Feature Scorecard · CART 1.0

Erfundene Beispieldaten – keine Messung dieser Website.

FeldCART-1.0-Befund
HypotheseEinfachere Mengenänderung und transparente Summen erhöhen den Checkout-Beginn.
Ausgangswert / Ziel58 % / ≥ 62 %
MessplanTag 6–18, zeitgleiche Vergleichsgruppe und Variante; je 1.000 geeignete Sitzungen als Beispiel, kein allgemeiner Mindestwert.
Beobachtet580/1.000 = 58 % → 640/1.000 = 64 % · +6 Prozentpunkte
SchutzkennzahlenÄnderungsfehler 0,6 % ≤ 1 %; p95 1,2 s ≤ 1,5 s.
UnsicherheitRandomisierung nicht belegt, mögliche Gruppenunterschiede; Kauf- und Beschwerdebefunde fehlen. Bugfix an Tag 8 in der Auswertung berücksichtigen.
InterpretationDas Beispielziel wird numerisch erreicht. Zusätzliche Käufe und kausale Wirkung sind damit nicht belegt.

Vollständige Scorecard und kopierbare Vorlage ↗

12Value ReviewBegrenzt beibehalten und gezielt weitere Evidence sammeln.Value

An Tag 20 legt der Messpartner die aktualisierte Scorecard mit Datenlücken und Empfehlung vor. PO, Fachpartner und Team bewerten Nutzen, Risiken und Aussagekraft. Der PO entscheidet innerhalb seines Mandats.

Entscheidung für CART 1.0

Begrenzte Variante beibehalten, noch nicht ausweiten. Der Messpartner klärt Vergleichbarkeit und fehlende Kauf- und Beschwerdebefunde. Das Team ergänzt nötige Messpunkte. Nächster Prüfpunkt in fünf Arbeitstagen.

Behalten, verändern, erweitern, zurückbauen oder weiter untersuchen sind mögliche Entscheidungen. Die Zahlen lösen keine automatische Freigabe aus. Regelmäßiges Value Review: alle vier Wochen; konkrete Nachweise können einen früheren Prüfpunkt auslösen.

13Learning LoopDer Summenfehler wird zu einem begrenzten Experiment für Zustandswechsel-Tests.Learning

Der Fix an Tag 8 beseitigt den Fehler. In der Retrospektive an Tag 10 untersucht das Team das wiederkehrende Muster: Prüffälle betrachten Endzustände, aber zu selten den Übergang zwischen ihnen.

ArbeitsgrundlageKonkrete Anpassung im Experiment
Spec TemplateEin Feld „Vorher → Aktion → Nachher“ samt Fehlerzustand ergänzen.
Test / KI-PrüfskillVersion 0.2 prüft Menge 1 → 2 → 0, abgelehnten Bestand und Summe nach jeder Änderung.
Prompt / Agent InstructionsNach jeder Zustandsänderung Anzeige, gespeicherten Zustand und Summe gemeinsam nachweisen; fehlende Fälle offen nennen.
ArbeitsregelReview-Nachweise enthalten AK-ID und Vorher-Nachher-Fall. Kontextgröße bleibt im Vergleich konstant.

Das ist ein einziges Experiment mit dem versionierten Prüfskill als Veränderung. Die zugehörigen Spec- und Prompt-Hinweise machen dieselbe Prüfregel anwendbar. Das Team vergleicht geeignete Fälle nach Fehlern, Nacharbeit, menschlicher Prüfzeit und KI-Kosten. An Tag 20 wird bewertet; dauerhafte Übernahme erst bei belegtem Nutzen, bei dünner Datenlage weiter erproben.

Lernexperiment-Vorlage ↗

14Zurück in den Build LoopCART-OBS 1.1 ergänzt einen fehlenden Messpunkt und nutzt den neuen Prüfskill.Build

Die nächste kleine Änderung

SPEC CART-OBS 1.1 · nächster bestätigungsbedürftiger Ausschnitt
Purpose: Checkout-Starts einer gültigen Warenkorbversion zuordnen.
Änderung: Erst nach bestätigter Zustandsänderung eine cart_revision vergeben;
checkout_started referenziert diese Revision, Release und Versuchsgruppe.
Kriterien: kein Erfolgsereignis bei abgelehnter Menge; ein Checkout-Event je Sitzung;
Zustandswechsel 1 → 2 und abgelehnter Bestand erhalten konsistente Zuordnung.
Grenzen: keine neue Preislogik, keine personenbezogenen Freitexte.
Nachweis: automatisierte Ereignis-Tests + geprüfte Telemetrie in Testumgebung.
Vor Umsetzung: PO, Messpartner und Team bestätigen Spec und kleinen Budgetrahmen.

Das Value Review liefert die Messlücke, Learning liefert die verbesserte Prüfung. Daraus entsteht ein neuer begrenzter Build-Auftrag am selben Warenkorb. Value beobachtet weiter; die Loops arbeiten parallel.

↻ Zurück zum Spec-Schritt
Ausführliche Referenz: derselbe CART-Verlauf über 20 Arbeitstage
Interaktive Fallstudie · 20 Arbeitstage

Vom Bedarf zur nächsten Anpassung.

Vier Wochen überfliegen, einzelne Tage vertiefen. Tag 1 ist ein Montag; die Wochenenden bleiben ausgeblendet. Die Loops laufen parallel – der Kalender ist ein Beispiel, kein vorgeschriebener Entwicklungszyklus.

  1. Bedarf
  2. Hypothese
  3. Specs
  4. Umsetzung
  5. Evidence
  6. Value messen
  7. Lernen
  8. Nächste Anpassung

Regeln und Zahlen sind Beispielannahmen. Pro Tag: Fokus und erwarteter Output. Die Markierungen zeigen die beteiligten Loops. Support, kleine Tasks und Flow Check laufen über alle vier Wochen mit.

Woche 1

Klären, bauen und aktivieren

Tag 1BuildValueLearning

Bedarf und Wirkung klären

Fokus: Problem, Hypothese und Investitionsrahmen gemeinsam festlegen.

Output: Begrenzter Auftrag, erste Hypothese und Messplan.

Details ansehenDetails schließen

Agenten unterstützen

Scout · Planer

Evidence & Entscheidung

Budget: höchstens 5 Teamarbeitstage und 50 € KI-Kosten; Prüfpunkt bei halbem Verbrauch.

Arbeit und Termine an diesem Tag

B1–B4 / V1–V2
Problem, Spec & Messplan

Tag 1: Problem, Budget, Hypothese und Messplan vereinbaren. Tag 2: Regeln bestätigen, Umsetzung und Prüffälle planen. Beispielrahmen für den ersten Warenkorb: höchstens 5 Teamarbeitstage und 50 € KI-Kosten; Teamaufwand ist nicht gleich Kalenderdauer. Die Spec Clinic verschiebt die zusätzliche Merkliste.

Beteiligte: PO, Delivery Team, Feature Partner und Measurement Partner; Scout und Planer unterstützen.

Tagesgeschäft
Support & kleine Tasks

Laufender Arbeitsstrom über alle vier Wochen, keine durchgehende Vollzeitauslastung. Anfragen sichten, nach Wirkung und Dringlichkeit ordnen, innerhalb des vereinbarten Arbeitslimits ziehen. Ein kleines Ticket erhält Ist/Soll, Owner und Nachweis.

Beteiligte: Delivery Team; PO oder Fachpartner nach Entscheidungsbedarf.

Passende Erklärung öffnen ↗
L1–L2
Erfahrungen sammeln

Von Beginn an Nacharbeit, Feedback und Wartezeiten erfassen. Der Bugfix an Tag 8 liefert einen konkreten Befund: Zustandswechsel waren nicht ausreichend abgedeckt. Das Team untersucht das Muster in der Retrospektive an Tag 10.

Beteiligte: Team und Loop Lotse; Lernbegleiter bündelt freigegebene Beobachtungen.

täglich · 09:00
Flow Check

An jedem Arbeitstag 09:00, bis 10 Minuten: Stand korrigieren, Fertigstellung und Blockaden klären, nächste Aktion und Owner bestätigen. Operative Arbeit und verdrängte Aufgaben sind sichtbar.

Beteiligte: Delivery Team; PO und Loop Lotse bei Bedarf.

Passende Erklärung öffnen ↗
wöchentlich · 10:00
Refinement

Montags um 10:00 für 45 Minuten. Nächste kleine Arbeit vorbereiten, Umfang und Budget prüfen. An Tag 1 betrifft das den Warenkorb, danach die nächste Arbeit; laufende Features werden nicht jede Woche neu geplant.

Beteiligte: PO, Team und relevante Fach- und Messpartner.

Passende Erklärung öffnen ↗

Der konkrete Warenkorb-Fall

B1–B2 + V1

Welches Problem lösen wir?

Kunden sollen ihre Auswahl vor dem Checkout einfach korrigieren und den Gesamtpreis verstehen können. Die erste kleine Änderung umfasst Hinzufügen, Mengenänderung, Entfernen und transparente Versandkosten.

PO priorisiert im MandatFachpartner liefert BeispieleScout findet offene Fragen

Wirkungshypothese

Wenn Kunden Mengen direkt ändern können und den Gesamtpreis sehen, erreichen mehr Nutzer mit gefülltem Warenkorb den Checkout.

Nächster Nachweis

Ein kurzer Nutzertest zeigt, ob Menge, Entfernen und Versandkosten ohne Erklärung verstanden werden.

Bewusst offen klären

  • Was passiert bei Menge 0?
  • Wie reagieren wir auf zu wenig Bestand?
  • Ab wann entfällt der Versand?
  • Wer bestimmt den gültigen Preis?

Kleiner Anfang

Illustrativer Auftrag: Die Bereichsleitung gibt mit der Initiative „Einkauf vereinfachen“ die Richtung vor. Der PO konkretisiert den Warenkorb-Beitrag und entscheidet im delegierten Rahmen. Beispielbudget aus B1: höchstens 5 Teamarbeitstage plus 50 € KI-Kosten; Prüfpunkt bei halbem Verbrauch. Rabattcodes, Gastkonto-Synchronisierung und Zahlung gehören nicht zu dieser Änderung. Reicht der Rahmen nicht, verkleinern PO und Team in der Spec Clinic den Umfang weiter. Preisrichtigkeit, Bestandsgrenzen und nötige Tests bleiben verbindlich.

Specs, Prompts & Artefakte

VALUE

Feature Scorecard

Vorlage für Hypothese, Messplan, Ergebnis, Unsicherheit und Entscheidung.

Vorlage öffnen ↗

Mögliche Abbildung in Jira / Confluence

Pitch bzw. Auftrag mit der kleinen Jira-Aufgabe verknüpfen. CART 1.0 als führenden, versionierten Stand referenzieren; offene Regeln und Entscheidungen nachvollziehbar festhalten.

Tooling im Zusammenhang ansehen ↗

Warenkorb ausprobieren & Demo-Prüffälle ausführen ↓

Tag 2BuildValueLearning

Spec bestätigen und Umfang schneiden

Fokus: Regeln und Messanforderungen klären; die Merkliste in der Spec Clinic verschieben.

Output: Bestätigte CART 1.0 mit Akzeptanzkriterien und Umsetzungsplan.

Details ansehenDetails schließen

Agenten unterstützen

Scout · Planer

Arbeit und Termine an diesem Tag

Problem, Spec & Messplan
Ablauf und Beteiligte · Tag 1 →
Support & kleine Tasks
Ablauf und Beteiligte · Tag 1 →
Erfahrungen sammeln
Ablauf und Beteiligte · Tag 1 →
Flow Check
Ablauf und Beteiligte · Tag 1 →
bei Bedarf · Tag 2
Spec Clinic

Tag 2 um 11:00, 30 Minuten: Die zusätzliche Merkliste sprengt den Rahmen. Nützlichen Kern bestätigen, Merkliste verschieben und Spec, Tests und Messanforderungen synchronisieren. Die Clinic ist anlassbezogen, kein wöchentlicher Pflichttermin.

Beteiligte: PO, zuständige Entwickler, Fachpartner; Loop Lotse bei Bedarf.

Passende Erklärung öffnen ↗

Der konkrete Warenkorb-Fall

B3 + V2 · SPEC CART 1.0

Ein vereinbartes Verhalten statt „Bau mal einen Warenkorb“.

PO und Fachpartner bestätigen Regeln; das Team ergänzt technische Verträge. Dieselbe bestätigte Spec-Version steuert Tests, Implementierung und Dokumentation.

Vollständige Spec CART 1.0 lesen und kopieren · Eigene Spec ausfüllen

Ein konkreter Stand für alle Beteiligten

Gültige Grundlage dieser Demo: Spec CART 1.0. In einem echten Projekt könnte sie als specs/cart.md im Repository liegen. Der Arbeitsauftrag nennt „CART 1.0“ und den konkreten Commit-Link; Tests referenzieren etwa CART 1.0 / AK-05. Review und Abnahme halten zusätzlich die geprüfte Code-Version fest. Das Release verbindet diese Nachweise mit der Scorecard.

Beispiel: Von CART 1.0 zu einem Änderungsvorschlag
  1. Ausgangslage: CART 1.0 / AK-05 vereinbart kostenlosen Versand ab 5.000 Cent. Dieser bestätigte Stand bleibt erhalten.
  2. Vorschlag: CART 1.1 im Status „Entwurf“ soll die Grenze auf 6.000 Cent ändern. Im Änderungsverlauf stehen Grund, betroffene Regel AK-05, vorschlagende Person und Datum. Das ist ein hypothetisches Folgevorhaben; die Demo bleibt bei 5.000 Cent.
  3. Auswirkungen prüfen: PO und Fachpartner entscheiden über die neue Regel. Das Team berücksichtigt Anzeige, Berechnung und Grenztests; der Messpartner prüft Hypothese und Vergleichbarkeit. Bereits laufende KI-Aufträge werden auf die Änderung geprüft.
  4. Erst nach Bestätigung umsetzen: CART 1.1 erhält Bestätigung und festen Versionsverweis. Spec, Code und Tests werden gemeinsam geändert, darunter 5.999 und 6.000 Cent. Abnahme und Release dokumentieren den tatsächlich geprüften Stand. In der Wirkungsauswertung werden Daten vor und nach der Regeländerung getrennt zugeordnet.

Entscheidend: Ein neuer Entwurf ersetzt nicht stillschweigend die bisherige Vereinbarung. Bei einer Rücknahme müssen Code, Konfiguration und zugehöriger Spec-Stand wieder zusammenpassen.

KriteriumVereinbarte RegelPrüfbeispiel
AK-01Hinzufügen erhöht die Menge einer vorhandenen Position.Kaffee zweimal hinzufügen → eine Position, Menge 2.
AK-02Mengen sind ganze Zahlen. Menge 0 entfernt die Position.Von 1 auf 0 → Position weg; negative Menge abweisen.
AK-03Bestand darf nicht überschritten werden.6 Kaffee bei Bestand 5 → Fehler, bisheriger Warenkorb bleibt.
AK-04Preise werden in Cent gerechnet, der Server ist maßgeblich.2 × 1.490 + 490 Versand = 3.470 Cent.
AK-05Versand 490 Cent, ab 5.000 Cent Warenwert kostenlos.4.999 → Versand 490; 5.000 → Versand 0.
AK-06Leerer Warenkorb hat Summe 0; Checkout ist gesperrt.Letzten Artikel entfernen → kein Checkout.

Beispiel für den Schnittstellenvertrag

PUT /cart/items/{productId}
Body: { "quantity": 2 }  // setzt die gewünschte Menge
200: aktualisierter Warenkorb inkl. serverseitiger Summen
400: ungültige Menge · 404: unbekannter Artikel
409: Bestand reicht nicht · Warenkorb bleibt unverändert
quantity: 0 entfernt die Position; Antwort enthält den Restwarenkorb.

Die Demo bildet diese Regeln im Browser ab. Eine echte Umsetzung prüft Zugriff, aktuelle Preise und Bestand auf dem Server. Der Vertrag ist ein Entwurf, kein hier erreichbarer API-Endpunkt.

Messpunkte aus V2: erfolgreiche Mengenänderung, Warenkorbfehler und Beginn des Checkouts. Events pro Aktion eindeutig zuordnen und ohne personenbezogene Freitexte erfassen.

Specs, Prompts & Artefakte

SPEC

Versionierte Spec · CART 1.0

Vollständiges ausgefülltes Muster mit Regeln, AK-IDs, Messung und Betrieb.

Spec öffnen ↗

Mögliche Abbildung in Jira / Confluence

Pitch bzw. Auftrag mit der kleinen Jira-Aufgabe verknüpfen. CART 1.0 als führenden, versionierten Stand referenzieren; offene Regeln und Entscheidungen nachvollziehbar festhalten.

Tooling im Zusammenhang ansehen ↗

Warenkorb ausprobieren & Demo-Prüffälle ausführen ↓

Tag 3BuildValueLearning

Prüffälle und kleine Umsetzung verbinden

Fokus: Mengen, Bestand, Cent-Summen und Versandgrenze testen und Messereignisse mitbauen.

Output: Prüffälle mit AK-Bezug und ein erster überprüfbarer Umsetzungsstand.

Details ansehenDetails schließen

Menschen verantworten

Delivery Team

Agenten unterstützen

Prüfer · Workmaster

Evidence & Entscheidung

Die bestätigten AK-IDs liefern den Prüfmaßstab. Ein Red-Test muss am fehlenden Verhalten scheitern, bevor die kleinste passende Umsetzung folgt.

Arbeit und Termine an diesem Tag

B5–B8
Testen, bauen & prüfen

Tag 3–4: Tests für Mengen, Bestand, Cent-Summen und Versandgrenze; kleine Umsetzung, Refactoring und unabhängige Prüfung. Am vereinbarten Budgetprüfpunkt den verbleibenden Umfang bestätigen. Messereignisse werden mitgebaut.

Beteiligte: Delivery Team mit Prüfer und Workmaster; unabhängiger menschlicher Reviewer.

Support & kleine Tasks
Ablauf und Beteiligte · Tag 1 →
Erfahrungen sammeln
Ablauf und Beteiligte · Tag 1 →
Flow Check
Ablauf und Beteiligte · Tag 1 →

Specs, Prompts & Artefakte

SPEC

Versionierte Spec · CART 1.0

Vollständiges ausgefülltes Muster mit Regeln, AK-IDs, Messung und Betrieb.

Spec öffnen ↗

Mögliche Abbildung in Jira / Confluence

Jira-Aufgabe, Spec-Version, AK-IDs, Pull Request und Testnachweise verbinden. Abnahme und Release referenzieren denselben geprüften Stand.

Tooling im Zusammenhang ansehen ↗

Warenkorb ausprobieren & Demo-Prüffälle ausführen ↓

Tag 4BuildLearning

Vereinfachen und unabhängig prüfen

Fokus: Änderung und Gegenfälle prüfen; den verbleibenden Umfang am Budgetprüfpunkt bestätigen.

Output: Review-Befunde und Testnachweise zur geprüften Code- und Spec-Version.

Details ansehenDetails schließen

Menschen verantworten

Delivery Team · Product Owner

Agenten unterstützen

Prüfer · Workmaster

Arbeit und Termine an diesem Tag

Testen, bauen & prüfen
Ablauf und Beteiligte · Tag 3 →
Support & kleine Tasks
Ablauf und Beteiligte · Tag 1 →
Erfahrungen sammeln
Ablauf und Beteiligte · Tag 1 →
Flow Check
Ablauf und Beteiligte · Tag 1 →

Der konkrete Warenkorb-Fall

B4–B10

Vom Prüffall zur freigegebenen Änderung.

Für diesen Durchlauf gilt CART 1.0. Der KI-Auftrag referenziert den festgelegten Spec-Stand; Testnachweise nennen die AK-IDs. Review, fachliche Abnahme und Release verbinden diesen Stand mit der geprüften Code-Version. Neue Spec-Entwürfe werden erst nach ausdrücklicher Bestätigung zur Arbeitsgrundlage.

SchrittKonkrete AktionVerantwortung / KI
B4 · PlanWarenkorbzustand, Cent-Berechnung und Mengenregeln als kleine Bausteine planen.Team / Planer
B5 · RedTest: zweimal hinzufügen ergibt eine Position mit Menge 2. Vor Implementierung muss er scheitern.Team / Prüfer
B6 · GreenNur das benötigte Verhalten implementieren, bis die geprüften Fälle bestehen.Team / Workmaster
B7 · RefactorBerechnungen zusammenführen, ohne Regeln zu verändern. Tests erneut ausführen.Team / Workmaster
B8 · ReviewAuch Gegenfälle prüfen: 0, −1, Dezimalzahl, zu wenig Bestand und Versandgrenze.Menschlicher Reviewer / separater Prüfer
B9 · AbnahmeFachpartner prüft echte Einkaufsabläufe und bestätigt die Kriterien.Fachpartner; PO klärt Änderungen
B10 · AktivierungKleine Nutzergruppe freischalten. Messung, Fehlerrate und Rücknahme prüfen.Team + menschliche Freigabe

Die Demo-Prüffälle sind ausführbar.

Der Button im Bereich „Warenkorb ausprobieren“ prüft unter anderem Mengen, Bestandsgrenzen, Cent-Summen und Versandkosten. Das ersetzt weder Server-Integration noch fachliche Abnahme.

Testauftrag in der Prompt-Werkstatt öffnen

Specs, Prompts & Artefakte

SPEC

Versionierte Spec · CART 1.0

Vollständiges ausgefülltes Muster mit Regeln, AK-IDs, Messung und Betrieb.

Spec öffnen ↗

Mögliche Abbildung in Jira / Confluence

Jira-Aufgabe, Spec-Version, AK-IDs, Pull Request und Testnachweise verbinden. Abnahme und Release referenzieren denselben geprüften Stand.

Tooling im Zusammenhang ansehen ↗

Warenkorb ausprobieren & Demo-Prüffälle ausführen ↓

Tag 5BuildValueLearning

Abnehmen und kontrolliert aktivieren

Fokus: Um 14:00 reale Fälle abnehmen und anschließend nur mit Freigaben aktivieren.

Output: Abnahme- und Release-Nachweise sowie geprüfte Messereignisse.

Details ansehenDetails schließen

Agenten unterstützen

Prüfer · Workmaster

Evidence & Entscheidung

Fachliche Abnahme und Produktionsfreigabe bleiben getrennte Entscheidungen. Ohne erforderliche Freigaben keine Aktivierung.

Arbeit und Termine an diesem Tag

B9–B10
Abnahme & Aktivierung

Tag 5, 14:00: Acceptance Slot für reale Warenkorb-Fälle. Danach nur bei vorliegenden Freigaben aktivieren und Messereignisse prüfen. Release und Nutzergruppen in der Scorecard vermerken.

Beteiligte: Feature Partner nimmt fachlich ab; Team und Freigabeverantwortlicher liefern aus.

Passende Erklärung öffnen ↗
Support & kleine Tasks
Ablauf und Beteiligte · Tag 1 →
Erfahrungen sammeln
Ablauf und Beteiligte · Tag 1 →
Flow Check
Ablauf und Beteiligte · Tag 1 →
abnahmereif · Tag 5/8
Acceptance Slot

Tag 5 um 14:00: 20 Minuten für den Warenkorb. Tag 8 um 13:30: kurze, gezielte Prüfung des Bugfixes, Beispiel 10 Minuten. Bei risikoarmen Tasks kann dieselbe Rückmeldung asynchron erfolgen.

Beteiligte: Fachpartner oder Vertretung mit zuständigem Entwickler.

Passende Erklärung öffnen ↗

Specs, Prompts & Artefakte

SPEC

Versionierte Spec · CART 1.0

Vollständiges ausgefülltes Muster mit Regeln, AK-IDs, Messung und Betrieb.

Spec öffnen ↗

Mögliche Abbildung in Jira / Confluence

Jira-Aufgabe, Spec-Version, AK-IDs, Pull Request und Testnachweise verbinden. Abnahme und Release referenzieren denselben geprüften Stand.

Tooling im Zusammenhang ansehen ↗

Warenkorb ausprobieren & Demo-Prüffälle ausführen ↓

Warenkorb ausprobieren & Demo-PrüffälleArtikel hinzufügen, Mengen ändern und die bestätigten Regeln prüfen.

Der kleine Onlineshop

Ausprobieren

Kaffee

500 g · ganze Bohne · 5 verfügbar
14,90 €

Grüner Tee

100 g · lose Blätter · 4 verfügbar
8,50 €

Keramikbecher

350 ml · dunkelblau · 3 verfügbar
12,00 €

Versand 4,90 €. Ab 50,00 € Warenwert versandkostenfrei. Gleiche Artikel werden zu einer Position zusammengefasst.

Dein Warenkorb

0 Artikel

Warenkorbregeln prüfen

Parallele Arbeit und Termine als Gesamtübersicht
BEISPIEL / VIER WOCHEN

Vom ersten Auftrag bis zur Wirkung.

Ein vollständiger Beispielablauf mit Feature-Arbeit, Bugfix, Tagesgeschäft und allen sieben Terminen. Tag 1 ist ein Montag; gezeigt werden 20 Arbeitstage ohne Wochenenden.

Lesart: Balken zeigen Zeitfenster, Punkte einzelne Tage. Sie sind keine Aufwandsschätzung und verlangen keine Vollzeitarbeit. Klicke eine Zeile oder einen Termin für Rollen, Uhrzeit und Ergebnis.
AblaufWoche 1Woche 2Woche 3Woche 4
Arbeitstag1234567891011121314151617181920
BuildValueLearningTagesgeschäftTermin
Arbeitsablauf

Problem, Spec & Messplan

Tag 1: Problem, Budget, Hypothese und Messplan vereinbaren. Tag 2: Regeln bestätigen, Umsetzung und Prüffälle planen. Beispielrahmen für den ersten Warenkorb: höchstens 5 Teamarbeitstage und 50 € KI-Kosten; Teamaufwand ist nicht gleich Kalenderdauer. Die Spec Clinic verschiebt die zusätzliche Merkliste.

Beteiligte: PO, Delivery Team, Feature Partner und Measurement Partner; Scout und Planer unterstützen.

Der Vierwochentakt gehört zum Value Review, nicht zu einem vorgeschriebenen Entwicklungszyklus. Ein Feature kann früher oder später fertig werden. Abnahme, Störungsbehebung und Auslieferung warten nicht auf einen Regeltermin.