Die Spec vereinbart Verhalten, der Prompt beauftragt die KI und die Scorecard prüft Wirkung. Für kleine Aufgaben genügt eine schlanke Arbeitskarte.
Den Bedarf beschreiben, den gültigen Stand bestätigen und Kriterien festhalten.
BUILD · VALUE · LEARNINGBegrenzte Aufträge mit Kontext, Werkzeugen und erwarteten Nachweisen.
VALUEHypothese, Messplan, Ergebnis und Produktentscheidung an einem Ort.
Eine Spec ist die führende, versionierte Vereinbarung über das gewünschte Verhalten einer Änderung. Sie verbindet Regeln, Beispiele, Fehlerfälle und Akzeptanzkriterien. Code, Tests und Dokumentation beziehen sich auf dieselbe Version.
Für einen Bug reichen oft Reproduktion, Sollverhalten und ein Regressionstest als Ergänzung der bestehenden Spec. Größere oder riskantere Änderungen brauchen mehr Klärung.
„Bau eine Login-Seite“ lässt viele Entscheidungen offen. Eine Spec benennt etwa Endpunkt, Eingaben, Fehlerantworten und konkrete Erfolgsfälle. KI-Ergebnisse werden anschließend gegen diese Vorgaben geprüft.
Ganze Mengen; Menge 0 entfernt die Position; Bestand nicht überschreiten; Geld in Cent; Versand 490 Cent, ab 5.000 Cent kostenlos. Beim Entfernen des letzten Artikels ist die Summe 0 und der Checkout gesperrt.
Beispiel: PUT /cart/items/{productId} mit quantity; 200 bei Erfolg, 400 bei ungültiger Menge, 404 bei unbekanntem Artikel und 409 bei fehlendem Bestand. Preise und Zugriff werden im echten Shop serverseitig geprüft.
Menschen und KI-Agenten müssen erkennen können, welcher Stand gilt. Sonst entstehen Code, Tests und Abnahme auf unterschiedlichen Grundlagen. Eine nachvollziehbare Historie zeigt, was geändert wurde, warum und wer es bestätigt hat. Sie hilft bei Fehlersuche, Wirkungsauswertung und Rücknahme.
Bei einem Bug: Bleibt das vereinbarte Verhalten gleich, genügt die Referenz auf die bestehende Spec mit Regressionstest. Eine neue fachliche Vereinbarung braucht es erst, wenn sich das Sollverhalten ändert.
Versionierung am Warenkorb-Beispiel ansehen · Vollständige Spec CART 1.0 · Spec mit Lückentext ausfüllen
Starte als Product Owner mit den ersten fünf Punkten. Beschreibe das Problem und zwei oder drei konkrete Situationen in Alltagssprache. Das Team ergänzt die Technik; der Messpartner hilft bei der Wirkungsmessung.
Du musst technische Felder nicht allein lösen. „Offen – klärt das Team bis …“ ist hilfreicher als eine erfundene Antwort. Kleine Aufgaben dürfen kurz bleiben.
So sieht die ausgefüllte Muster-Spec CART 1.0 aus
Der Lückentext enthält einen optionalen Abschnitt für Kritikalität, Monitoring, Alert-Auslöser, SLO / erwartete Verfügbarkeit, Verhalten bei Ausfall und Dashboard / Tool. SLO und Tool-Verweis sind nur bei Bedarf nötig.
Je kritischer eine Änderung, desto genauer die Angaben. Möglicher Schaden, Nutzungshäufigkeit, Abhängigkeiten und Wiederherstellbarkeit bestimmen die Tiefe. Für unkritische Änderungen reicht eine sehr kleine oder keine Angabe.
Bei kritischen Komponenten werden Monitoring, sinnvolle Alerts und überprüfbares Fehlerverhalten mit umgesetzt und vor Abschluss nachgewiesen. Betrieb im Build Loop mitdenken
SPEC [kurzer Name / ID] · Version [0.1] · Status: Entwurf SO STARTET DER PRODUCT OWNER Ersetze die eckigen Klammern durch kurze Sätze. Stichpunkte genügen. Was du noch nicht weißt, bleibt als „offen“ mit einer zuständigen Person stehen. Technik und Messung ergänzt ihr gemeinsam. Beispieltexte sind Hilfen, keine Vorgaben. 1. Für wen lösen wir welches Problem? Der Auftrag kommt von [Team / Vorstand / Geschäftsführung / strategische Initiative / andere Stelle]. Er trägt zu [übergeordnetes Ziel und Link zum Auftrag] bei. Vorgegeben sind [Ziel, Termin, Budget oder Pflichtumfang]. PO und Team dürfen selbst über [Spielraum] entscheiden. Änderungen außerhalb davon bestätigt [zuständige Person / Gremium]. Als [Zielgruppe] möchte ich [Aufgabe erledigen], damit [Nutzen]. Heute passiert dabei [beobachtbares Problem]. Das wissen wir aus [Feedback, Beobachtung oder Daten; sonst: noch zu prüfen]. Beispiel: Kunden möchten ihre Auswahl korrigieren, damit sie die richtige Menge bestellen. Heute ist die Mengenänderung umständlich. 2. Was soll besser werden? Wenn wir [kleine Änderung] ermöglichen, erwarten wir [beobachtbare Verbesserung], weil [Annahme]. Wir erkennen einen Nutzen daran, dass [Signal oder Kennzahl] sich von [Ausgangswert / noch offen] auf [Ziel / gemeinsam festzulegen] verändert. Dabei darf [unerwünschte Nebenwirkung] nicht zunehmen. Beispiel: Mehr Kunden erreichen den Checkout; Preisfehler dürfen nicht zunehmen. Messdetails klären wir mit dem Messpartner. 3. Was ist der kleinste sinnvolle Umfang? In dieser Änderung ermöglichen wir [höchstens wenige konkrete Fähigkeiten]. Bewusst später behandeln wir [Wünsche außerhalb des Umfangs]. Slice: Ist die Spec mit abgegrenztem Kontext verständlich, ohne große Systemerklärung umsetzbar und eigenständig überprüfbar? Wenn nein: [kleinere Specs mit eigenen Prüffällen und benötigtem Kontext]; den Schnitt bestätigen PO und Team. Wir investieren höchstens [Teamaufwand] und [KI-Budget]; bei [Prüfpunkt] entscheiden wir über Fortsetzung oder kleineren Umfang. Den Rahmen vereinbare ich mit [Team / zuständige Person]. 4. Zeige das gewünschte Verhalten an Beispielen. AK-01: Gegeben [Ausgangslage], wenn [Aktion], dann [sichtbares, prüfbares Ergebnis]. AK-02: Gegeben [Grenzfall], wenn [Aktion], dann [erwartete Reaktion]. AK-03: Gegeben [Fehlerfall], wenn [ungültige Aktion], dann [Rückmeldung und was unverändert bleibt]. Nach [weiterer Aktion] muss [neuer Zustand] sichtbar sein. Beispiel: Gegeben ein Artikel mit Menge 1, wenn ich ihn erneut hinzufüge, dann sehe ich eine Position mit Menge 2. Prüffragen: Was passiert bei leer, 0, zu viel, ohne Berechtigung oder nach wiederholtem Klicken? Nur passende Fälle aufnehmen; AK-IDs später nicht neu durchnummerieren. 5. Was müssen wir noch entscheiden? Offene Frage: [Frage]. Klärt [Name] bis [Termin]. Blockiert [betroffene Umsetzung / nichts]. Fachlich bestätigt durch: [PO / Fachpartner, Datum]; bis dahin bleibt diese Spec ein Entwurf. GEMEINSAM MIT DEM TEAM ERGÄNZEN 6. Technische Vereinbarung – Team führt, PO klärt fachliche Folgen. Betroffene Schnittstelle / Eingaben: [Vertrag oder Link]. Ergebnisse, Fehler, Berechtigungen und Datenschutz: [Regeln / offene Entscheidungen]. Tests: [AK-IDs, Gegenfälle, Integrations- und Regressionstests]. Fachliche Abnahme: [Person, Szenarien, Testversion und Termin / Auslöser]. Release, Betriebskontrolle und Rücknahme: [Plan, Owner und Auslöser]. Bei kleinen Aufgaben genügt ein Verweis auf bereits geltende Standards. Reliability & Observability · OPTIONAL Nur soweit relevant ausfüllen. Für unkritische Änderungen reicht eine sehr kleine oder keine Angabe; ein Verweis auf geltende Standards kann genügen. Die Tiefe richtet sich nach Kritikalität, möglichem Schaden, Nutzungshäufigkeit, Abhängigkeiten und Wiederherstellbarkeit. Kritikalität: [hoch / mittel / niedrig] Monitoring: [Welche Metriken, Logs oder Traces werden benötigt?] Alert wenn: [Welche konkrete Abweichung soll einen Alert auslösen? Reaktion, Zuständigkeit und Eskalation klären.] SLO / erwartete Verfügbarkeit: [optional, nur wenn für die Komponente relevant] Verhalten bei Ausfall: [Retry, Fallback, Rollback, Degradation, manueller Eingriff oder anderes Verhalten] Dashboard / Tool: [optional: Link zu Datadog, Grafana, Sentry oder einem anderen System] Kritikalität, akzeptables Risiko, Alert-Schwellen, SLOs, Eskalation und Freigabe bestätigen die verantwortlichen Menschen. 7. Wirkung prüfen – Messpartner unterstützt. Primäre Kennzahl / Zähler / Nenner: [Definition]. Quelle / Ereignisse / Vergleich / Zeitraum: [Plan]. Schutzkennzahlen und Entscheidungsregel: [Grenzen, noch offene Daten]. Scorecard: [Link]. Über Fortsetzung entscheidet [Person] bei [Prüfpunkt]. 8. Einen verlässlichen Stand festhalten. Owner: [Name]. Führende Quelle: [Link]. Bestätigte Version und unveränderlicher Stand: [Version + Commit-Link / Dokumentrevision]. KI-Aufträge, Tests, Review und Abnahme beziehen sich auf [diesen Stand]. Release verbindet [Spec-Stand, geprüfte Code-Version und Nachweise]. Änderungsverlauf: [Version, Datum, Änderung, Grund, betroffene AK-IDs, Bestätigung]. Bei Änderungen laufende KI-Aufträge auf Auswirkungen prüfen und den vereinbarten Stand ausdrücklich festhalten. KURZER CHECK VOR DER UMSETZUNG Kann eine andere Person an meinen Beispielen erkennen, was richtig wäre? Sind Umfang, Verantwortung und Investitionsrahmen klar? Sind kritische offene Fragen geklärt und die Regeln menschlich bestätigt? Verwenden alle denselben Spec-Stand?
Alle Bestandteile an einem Ort: Auftrag, Nutzen, Umfang, Regeln, technischer Vertrag, Prüfungen, Messung, Auslieferung und Versionierung. Offene Punkte für eine echte Umsetzung sind ausdrücklich benannt.
SPEC CART · Version 1.0 · Referenzfassung des LoopsWork-Lernbeispiels Diese vollständig ausgefüllte Muster-Spec beschreibt die bereits gezeigten Warenkorbregeln. Rollen, Budget und Messplan sind illustrative Annahmen. Sie ist keine reale Produktfreigabe und kein Nachweis einer produktiven Implementierung. Führende Beispielquelle: https://loopswork.dev/docs/#cart-spec Owner: Product Owner Onlineshop (Beispielrolle). Fachliche Bestätigung: Feature Partner und PO; technische Vereinbarung: Delivery Team; Messplan: Measurement Partner. Im Lernablauf gilt CART 1.0 ab Abschluss von B3 als bestätigt. Ein reales Bestätigungsdatum und ein unveränderlicher Git-Commit bzw. eine Dokumentrevision müssen bei der Übernahme ins eigene Projekt ergänzt werden. Die Website-URL allein ersetzt diesen festen Stand nicht.
Illustrativer Auftrag: Die Bereichsleitung verantwortet die strategische Initiative „Einkauf vereinfachen“ und beauftragt den PO mit dem Warenkorb-Beitrag. Das ist eine ergänzende Beispielannahme. Der PO priorisiert den konkreten Umfang im beauftragten Rahmen; technische Umsetzung und Arbeitsteilung liegen beim Team. Änderungen am übergeordneten Ziel oder Budget gehen an die Bereichsleitung. Kunden mit einer Artikelauswahl sollen vor dem Checkout Mengen korrigieren, Artikel entfernen und den Gesamtpreis verstehen können. Die Beispielannahme lautet: Umständliche Korrekturen und unklare Versandkosten erschweren den Checkout-Beginn. Reale Nutzerbelege sind in dieser Lerndemo nicht vorhanden; im Projekt prüft der Fachpartner die Annahme mit Nutzertests und Feedback.
Hypothese: Wenn Kunden Mengen einfach ändern und den Gesamtpreis verstehen, beginnen mehr geeignete Sitzungen mit gefülltem Warenkorb den Checkout. Beispiel-Ausgangswert: 58 %. Beispielziel: mindestens 62 % bei eingehaltenen Schutzgrenzen. Diese Zahlen sind erfundene Annahmen, keine Messwerte der Website. Für die erste Änderung: höchstens 5 Teamarbeitstage und 50 € KI-Kosten. Prüfpunkt bei halbem Verbrauch. Teamaufwand ist nicht Kalenderdauer. Im Muster ist dem PO die Entscheidung über Fortsetzung, Verkleinerung oder Stopp innerhalb dieses Rahmens übertragen. Ein größeres Budget oder ein geändertes strategisches Ziel bestätigt die zuständige Bereichsleitung.
Enthalten: Artikel hinzufügen, Mengen ändern, Positionen entfernen, Artikelwert und Versandkosten berechnen, Gesamtpreis anzeigen und leeren Checkout verhindern. Nicht enthalten: Rabattcodes, Merkliste, Gastkonto-Synchronisierung, Zahlung und echte Bestellabwicklung. Die Website bildet die Regeln lokal im Browser ab. Ein produktiver Warenkorb benötigt zusätzlich serverseitige Prüfungen, Zugriffsschutz, Betrieb und Freigaben. Die unten beschriebenen Anforderungen an einen echten Service sind nicht als vorhandene Website-Funktionen zu verstehen.
AK-01 · Hinzufügen: Ein vorhandener Artikel wird nicht als zweite Position angelegt. Gegeben Kaffee mit Menge 1, wenn derselbe Artikel erneut hinzugefügt wird, dann besteht eine Position mit Menge 2. AK-02 · Mengen: Zulässig sind ganze, nichtnegative Mengen. Menge 0 entfernt die Position. Negative und gebrochene Mengen werden abgewiesen; der bisherige Warenkorb bleibt unverändert. AK-03 · Bestand: Die gewünschte Menge darf den verfügbaren Bestand nicht überschreiten. Bei Bestand 5 wird Menge 6 abgewiesen und der Warenkorb nicht verändert. Menge 5 ist zulässig. AK-04 · Geld und Summen: Geld wird in ganzzahligen Cent berechnet. Artikelwert ist die Summe aus Menge × gültigem Einzelpreis. Gesamtpreis ist Artikelwert plus Versand. Nach erfolgreichem Hinzufügen, Ändern oder Entfernen werden die angezeigten Summen aktualisiert. Im echten Service sind serverseitige Preise maßgeblich. Beispiel: 2 × 1.490 Cent + 490 Cent Versand = 3.470 Cent. AK-05 · Versand: Bei einem nichtleeren Warenkorb unter 5.000 Cent Artikelwert betragen die Versandkosten 490 Cent. Ab genau 5.000 Cent sind sie 0. Grenzfälle: 4.999 → 490 Cent Versand; 5.000 → 0. Nach einer Mengenänderung über oder unter die Grenze gilt sofort die neue Summe. AK-06 · Leerzustand: Nach Entfernen des letzten Artikels sind Artikelwert, Versand und Gesamtpreis 0. Der Checkout ist gesperrt, der Leerzustand wird verständlich angezeigt. Ungültige Aktionen zeigen eine verständliche Rückmeldung und verändern weder Positionen noch Summen. Die Bestandsgrenzen gelten auch beim wiederholten Hinzufügen.
Entwurf: PUT /cart/items/{productId} Body: { "quantity": 2 } setzt die gewünschte absolute Menge. quantity: 0 entfernt die Position. Wiederholung derselben Setzoperation erhöht die Menge nicht zusätzlich; das Hinzufügen in der Oberfläche bestimmt die neue Zielmenge. 200: aktualisierter Warenkorb einschließlich serverseitiger Summen. 400: ungültige Menge. 404: unbekannter Artikel. 409: Bestand reicht nicht. Bei diesen Fehlern bleibt der Warenkorb unverändert. Der Service prüft Eingaben, aktuellen Preis, Bestand und Berechtigung auf den betroffenen Warenkorb. Eine Bestellung und Reservierung von Bestand werden durch diesen Vertrag nicht ausgelöst. Vor produktiver Umsetzung klärt das Team Authentifizierung, 401/403-Behandlung, parallele Änderungen, Transaktionsgrenzen und das konkrete Antwortschema. Diese offenen technischen Punkte sind kein stillschweigender Freiraum für Agenten. Sie blockieren den betroffenen Produktionsteil.
Tests referenzieren CART 1.0 und die jeweiligen AK-IDs. Ein Prüfer arbeitet mit demselben festgelegten Spec-Stand wie der umsetzende Agent. Automatisiert prüfen: wiederholtes Hinzufügen, Menge 0, negative und gebrochene Mengen, Bestand genau erreicht und überschritten, Cent-Berechnung, beide Seiten der Versandgrenze und leerer Checkout. Zustandswechsel prüfen: Nach jeder Aktion stimmen Positionen, Artikelwert, Versand und Gesamtpreis zusammen. Für eine echte Umsetzung zusätzlich: Schnittstellenfehler, unberechtigter Zugriff, aktuelle serverseitige Preise und parallele Änderungen nach bestätigtem Vertrag. Das Delivery Team erstellt Nachweise; ein menschlicher Reviewer prüft unabhängig. Der Feature Partner nimmt reale Einkaufsabläufe ab: Menge ändern, letzten Artikel entfernen, Bestand überschreiten und Versandgrenze wechseln. Abnahme protokolliert Spec-Stand, Code-Version, Prüffälle und Abweichungen. Schweigen ist keine Abnahme. Die ausführbaren Website-Prüffälle sind Lernhilfen und ersetzen keine Serverintegration, Sicherheitsprüfung oder fachliche Abnahme.
Primäre Kennzahl: geeignete Sitzungen mit Checkout-Beginn geteilt durch geeignete Sitzungen mit gefülltem Warenkorb. Testverkehr ausschließen und wiederholte Ereignisse je Sitzung nur einmal zählen. Messpunkte: erfolgreiche Mengenänderung, Warenkorbfehler und Beginn des Checkouts. Aktionen eindeutig zuordnen; keine personenbezogenen Freitexte erfassen. Beispiel-Messfenster: Tag 6–18 nach Aktivierung an Tag 5, Vergleichsgruppe und neue Variante. Je 1.000 Sitzungen sind nur eine illustrative Auswertungsgröße. Messpartner klärt Gruppenbildung, Vergleichbarkeit und benötigte Datenmenge vorab. Beispiel-Schutzgrenzen: Änderungsfehler höchstens 1 %, Ladezeit p95 höchstens 1,5 Sekunden. Preisbeschwerden und abgeschlossene Käufe zusätzlich beobachten; ihre Entscheidungsgrenzen müssen vor einem echten Experiment vereinbart werden. Am Tag 20 prüft der PO mit Team und Partnern die Scorecard. Er entscheidet im delegierten Rahmen und gibt die Befunde an die beauftragende Bereichsleitung zurück; strategische Änderungen entscheidet diese. Fehlende Daten oder ungeklärte Vergleichbarkeit führen zu weiterer Untersuchung statt automatischer Ausweitung. Dringende schädliche Befunde werden sofort behandelt. Die Scorecard mit fiktiven Ergebnissen steht unter https://loopswork.dev/docs/#scorecard. Die Website erhebt diese Shopdaten nicht.
Im Beispiel: Nach fachlicher Abnahme an Tag 5 nur mit vorliegenden Freigaben für eine begrenzte Nutzergruppe aktivieren. Das Release verknüpft CART 1.0, tatsächliche Code-Version, Testnachweise, Abnahme und Scorecard. Messdaten werden Release und Nutzergruppe zugeordnet. Team und Freigabeverantwortlicher prüfen Fehlerrate, Preisrichtigkeit und Datenerfassung. Bei fehlerhaften Preisen oder schädlichen Befunden wird die Aktivierung gestoppt und der vereinbarte Rücknahmeweg genutzt. Die konkrete Umschaltung, zuständige Person und Behandlung bereits veränderter Daten müssen vor einem echten Release geklärt und erprobt sein. Bei Rücknahme müssen Code, Konfiguration und zugehöriger Spec-Stand zusammenpassen.
Vor echter Umsetzung offen: Nutzerbelege (Fachpartner), Authentifizierung und Parallelzugriffe (Team), Vergleichsdesign und Schutzgrenzen (Messpartner), Freigabe- und Rücknahmeweg (Team und Freigabeverantwortlicher). Frist jeweils vor Umsetzung bzw. Start des betroffenen Teils; konkrete Namen und Termine im Projekt zuordnen. Version 1.0 dokumentiert die sechs bereits im Lernbeispiel vereinbarten Regeln. Diese ausgefüllte Fassung führt sie zusammen und erläutert ihre Anwendung; sie ändert die Versandgrenze nicht. KI-Aufträge, Tests, Review und Abnahme nennen CART 1.0 plus festen Commit- oder Dokumentversionsverweis. Eine fachliche Änderung wird als neuer Entwurf mit Unterschied, Grund, betroffenen AK-IDs und menschlicher Bestätigung geprüft. Laufende Aufträge werden auf Auswirkungen geprüft. Der auf der Beispielseite beschriebene Vorschlag CART 1.1 mit 6.000 Cent Versandgrenze ist hypothetisch und nicht Teil dieser Fassung. Bis zur ausdrücklichen Bestätigung einer neuen Vereinbarung gilt CART 1.0 mit 5.000 Cent.
Eigene Spec mit dem Lückentext erstellen · Regeln im Warenkorb-Beispiel erkunden
Small Specs brauchen auch Small PRs. Eine fachlich zusammenhängende Änderung mit Spec-Bezug und Evidence ist leichter zu prüfen als ein großer Sammel-PR.
PR-Review & Merge-Freigabe: Ablauf, Verantwortung und Prüfumfang →
Die Vorlage enthält die kurze Checkliste. Bei bedingten Punkten ist „nicht relevant“ mit kurzer Begründung möglich. Fehlende Nachweise und blockierende Befunde bleiben sichtbar.
PR · [Kurztitel] Zweck & Small Spec: [Warum? Link zur Spec mit gültiger Version] Änderung & Abgrenzung: [Was ändert sich? Was ausdrücklich nicht?] Risiko & betroffene Bereiche: [Mögliche Folgen, Schnittstellen, Daten, Berechtigungen] Evidence: [Durchgeführte Tests/Checks + Ergebnis + Link; Agenten-Review mit Befunden/Stand; nicht ausgeführte Checks benennen] Bekannte Einschränkungen & offene Punkte: [Befund, Blocker, Owner; oder keine bekannt] Betrieb & Rollback (falls relevant): [Monitoring, Alerts, Rücknahme und Wiederherstellung; sonst nicht relevant + Grund] Review & Merge-Freigabe: [Benannte menschliche Person im Delivery Team; geprüfter Commit/Stand, Entscheidung und Datum] REVIEW-CHECKLISTE Bedingte Punkte dürfen mit „nicht relevant“ und kurzer Begründung beantwortet werden. - [ ] Spec & Umfang: Erfüllt die Änderung die Spec und bleibt sie im vereinbarten Umfang? - [ ] Verständlichkeit & Architektur: Sind Aufbau, Wartbarkeit und Architektur der Änderung tragfähig? - [ ] Sicherheit & Datenzugriff: Sind Sicherheit, Datenzugriffe und Berechtigungen angemessen abgesichert? [geprüft / nicht relevant + Grund] - [ ] Tests & Fehlerfälle: Sind Tests und Checks aussagekräftig und relevante Fehlerfälle abgedeckt? - [ ] Schnittstellen & bestehende Funktionen: Sind Auswirkungen auf Schnittstellen und bestehende Funktionen geprüft? [geprüft / nicht relevant + Grund] - [ ] Betrieb & Rücknahme: Bei Betriebsrelevanz: Sind Monitoring, Alerting, Rollback und Wiederherstellung geklärt und nachgewiesen? [geprüft / nicht relevant + Grund] - [ ] Blockierende Befunde behoben und erneut geprüft; relevante Änderungen nach Freigabe erneut vorgelegt.
Die Feature Scorecard ist ein kompaktes Entscheidungsblatt für ein Feature oder Nutzenziel. Sie hält die erwartete Wirkung, den Messplan, Ergebnisse und die daraus abgeleitete Produktentscheidung zusammen. Sie bewertet die Wirkung einer Änderung, nicht die Leistung einzelner Personen.
In V1 und V2: Hypothese, Ausgangswert, Ziel, primäre Kennzahl, Schutzkennzahlen, Datenquellen und Vergleich vereinbaren. Messereignisse gehen in B3.
Ab B10/V3: Version und Nutzergruppe zuordnen, Erfassung prüfen und Ergebnisse ergänzen. Der Messpartner prüft Datenqualität und Unsicherheit.
In V4–V6 und im Value Review: PO, Team und Partner bewerten Nutzen und Nebenwirkungen. Entscheidung, Owner und nächster Prüfpunkt werden festgehalten.
Sämtliche Werte und Ziele unten sind erfundene Beispielannahmen. Diese Site erhebt keine Shopdaten.
| Feld | Eintrag |
|---|---|
| Bezug & Verantwortung | Spec CART 1.0 · Aktivierung an Tag 5 · PO entscheidet im delegierten Rahmen; Measurement Partner prüft Daten. |
| Hypothese | Wenn Kunden Mengen einfach ändern und den Gesamtpreis verstehen, beginnen mehr geeignete Sitzungen mit gefülltem Warenkorb den Checkout. |
| Primäre Kennzahl | Geeignete Sitzungen mit Checkout-Beginn ÷ geeignete Sitzungen mit gefülltem Warenkorb. Testverkehr ausschließen; wiederholte Events je Sitzung nur einmal zählen. |
| Ausgangswert & Ziel | Vergleichswert 58 %. Beispielziel: mindestens 62 % bei eingehaltenen Schutzgrenzen. Ausgangswert und Vergleichbarkeit vor Umsetzung prüfen. |
| Messplan | Tag 6–18: zeitgleiche Vergleichsgruppe und neue Variante, jeweils 1.000 geeignete Sitzungen als illustrative Auswertung. Gruppenbildung, Zuordnung und benötigte Datenmenge vorab durch den Messpartner prüfen; 1.000 ist kein allgemeiner Mindestwert. |
| Ergebnis | Vergleich: 580/1.000 = 58 %. Variante: 640/1.000 = 64 %. Unterschied: +6 Prozentpunkte. Noch kein Beleg für zusätzliche Käufe oder eine kausale Wirkung. |
| Schutzkennzahlen | Änderungsfehler: beispielhaft 0,6 %, Grenze ≤ 1 %. Ladezeit p95: 1,2 s, Grenze ≤ 1,5 s. Preisbeschwerden und abgeschlossene Käufe ergänzen; fehlen hier noch. |
| Unsicherheit | Randomisierung nicht belegt; Nutzergruppen könnten sich unterscheiden. Umsatz- und Beschwerdebefund fehlen. Zahlen allein reichen für eine Ausweitung nicht. |
| Entscheidung an Tag 20 | PO: begrenzte Variante beibehalten, noch nicht ausweiten. Messpartner klärt Vergleich und fehlende Befunde, Team ergänzt nötige Messpunkte; nächster Prüfpunkt in 5 Arbeitstagen. |
Die Scorecards werden vor dem Termin aktualisiert. Fehlende Daten führen zu einem Untersuchungsauftrag mit Owner und Frist. Dringende Fehler oder schädliche Nebenwirkungen werden sofort behandelt; sie warten nicht auf das Review.
Ablauf und Beteiligte ansehenFEATURE SCORECARD [ID] · Version [x] · Stand [Datum] Feature / Spec / Release: [Links und Versionen] Produktentscheidung im Mandat: [PO] · Übergeordnete Entscheidung / Auftraggeber: [Person oder Gremium] · Datenqualität: [Measurement Partner] Problem / Zielgruppe: [für wen soll was besser werden?] Hypothese: Wenn [Änderung], dann [Wirkung], weil [Annahme]. Primäre Kennzahl: [Definition inkl. Zähler, Nenner, Ausschlüsse] Ausgangswert / Quelle / Zeitraum: [Wert oder fehlt + Klärungsplan] Ziel und Entscheidungsregel: [vorab vereinbaren] Schutzkennzahlen: [Grenzen für Fehler, Geschwindigkeit, Beschwerden; relevante Fehlerrate, Latenz, Verfügbarkeit oder SLO-Verletzungen nur mit Einfluss auf Nutzer, Business-Wirkung oder Zuverlässigkeit] Messplan: [Ereignisse, Vergleich, Gruppen, Datenmenge, Zeitraum] Ergebnis / Nutzerfeedback: [Werte, Belege, Datenqualität] Unsicherheit / alternative Erklärungen: [offen benennen] Entscheidung + Grund: [beibehalten/ändern/ausweiten/untersuchen/zurücknehmen] Nächste Aktion / Owner / Prüftermin: [konkret] Value Review: regelmäßig alle 4 Wochen; dringende Befunde sofort behandeln.
Eine Arbeitskarte enthält gerade genug Klarheit, um eine begrenzte Aufgabe sicher abzuschließen. Kein eigener Feature-Pitch und keine neue Scorecard für jede Korrektur: Bei einem Bug wird das bestehende Sollverhalten wiederhergestellt und geprüft.
Den operativen Ablauf ansehen · Bugfix an Tag 8 im Gantt-Beispiel
OPERATIVE ARBEITSKARTE [ID] Typ: [Bugfix / kleiner Task / Support / Incident] Ist / Soll / Reproduktion: [konkreter Fall oder minimale Regel] Auswirkung / Dringlichkeit / Priorität: [Begründung] Verantwortlich: [Teammitglied] · Fachliche Rückmeldung: [Name] Zeit-/KI-Budget / WIP: [Grenzen, gegebenenfalls pausierte Arbeit] Betroffene Spec / Regel: [Link; bei Bedarf ergänzen] Prüffall / Regression: [vorher fehlschlagend, nachher bestanden] KI-Auftrag: [erlaubte Dateien/Tools, KI-Skill-Version, KI-Kontext] Review / Abnahme / Rücknahme: [risikogerechter Nachweis] Betriebskontrolle / Abschluss: [Sollzustand wiederhergestellt?] Reliability & Observability (optional): [bei kritischen Änderungen Monitoring, Alert-Auslöser und Fehlerverhalten; sonst kurz oder weglassen] Wiederholungsmuster für Learning: [Beleg, keine neue Pflichtzeremonie]
Ein wiederkehrender Befund wird zu einem begrenzten Versuch. Zusammenarbeit, Wartezeiten und Arbeitsbedingungen gehören ebenso dazu wie KI-Skills und die Auswahl des KI-Kontexts. Pro Versuch wird eine Veränderung untersucht.
KI-Skills und KI-Kontext erklärt · Prompt für den Lernbegleiter
LERNEXPERIMENT [ID] Beobachtung und Belege: [Nacharbeit, Wartezeit, Feedback] Ursachenhypothese: [Vermutung, alternative Erklärungen] Eine Veränderung: [Arbeitsweise ODER KI-Skill ODER KI-Kontext] Owner / Budget / Vergleichsfälle: [konkret] Erwarteter Nutzen / Gegenindikatoren: [vorab vereinbaren] Ergebnis: [Qualität, Nacharbeit, Prüfzeit, KI-Kosten, Unsicherheit] Entscheidung: [beibehalten/anpassen/verwerfen] Übernahme: [Version, Rücknahmeweg, nächster Prüftermin]
Direkt zu den vorhandenen Übersichten und Arbeitsgrundlagen.
B1–B10, V1–V6 und L1–L6 mit Nachweisen und Rückkopplungen.
LEITPLANKENDie bestehenden Prinzipien mit Erläuterungen und Beispielen.
VERANTWORTUNGAufträge, Entscheidungen, Grenzen und Beispiele.
TAGESGESCHÄFTSchlanke Vorlage für Bugs, Support und kleine Tasks.
LEARNINGEine Veränderung mit Nachweisen erproben.
EINORDNUNGFramework-Entwurf, technische Quellen und Grenzen der Beispiele.
Downloads und Kopierfunktionen verwenden dieselbe Quelle.
Vorlagen und Prompts: CC BY 4.0 · Christian Stiller / LoopsWork. Urheber nennen, Lizenz verlinken und Änderungen kennzeichnen. Lizenztext ↓
spec.md · pr.md · scorecard.md · cart.md · operation.md · experiment.md