NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Gefächerte Karteikarten in Gelb Blau Grün Rot mit Schriftzug Example Mapping

Was ist Example Mapping?

Example Mapping ist eine Gesprächstechnik, mit der ein Team eine User Story in klare Regeln und konkrete Beispiele zerlegt, bevor die erste Codezeile entsteht. Vier Kartenfarben halten das Ergebnis fest: gelb für die Story, blau für die Regeln, grün für die Beispiele, rot für offene Fragen.
Die Technik stammt von Matt Wynne, Mitgründer von Cucumber, und wurde Ende 2015 veröffentlicht. Bei Cucumber selbst wird nach 25 Minuten per Daumenabstimmung entschieden, ob die Story reif für die Entwicklung ist. Jede grüne Karte illustriert genau eine blaue Regel. Ohne Beispiel bleibt eine Regel mehrdeutig, ohne Regel fehlt dem Beispiel der Zusammenhang.
2026 hat die Technik eine zweite Karriere bekommen. Was früher die Vorlage für einen Testfall war, ist heute die Vorlage für einen Prompt. Ein KI Coding Agent, der eine Regel und drei Beispiele bekommt, produziert etwas völlig anderes als einer, der eine vage Story bekommt. Example Mapping liefert genau den Kontext, an dem agentische Entwicklung sonst scheitert.
Inhalt

Example Mapping mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet seit über 20 Jahren mit Testautomatisierung und begleitet Teams beim Übergang von handgeschriebenem zu KI generiertem Code. Roland Golla ist Cypress Ambassador und moderiert seit 2018 Mob Programming Sessions, in denen Teams gemeinsam Testfälle formulieren. Genau dieses Handwerk steckt in Example Mapping: erst die Fachlichkeit klären, dann automatisieren. Unser eigener Stack läuft mit PHPUnit, PHPStan, Rector PHP und Cypress mit Cypress Cloud, dazu OpenCode mit Open Weight Modellen für die KI Seite.
Wenn dein Team Anforderungen sauber in Tests und Prompts übersetzen will, passen dazu mehrere Leistungen: das Vibe Coding Consulting für die strategische Begleitung, unsere Quality Gates für KI Code für die automatische Durchsetzung, die NCA PHP AI Coding Guidelines als Regelwerk im bestehenden Projekt, das Schema Based AI Coding für maschinenprüfbare Verträge sowie rules.md und AGENTS.md für die Regeldateien deiner Agenten.
Anforderungen sauber klären mit Never Code Alone
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum unklare Anforderungen bei KI Entwicklung teurer werden

Früher hat eine vage Story Zeit gekostet. Ein Entwickler las sie, stutzte, fragte nach. Der Rückfragemoment war die eingebaute Qualitätssicherung. Ein KI Coding Agent fragt nicht nach. Er füllt die Lücke mit einer Annahme und schreibt dazu Code, der sauber aussieht und an der Fachlichkeit vorbeigeht.
Der Schaden fällt später auf. Der Pull Request läuft durch, die Tests sind grün, weil der Agent die Tests zur eigenen Annahme geschrieben hat. Erst im Abnahmegespräch merkt jemand, dass die Regel anders gemeint war. Dann steht nicht eine Funktion zur Debatte, sondern eine ganze Struktur, die auf der falschen Annahme aufgebaut wurde.
Example Mapping schiebt diesen Moment nach vorn. Die Fragen, die der Agent nicht stellt, stellt das Team vorher. Rote Karten sind dabei kein Scheitern, sondern das eigentliche Ergebnis: Jede rote Karte ist ein Fehler, der nicht in den Code gewandert ist. Wie sich fehlende Klärung sonst niederschlägt, beschreiben wir unter technische Schulden durch Vibe Coding und blindes Iterieren.

Die vier Kartenfarben im Überblick

Die Farben sind keine Formalie, sie erzwingen eine Denkbewegung. Eine Regel ist abstrakt, ein Beispiel ist konkret. Wer beides auf dieselbe Karte schreibt, merkt nicht, dass ihm eines von beidem fehlt. Getrennte Karten machen die Lücke sichtbar.
Karte Inhalt Was daraus wird
Gelb: Story Die User Story als Überschrift der Karte Ticket, Branch, Scope der Änderung
Blau: Regel Ein Akzeptanzkriterium, abstrakt formuliert Testklasse, Abschnitt in der Spezifikation
Grün: Beispiel Ein konkreter Fall, der die Regel illustriert Einzelner Testfall, Prompt für den Agenten
Rot: Frage Offener Punkt, den im Raum niemand beantworten kann Klärung mit Fachbereich, neue Story

So läuft eine Session ab

Drei Rollen reichen: jemand aus dem Fachbereich, jemand aus der Entwicklung, jemand aus dem Testing. Mehr Leute machen die Runde nicht besser, nur langsamer. Der Ablauf ist immer gleich.
Story auf Gelb. Eine Karte, oben auf den Tisch. Wenn sich schon hier niemand auf einen Satz einigen kann, ist das die erste wichtige Erkenntnis.
Bekannte Regeln auf Blau. Alles, was als Akzeptanzkriterium schon feststeht, kommt quer unter die Story.
Beispiele auf Grün. Für jede Regel mindestens eines, senkrecht darunter. Wer für eine Regel kein Beispiel findet, hat vermutlich keine Regel, sondern einen Wunsch.
Fragen auf Rot. Sobald niemand im Raum eine Antwort hat, kommt der Punkt auf Rot und das Gespräch läuft weiter.
Nach 25 Minuten wird abgestimmt. Viele blaue Karten heißen: Die Story ist zu groß und muss geschnitten werden. Viele rote Karten heißen: Es fehlt Fachwissen, die Story ist noch nicht reif. Wenige Karten und alle nicken heißt: Los geht es.
Das Format funktioniert mit Papierkarten genauso wie remote in einem geteilten Dokument oder einem Whiteboard Tool. Wichtig ist nur, dass die vier Ebenen visuell getrennt bleiben.

Von der grünen Karte zum Test

Eine grüne Karte ist ein Testfall im Rohzustand. Der Schritt zum ausformulierten Test heißt in der BDD Welt Formulation. Aus dem Beispiel wird ein Szenario, aus dem Szenario ein automatisierter Test. Bei uns landet das je nach Ebene in PHPUnit, in Pytest oder in Cypress. Was danach entsteht, ist eine lebende Spezifikation, die bei jedem Lauf gegen die Realität geprüft wird.
Ein Beispiel für einen Warenkorb: Die blaue Regel lautet, ab 50 Euro Warenwert entfällt der Versand. Die grünen Karten dazu sind 49,99 Euro mit Versand, 50,00 Euro ohne Versand und ein Gutschein, der den Wert unter 50 Euro drückt. Die dritte Karte ist die interessante. Sie entsteht nur im Gespräch, nie beim stillen Lesen einer Story.
Genau diese dritte Karte ist der Grund, warum Example Mapping mehr bringt als ein sauber geschriebenes Ticket. Sie ist die Kante, an der Software später bricht.
Code: 
          
public function testVersandkostenfreiAb50Euro(): void
{
    $warenkorb = new Warenkorb();
    $warenkorb->addPosition(new Position('Artikel', 5000));

    self::assertSame(0, $warenkorb->getVersandkosten());
}

public function testGutscheinDruecktWertUnterSchwelle(): void
{
    $warenkorb = new Warenkorb();
    $warenkorb->addPosition(new Position('Artikel', 5000));
    $warenkorb->addGutschein(new Gutschein(500));

    self::assertSame(495, $warenkorb->getVersandkosten());
}
Der zweite Test ist die grüne Karte, die im Gespräch entstanden ist. Ohne Example Mapping hätte ihn niemand geschrieben, weil niemand die Frage gestellt hätte.

Example Mapping als Kontext für KI Coding Agents

Ein Coding Agent arbeitet mit dem, was im Context Window steht. Eine Story im Fließtext ist schlechter Kontext, weil sie Regeln und Beispiele vermischt und Annahmen offen lässt. Eine Example Map ist guter Kontext, weil sie beides sauber trennt und die Lücken benennt.
In der Praxis übergeben wir die blauen Regeln als Spezifikation und die grünen Beispiele als Abnahmekriterium. Der Agent bekommt keinen Freibrief, sondern eine Liste von Fällen, gegen die sein Ergebnis geprüft wird. Rote Karten gehen gar nicht erst an den Agenten. Was im Team ungeklärt ist, kann eine Maschine nicht klären, sie kann es nur überschreiben.
Der Prompt sieht dann nicht mehr aus wie eine Bitte, sondern wie ein Auftrag mit Prüfkriterien.
Code: 
          
Regel: Ab 50 Euro Warenwert entfaellt der Versand.

Beispiele, die gruen sein muessen:
- 49,99 Euro Warenwert -> Versandkosten werden berechnet
- 50,00 Euro Warenwert -> keine Versandkosten
- 50,00 Euro Warenwert minus 5 Euro Gutschein -> Versandkosten werden berechnet

Schreibe zuerst die Tests, dann die Implementierung.
Aendere keine Dateien ausserhalb src/Warenkorb und tests/Warenkorb.
Diese Form der Steuerung ist kein Sonderfall, sondern die Grundlage von Exact Coding. Wie du Regeln dauerhaft im Projekt verankerst, steht in unserem Beitrag zu rules.md und AGENTS.md, den Umgang mit begrenztem Kontext beschreibt das Context Window Management.

Wann Example Mapping passt und wann nicht

Die Technik lohnt sich, wenn Fachlichkeit im Spiel ist. Preisregeln, Berechtigungen, Rabattstaffeln, Fristen, alles mit Wenn und Aber. Dort sitzen die teuren Missverständnisse.
Sie lohnt sich nicht bei rein technischen Aufgaben. Ein Framework Update, eine Migration, ein Refactoring ohne Verhaltensänderung braucht keine Beispielkarten, sondern eine Testabdeckung, die vorher schon steht. Für diesen Fall gilt bei uns die umgekehrte Reihenfolge: erst Quality Gates, dann anfassen. Das beschreiben wir im AI Coding Refactoring.
Auch bei einem Prototyp ist der Aufwand falsch investiert. Wer in 30 Minuten ausprobiert, ob eine Idee trägt, braucht keine Regeln, sondern Tempo. Der Übergang von dieser Phase in echte Software ist eine eigene Disziplin, dazu passt unser Beitrag zum Einstieg ins Vibe Coding und die Enterprise Readiness.

Rules make natural fault lines for slicing your story.

Matt Wynne, Mitgründer von Cucumber und Erfinder von Example Mapping – via Introducing Example Mapping, cucumber.io

Was Wynne damit meint

Regeln sind die natürlichen Bruchkanten einer Story. Wer eine zu große Aufgabe schneiden muss, sucht nicht nach technischen Schichten, sondern nach den blauen Karten. Jede Regel kann für sich fertig werden, mit ihren eigenen Beispielen und ihren eigenen Tests. Für KI gestützte Entwicklung ist das doppelt wertvoll: Ein Agent, der eine Regel abarbeitet, bleibt überprüfbar. Einer, der eine ganze Story abarbeitet, wird zur Blackbox.

Aus der NCA Praxis: Beispiele schlagen Beschreibungen

Wir sehen bei Teams immer wieder dasselbe Muster. Die Story ist lang, sauber formuliert und trotzdem missverständlich. Sobald jemand fragt, was denn bei genau 50 Euro passiert, kippt die Diskussion. Beschreibungen erzeugen Zustimmung, Beispiele erzeugen Klarheit. Deshalb steht bei uns am Anfang jeder Beratung die Frage nach dem konkreten Fall, nicht nach der Regel.
Der zweite Effekt zeigt sich beim Testing. Teams, die Example Mapping machen, schreiben andere Tests. Nicht mehr, sondern gezieltere. Der Weg von der grünen Karte zum Testfall ist so kurz, dass die Ausrede keine Zeit für Tests von selbst verschwindet. Wie das Sicherheitsnetz darunter aussieht, beschreiben wir in der Code Qualität mit KI Agenten und in den Quality Gates für KI Code.
Weiterführend passen dazu unsere Beiträge zu Agentic Coding Patterns, zur BMAD Method, zum Vibe Coding Prompting, zu Faker für realistische Testdaten, zur Human Readiness und zu den Vibe Coding Risiken.
Wer tiefer in die Werkzeugkette will, findet Anschluss bei OpenSpec für Spec Driven Development, bei SwarmForge mit TDD Rollen, bei PHPSpec für Behavior Driven Development sowie beim Digitalen Zwilling. Für PHP Projekte greifen die NCA PHP AI Coding Guidelines, für gewachsene Codebasen das NCA Ruhr Refactoring Consulting und für den gesamten Überblick der Vibe Coding Hub mit den Vibe Coding Best Practices.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu Example Mapping

Die Fragen, die uns Teams beim Einstieg stellen, drehen sich fast immer um Aufwand, Rollen und den Übergang zu Tests und KI Agenten.
Was ist Example Mapping 2026 in einem Satz?

Example Mapping ist eine kurze Gesprächsrunde, in der ein Team eine User Story in Regeln, Beispiele und offene Fragen zerlegt und das Ergebnis auf vier Kartenfarben festhält. Gelb steht für die Story, blau für die Regeln, grün für die Beispiele, rot für die Fragen. Ziel ist eine Story, die alle gleich verstehen, bevor Code entsteht.

Warum ist Example Mapping 2026 wichtiger geworden?

Weil KI Coding Agents nicht nachfragen. Ein Entwickler stolpert über eine unklare Anforderung und meldet sich. Ein Agent füllt die Lücke mit einer Annahme und baut darauf auf. Example Mapping verlegt die Klärung nach vorn und liefert dem Agenten Regeln und Beispiele statt vager Prosa. Damit sinkt die Zahl der Korrekturschleifen deutlich.

Wie lange dauert eine Example Mapping Session 2026?

Bei Cucumber wird nach 25 Minuten per Daumenabstimmung entschieden, ob die Story reif ist. Diese Zeitgrenze hat sich bewährt. Sie zwingt zur Konzentration und verhindert, dass die Runde in eine Designdiskussion kippt. Braucht eine Story deutlich länger, ist das selbst schon das Ergebnis: Sie ist zu groß oder zu unklar.

Wer nimmt 2026 an einer Session teil?

Drei Perspektiven reichen und sind gleichzeitig Pflicht: Fachbereich, Entwicklung, Testing. Der Fachbereich kennt die Regel, die Entwicklung kennt die technischen Kanten, das Testing findet die Fälle, an die sonst niemand denkt. Größere Runden verlängern die Diskussion, ohne die Qualität der Karten zu verbessern.

Brauche ich 2026 noch Gherkin und Cucumber dafür?

Nein. Example Mapping ist unabhängig vom Testframework. Die grünen Karten lassen sich genauso in PHPUnit, Pytest, Vitest oder Cypress übersetzen wie in Gherkin Szenarien. Die Kartenrunde klärt die Fachlichkeit, die Werkzeugwahl kommt danach und richtet sich nach dem Stack des Projekts.

Was ist der Unterschied zwischen einer Regel und einem Beispiel?

Eine Regel ist abstrakt und gilt allgemein, etwa dass ab 50 Euro Warenwert der Versand entfällt. Ein Beispiel ist konkret und prüfbar, etwa dass bei 49,99 Euro Versandkosten anfallen. Jedes Beispiel illustriert genau eine Regel. Ohne Beispiel bleibt die Regel mehrdeutig, ohne Regel fehlt dem Beispiel der Zusammenhang.

Was mache ich mit den roten Karten?

Rote Karten bekommen einen Verantwortlichen und ein Datum, sonst verschwinden sie. Manche werden nach der Runde beantwortet und wandern dann als Regel oder Beispiel zurück in die Map. Andere entpuppen sich als eigene Story. Eine offene Frage darf nie stillschweigend in einen Prompt wandern, denn dort wird sie zur Annahme.

Funktioniert Example Mapping auch remote?

Ja. Papierkarten sind nicht die Methode, sie sind nur ein Medium. Ein geteiltes Dokument mit vier Ebenen, ein Whiteboard Tool oder eine Tabelle mit farbigen Zellen erfüllen denselben Zweck. Entscheidend ist, dass Story, Regeln, Beispiele und Fragen visuell getrennt bleiben und alle gleichzeitig darauf schauen.

Wie viele Beispiele braucht eine Regel?

So viele, wie es Kanten gibt. Meist reichen drei: der klare Fall, der Grenzfall und der Fall, der die Regel bricht. Wer für eine Regel gar kein Beispiel findet, hat wahrscheinlich keine Regel formuliert, sondern einen Wunsch. Wer zehn braucht, hat vermutlich zwei Regeln in eine Karte gepackt.

Wie übergebe ich eine Example Map an einen KI Agenten?

Die blauen Regeln gehen als Spezifikation in den Prompt, die grünen Beispiele als Abnahmekriterium. Dazu kommt eine klare Grenze, welche Dateien der Agent anfassen darf. Rote Karten bleiben draußen. Diese Struktur macht das Ergebnis prüfbar, weil jeder Fall entweder grün ist oder nicht.

Ersetzt Example Mapping die Spezifikation?

Nein, es ist die Vorstufe. Aus den Karten entsteht das, was danach dauerhaft gepflegt wird: Tests, eine Spezifikation je Änderung und Regeln in der AGENTS.md. Die Karten selbst sind flüchtig. Ihr Wert liegt im Gespräch, nicht im Artefakt, und deshalb lohnt es sich nicht, sie zu archivieren.

Passt Example Mapping zu Legacy Projekten?

Für neue Fachlichkeit ja, für reines Refactoring nein. Wer bestehendes Verhalten umbaut, braucht keine neuen Beispiele, sondern erst eine Testabdeckung, die das aktuelle Verhalten festhält. Bei NCA gilt in gewachsenen Codebasen immer dieselbe Reihenfolge: erst Quality Gates aufbauen, dann aufräumen, niemals umgekehrt.