TL;DR
User Stories, die in Miro oder Jira entstehen, wissen nicht, was in deiner Codebase steckt. Also setzt dein KI-Coding-Agent sie wörtlich um – und produziert generischen Code. Tekk.coach lässt das Canvas weg. Seine Loops lesen, was sich in deinem Code geändert hat, und schlagen Specs mit Akzeptanzkriterien vor; du gibst sie mit Greenlight frei oder schreibst eine von Hand. Dein Coding-Agent baut die Spec, und der gemergte PR schließt sie. Kein Workshop, keine Haftnotizen, keine manuelle Übertragung nach Jira.
So erzeugt Tekk.coach User Stories
Die meiste User-Story-Mapping-Software beginnt mit einem leeren Canvas. Du klebst Haftnotizen, ordnest Aktivitäten, ziehst Swimlanes, schreibst Akzeptanzkriterien. Dann muss jemand all das in Jira-Tickets übertragen. Dann interpretiert jemand aus dem Dev-Team – oder ein KI-Coding-Agent – die Tickets und schreibt Code. Bei jeder Übergabe geht Information verloren. Wie die Analyse der Nielsen Norman Group zum Story Mapping bestätigt, hilft die Methode Teams, den Überblick zu behalten und sich darauf zu einigen, was gebaut wird – aber die Map selbst enthält keine Implementierungsdetails. Wenn deine Story beim Code ankommt, sagt sie „man kann sich einloggen“, ohne jeden Kontext zu deiner Auth-Implementierung.
Tekk lässt das Canvas komplett weg. Du verbindest dein Repo, und sechzehn Loops – Security, Backend, Payments und der Rest – beobachten es. Ändert sich dein Code, wacht ein Loop auf, liest, was sich geändert hat, und verfolgt es bis zu dem, was davon berührt wird. Er baut ein echtes Verständnis dafür auf, was existiert, bevor er eine einzige Zeile Spec schreibt. Findet er etwas, das sich lohnt, bringt er dir ein Proposal.
Jede Spec hat Akzeptanzkriterien, und die Spec eines Loops zeigt auf die tatsächlichen Dateien und Muster aus deinem Repo. Nicht „man kann das eigene Passwort zurücksetzen“. Eher: „Die E-Mail zum Passwort-Reset wird über services/auth/emailService.ts ausgelöst, das Token im Model UserPasswordReset gespeichert, der Ablauf in middleware/auth.ts geprüft.“ Solche Akzeptanzkriterien kann ein KI-Coding-Agent ohne Raten umsetzen – derselbe Maßstab, den Spec-driven Development an jede Anforderung anlegt.
Du gibst das Proposal mit Greenlight frei, und es wird zur Spec auf deinem Board, oder du lehnst es mit Begründung ab, und die Loops lernen dazu. Weißt du genau, was gebaut werden soll? Schreib die Spec von Hand – dasselbe Board, dieselben Akzeptanzkriterien. Ist sie bereit, baut dein Coding-Agent – Claude Code, Codex oder Cursor – sie über den Tekk-MCP-Server, und der PR mit Closes TEK-123 schließt sie beim Merge ab.
Die wichtigsten Vorteile
Akzeptanzkriterien, die auf echten Code verweisen Die Spec eines Loops zeigt auf tatsächliche Dateien, Funktionen und Architekturmuster in deinem Repo. AI-Agents hören auf zu raten und bauen es richtig.
Keine manuelle Übertragung nach Jira Der Schritt vom Workshop zum Ticket ist der, an dem die Qualität der Stories stirbt. Loops schreiben Specs direkt aus deinem Code. Ein Schritt statt drei.
Akzeptanzkriterien, die die Arbeit schließen Jede Spec hat eine Checkliste für die Reihenfolge der Umsetzung. Der gemergte PR schließt die Spec erst ab, wenn die Checkliste erledigt ist – dieselbe Funktion wie der Release-Slice einer Story Map, durchgesetzt durch den Merge.
Gebaut für KI-Coding-Agents Claude Code, Codex und Cursor arbeiten das Board über den Tekk-MCP-Server ab. Die Qualität der Stories bestimmt die Code Quality. Um die Qualität der Stories kümmert sich Tekk.
Drei Tage testen Verbinde dein Repo, und die Loops starten bei deiner nächsten Änderung. Drei Loop-Läufe, um zu sehen, was sie finden; kein Sales-Call.
So funktioniert’s
Verbinde dein Repo. Schalte die Loops ein, die du willst. Sie lesen deinen Code, kein Canvas.
Ein Loop findet die Arbeit. Wenn sich dein Code ändert, wenn Sentry anschlägt oder wenn ein Teil seines Bereichs ungeprüft bleibt, wacht ein Loop auf, liest, was sich geändert hat, und bringt höchstens ein Proposal.
Mit Greenlight freigeben oder ablehnen. Freigegebene Proposals werden zu Specs. Abgelehnte bringen den Loops mit einer Begründung bei, was für dein Projekt Rauschen ist. Hier passiert die Abstimmung, für die es sonst einen Workshop braucht – schnell, asynchron, ohne Zoom-Call.
Oder schreib die Spec selbst. In einfacher Sprache. „Zwei-Faktor-Authentifizierung hinzufügen“ oder „das Billing-Modul so umbauen, dass es Jahrespläne unterstützt“. Sie landet auf demselben Board, mit denselben Akzeptanzkriterien und derselben Checkliste.
Dein Coding-Agent baut sie. Claude Code, Codex oder Cursor holt sich die Spec über MCP. Der PR mit
Closes TEK-123schließt sie beim Merge ab.
Für wen das ist
Solo Founder und kleine Dev-Teams (1–10 Leute) Du brauchst keinen moderierten Story-Mapping-Workshop. Du brauchst eine Spec, die du heute umsetzen kannst. Tekk ersetzt das Ritual durch Specs, die aus deinem Code geschrieben sind.
PMs und Devs, die mit KI-Coding-Agents arbeiten Wenn du Cursor, Claude Code oder Codex nutzt, ist die Qualität deiner Stories der Engpass. Generische „Als User möchte ich …“-Stories erzeugen generischen Code – und wie die Community-Recherche von Atlassian zu KI-generierten User Stories festhält, liefern die meisten KI-Story-Generatoren Output ohne Bezug zur Codebase, den Teams von Hand mit Implementierungskontext anreichern müssen. Tekks Loops schreiben Specs, die auf deiner tatsächlichen Architektur beruhen.
Teams, die die Übertragung von Miro nach Jira satthaben Du hast zwei Stunden lang Stories auf einem Whiteboard gemappt. Jetzt musst du sie als Tickets neu eingeben. Dann muss jemand Akzeptanzkriterien ergänzen. Dann fragt jemand aus dem Dev-Team, was „User können sich authentifizieren“ in deiner konkreten Codebase bedeutet. Tekk überspringt diese Übertragung.
Was ist User Story Mapping?
User Story Mapping ist eine Technik der Produktplanung, die Jeff Patton 2005 eingeführt hat. Die Grundidee: Nutzeraktivitäten horizontal anordnen (das „Backbone“ der Produkterfahrung) und jede Aktivität darunter in Stories aufteilen. Teams priorisieren Stories vertikal – die oberste Reihe jeder Aktivität bildet das Minimum Viable Product. Horizontale Swimlanes legen den Release-Scope fest.
Die Technik wurde zu einem Grundpfeiler agiler Produktentwicklung, weil sie ein echtes Problem löst: Flache Backlogs verlieren Kontext. Siehst du 200 Tickets in Jira, verlierst du den Faden, was die Leute eigentlich erreichen wollen. Eine Story Map stellt die Erzählung wieder her – wie Patton später in seinem O’Reilly-Buch User Story Mapping (2014) ausführte, hilft die Methode funktionsübergreifenden Teams aus Produkt, Design und Entwicklung, sich darauf zu einigen, was sie bauen und warum.
Der aktuelle Markt für User-Story-Mapping-Software teilt sich in drei Kategorien. Spezialisierte Tools wie StoriesOnBoard, FeatureMap und Avion bieten Mapping auf einem Canvas mit Jira- und GitHub-Integrationen. Whiteboard-Tools wie Miro, Mural und FigJam dienen für gemeinsame Discovery-Workshops. Jira-Add-ons wie Easy Agile TeamRhythm holen das Mapping ins Delivery-Tool. All diese Tools bedienen die Ebene von Discovery und Dokumentation. Keins davon bedient die Ebene der Codebase.
Diese Lücke zählt heute mehr als 2005. Da 87 % der agilen Teams Scrum nutzen und User Stories ihr wichtigstes Format für Anforderungen sind, betrifft die Trennung zwischen Story Maps und Codebases die meisten Softwareteams. KI-Coding-Agents setzen User Stories wörtlich um. „Als User möchte ich mein Passwort zurücksetzen“ sagt Claude Code nichts über deinen E-Mail-Service, dein Token-Model oder deine bestehende Auth-Middleware. Die Story Map hat dir geholfen, dich darauf festzulegen, was gebaut wird. Sie hilft deinem AI-Agent nicht zu verstehen, wie es in deiner konkreten Codebase zu bauen ist. KI-Projektplanung, die bei der Codebase beginnt statt bei einem leeren Canvas, schließt diese Lücke. Genau dieses Problem löst Tekk.