Stories und Akzeptanzkriterien | kanman Dokumentation

Eine Story ist das Stück Arbeit, das kanman übernimmt: ein Issue in Ihrem Tracker, klein genug für einen Pull Request, mit Akzeptanzkriterien, die genau sagen, wann es fertig ist. kanman übernimmt nur Stories, die bereit sind, und belegt jede fertige Story gegen ihre Kriterien, bevor jemand den Code prüft.

Woher Stories kommen

Stories kommen aus zwei Quellen:

Ihr Tracker. Ein Issue im verbundenen Projekt wird zur Story auf der Team-Seite, sobald es für kanman markiert ist: Es trägt das Übernahme-Label (standardmäßig kanman) oder ist dem Konto zugewiesen, das in den Tracker-Einstellungen des Teams steht. Nicht markierte Issues erscheinen nie auf der Team-Seite.
Aufnahme. Beschreiben Sie eine Anforderung im Reiter Anforderungen des Teams (oder über Neue Anforderung auf der Team-Seite), oder erwähnen Sie kanman in einem Slack-Thread. kanman entwirft Stories, die Sie bearbeiten, freigeben oder ablehnen. Freigegebene Stories werden gesammelt in Ihren Tracker geschrieben, mit dem Übernahme-Label.

Zuerst wird sortiert

Jede Nachricht, die kanman in der Aufnahme erhält, wird genau einer von vier Arten zugeordnet:

Art	Was passiert
Antwort auf eine offene Entscheidung	Die Antwort wird auf diese Entscheidung angewendet
Statusfrage	kanman antwortet im Gespräch. Die Antwort wird nie ins Repository committet
Operative Bitte: das Team pausieren oder fortsetzen (nur Admins), einen Run abbrechen, eine Story vorziehen oder zurückstellen	kanman setzt sie um und bestätigt
Arbeitsauftrag	kanman entwirft Stories

Nur Arbeitsaufträge werden zu Stories. Eine Frage wie “Was blockiert SBX-12?” wird also nie zum Ticket. Ist eine Anforderung zu vage, stellt kanman zuerst bis zu drei Fragen; beantworten Sie sie auf der Seite der Anfrage, und kanman entwirft erneut.

Aufbau einer Story

Teil	Beschreibung
Titel und Kontext	Was und warum, in klaren Worten
Akzeptanzkriterien	Nummerierte Kriterien in der Form Given / When / Then
Demonstrate-Block	Ein konkreter, ausführbarer Weg, das Ergebnis zu zeigen. Pflicht
Testplan	Welche Tests die Änderung braucht, zum Beispiel “unit: CSV serializer”, “e2e: download flow”
Größe	`S`, `M` oder `L`. Stories der Größe L sollten vor dem Schreiben geteilt werden
Betroffene Bereiche	Pfade oder Module, die die Änderung berührt, zum Beispiel `src/invoices/**`
Offene Fragen	Alles, was noch unklar ist. Eine Story mit offenen Fragen ist nicht bereit
Serviceklasse	`standard`, `expedite`, `fixed_date` oder `maintenance`

Akzeptanzkriterien

Jedes Kriterium steht in der Form Given / When / Then und hat eine feste ID (ac-1, ac-2, …), die innerhalb der Story nie wiederverwendet wird:

ac-1  Given a customer with 3 invoices in March
      When they export March as CSV
      Then the file has 3 rows and the columns date,number,amount

Bei der Prüfung bekommt jedes Kriterium einen Status: pending, passed, failed oder unknown. Ein bestandenes Kriterium trägt einen Nachweis: Datei und Zeile, die es umsetzen. Diese Tabelle sehen Sie im Nachweispaket.

Der Demonstrate-Block

Der Demonstrate-Block sagt, woran ein Mensch sieht, dass die Story funktioniert. Er schließt die Akzeptanzkriterien ab und ist für jede Story Pflicht. Er besteht aus Art, Schritten und erwartetem Ergebnis:

Feld	Werte
Art	`ui`, `api`, `cli` oder `config`
Schritte	Was in welcher Reihenfolge zu tun ist
Erwartet	Was Sie sehen, wenn es funktioniert

Ein guter Demonstrate-Block:

Kind:     ui
Steps:    open /invoices, pick 2026-03-01 to 2026-03-31, click "Download CSV"
Expected: a CSV downloads with the columns date,number,amount

“Tests sind grün” ist kein Demonstrate-Block, denn es nennt kein Ergebnis, das ein Mensch prüfen könnte. Eine Story ohne Demonstrate-Block zeigt in der Aufnahme Demonstrate-Schritt hinzufügen und kann nicht freigegeben werden.

Screenshot folgt Story-Seite mit Akzeptanzkriterien, dem Demonstrate-Block und dem Spec-Status 'rot (erwartet)'

Bereitschaft

Jede Story bekommt einen Bereitschaftswert von 0 bis 100 aus fünf Prüfungen:

Prüfung	Bestanden, wenn
Klare Akzeptanzkriterien	Es gibt mindestens ein Kriterium, und jedes hat ein Given, ein When und ein Then
Testbar	Die Story hat einen Testplan, und jedes Kriterium hat ein beobachtbares Then
Klein	Die Größe ist S oder M
Keine offenen Fragen	Die Liste der offenen Fragen ist leer
Demonstrate vorhanden	Der Demonstrate-Block hat Schritte und ein erwartetes Ergebnis

Jede Prüfung zählt 20 Punkte. Bei 100 zeigt die Story Bereit für kanman; nur solche Stories können in der Aufnahme freigegeben und in den Tracker geschrieben werden.

Die Akzeptanz-Spec

Hat Ihr Repository ein Akzeptanz-Manifest, geht kanman vor Ready noch einen Schritt weiter. Es schreibt aus dem Demonstrate-Block eine ausführbare Akzeptanz-Spec auf einen geschützten Pfad in Ihrem Repository (.kanman/acceptance/SBX-12/) und führt sie aus. Die Story wandert erst nach Ready, wenn die Spec läuft und aktuell fehlschlägt: Eine Spec, die schon vorher grün ist, testet das neue Verhalten nicht. Die Story-Seite zeigt den Spec-Status:

Status	Bedeutung
`missing`	Noch keine Spec. Angezeigt als Spec: noch nicht geschrieben
`authored`	Geschrieben, noch nicht ausgeführt
`red`	Läuft und schlägt fehl, wie vor der Änderung erwartet. Angezeigt als Spec: rot (erwartet)
`green`	Besteht, nach der Änderung
`invalid`	Abgelehnt, angezeigt als Spec: muss korrigiert werden, mit einem Grund wie “Spec besteht schon vor der Umsetzung und testet das neue Verhalten nicht” oder “Spec mockt ihr eigenes Ziel: Route-Interception von /api/invoices”

Die Einzelheiten stehen unter Das Outcome-Gate und Nachweise.

Stories teilen

kanman hält Stories klein, statt Checklisten in ihnen zu führen. Entwirft kanman eine große Anforderung, schreibt es mehrere Stories, jede mit eigenen Kriterien und eigenem Demonstrate-Block. Eine Story der Größe L besteht die Bereitschaftsprüfung nicht; teilen Sie sie in der Aufnahme, bevor Sie sie freigeben.

Kommt in einem späteren Release

Dass kanman Stories selbst als NOTIFY-Aktion teilt, mit einem einzeiligen Hinweis, den Sie rückgängig machen können, kommt in einem späteren Release. Wenn Sie Teilungen dann vorher freigeben möchten, heben Sie split_story in der Richtlinie auf ESCALATE an (siehe Befugnisstufen).

Der Testplan ersetzt die frühere Unteraufgaben-Checkliste: Er nennt die konkreten Prüfungen, die die Änderung braucht, und das Nachweispaket des Runs zeigt, welche davon gelaufen sind.

Serviceklassen und Komplexität

Zwei Einordnungen steuern, wie eine Story behandelt wird:

Die Serviceklasse bestimmt die Dringlichkeit. Arbeit mit expedite (zum Beispiel eine CI-Regression, ein Ausfall oder ein Sicherheitsfix) wird nie durch Budgets, Arbeitszeiten oder die Parallelitätsgrenze gestoppt. fixed_date, standard und maintenance folgen den normalen Regeln. Um eine Story vorzuziehen, bitten Sie im Reiter Anforderungen des Teams darum, zum Beispiel “SBX-12 vorziehen”; “SBX-12 zurückstellen” setzt sie auf Standard zurück. Kritische Wartungsfunde werden automatisch als expedite angelegt.
Die Komplexität (trivial, routine oder complex) folgt aus der Story-Größe: S ist trivial, M routine, L complex. Sie wählt die Modellstufe, das Turn-Budget und wie viel Planung ein Run macht. Komplexe Stories bekommen mehrere bewertete Lösungsansätze vor dem Plan. Siehe Runs.