Stories und Akzeptanzkriterien

Eine Story ist das Stück Arbeit, das kanman übernimmt: ein Issue in deinem 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 jede Änderung von kanman besteht deine CI und ein unabhängiges Review gegen die Kriterien, bevor sie gemergt wird.

Woher Stories kommen

Stories kommen aus zwei Quellen:

• Dein 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. Beschreib kanman eine Anforderung in der Unterhaltung (mit N beginnst du mit dem Team, das du gerade ansiehst), oder frag kanman in Slack oder Microsoft Teams (siehe Mit kanman in Slack und Microsoft Teams arbeiten). kanman entwirft Stories und zeigt sie als Karte, auf der du sie freigibst oder ablehnst; Review öffnen öffnet eine Seite, um sie vorher zu bearbeiten. Freigegebene Stories werden gesammelt in deinen Tracker geschrieben, mit dem Übernahme-Label. Ihren Schlüssel (zum Beispiel SBX-12) erhält eine Story bei der Freigabe, abgelehnte Entwürfe hinterlassen also keine Lücken in der Nummerierung.

Zuerst wird sortiert

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

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; beantworte sie auf der Seite der Anfrage, und kanman entwirft erneut.

Warum es eine Story gibt

Direkt unter ihrem Titel sagt jede Story in einem Satz, warum es sie gibt. Was der Satz nennt, ist verlinkt. Zum Beispiel:

Von kanman am 23. Okt. angelegt, weil develop von flow_object_cody rot wurde (Pipeline 894405) und zwei Läufe lang rot blieb.

Teil des Ziels „Connectoren wiederholen nie einen Schreibvorgang beim Anbieter“, freigegeben von Jana am 21. Okt.

Gewünscht von Marco am 22. Okt.: „Bitte einen CSV-Export der Rechnungen“.

Übernommen aus dem Tracker-Issue FM-912.

kanman schreibt den Satz, wenn es eine Story anlegt oder übernimmt, in der Chat-Sprache deines Teams. Jede Story, jedes Ziel, jede Nachricht, Pipeline, jeder Merge Request, Befund und jedes Tracker-Issue, das er nennt, wird vor dem Speichern mit dem echten Datensatz abgeglichen, damit jeder Link öffnet, was er nennt. Personen werden genannt, nicht verlinkt. Hat kanman für eine Story noch keinen Satz geschrieben, bildet die Seite einen aus dem, was über die Story schon bekannt ist, etwa deiner Anfrage, dem Tracker-Issue, dem Ziel oder dem, was kanman beim Anlegen festgehalten hat. kanman ersetzt ihn durch seinen eigenen, wenn es das nächste Mal an der Story arbeitet.

Eine Story kann kommen aus:

Der Verlauf unten auf der Seite listet weiterhin jede Änderung.

kanman fügt nie selbst Umfang hinzu

kanman baut nur, worum eine Person gebeten hat. Eine Story, deren Umfang niemand bestätigt hat, kommt nie nach Ready und startet nie:

• eine Anfrage, die kanman in eigenen Worten zu einer Funktion gemacht hat, bis du den Entwurf freigibst;
• etwas, das kanman selbst vorgeschlagen hat, etwa eine Folgearbeit;
• ein Teil einer solchen Story nach einer Teilung;
• eine Story, die der Plan eines Ziels hinzugefügt hat, außer eine Person hat diesen Plan freigegeben.

Diese Stories zeigen auf dem Board Wartet auf ein Ja. kanman fragt die Person, die die Anfrage gestellt hat (oder die verantwortliche Person des Teams), einmal pro Anfrage: „Darf ich das so bauen, wie ich es entworfen habe?“ mit Ja, so bauen, Erst bearbeiten und Verwerfen. Die Frage kommt zu deinen anderen Fragen an einem Ort (siehe Fragen von kanman). Du kannst auch direkt auf der Story Ja sagen oder sie selbst nach Ready verschieben: Auch das ist dein Ja. Verwerfen schließt die Story als nicht umzusetzen; nichts wird gelöscht.

Entwürfe, die zu deinem Team passen

kanman entwirft für das Team, das du tatsächlich hast. Bevor ein Entwurf dich erreicht, prüft kanman ihn gegen die Werkzeuge deines Teams (Code-Host, wo die Arbeit verfolgt wird, Chat) und gegen das, was kanman für das Team schon erledigt, etwa den Wartungs-Scan oder die Beobachtung deiner Pipelines. Ein Entwurf, der ein Werkzeug nennt, das dein Team nicht nutzt („GitHub-Issues anlegen“ für ein Team auf GitLab, das seine Arbeit auf dem kanman-Board verfolgt), oder der etwas baut, das kanman schon erledigt (eine Abhängigkeitsprüfung, einen Lockfile-Check, einen Link-Checker), wird einmal neu entworfen. Passt er dann immer noch nicht, legt kanman nichts an und stellt dir stattdessen eine Frage, zum Beispiel: „Mein Wartungs-Scan sucht schon danach. Soll ich ihn starten? Schreib ‘starte den Scan’.“ Wenn du ein solches Werkzeug wirklich gebaut haben willst, sag es in deiner Anfrage („bau einen Lockfile-Check in unsere Pipeline“), dann entwirft kanman es. Dieselbe Prüfung gilt für die Stories, die der Plan eines Ziels vorschlägt: Ein Schritt, der ein Werkzeug nennt, das dein Team nicht nutzt, bleibt aus dem Plan.

Findet kanman Entwürfe einer früheren Anfrage, die so danebenliegen, sagt es das der Person, die gefragt hat, einmal pro Anfrage: „Ich habe deine Anfrage falsch verstanden. Darf ich sie verwerfen und stattdessen den Wartungs-Scan starten?“ mit Verwerfen und stattdessen scannen, Erst bearbeiten und Ja, so bauen. Verwerfen schließt sie als nicht umzusetzen (nichts wird gelöscht) und startet den Scan; was er findet, landet zur Prüfung auf dem Board.

Arbeit mit einem klaren Auslöser läuft ohne Rückfrage weiter, innerhalb der Grenzen des Teams: fehlschlagende Pipelines, Sicherheits- und Abhängigkeits-Updates, Stories, die eine Person geschrieben, freigegeben oder nach Ready verschoben hat, Teile solcher Stories, Issues aus deinem Tracker und Stories in einem Ziel, dessen Plan eine Person freigegeben hat.

Eine Story lesen

Eine Story-Seite beantwortet die Fragen, die du meist hast, in dieser Reihenfolge:

1. Was ist das, und warum? Der Titel, der Satz, warum es die Story gibt, und die Beschreibung. Eine lange Beschreibung klappt nach ein paar Zeilen ein; mit Mehr zeigen liest du alles. Mit Bearbeiten änderst du Titel und Kurzbeschreibung.
2. Wo steht sie? Eine kurze Karte nennt zuerst, was dich braucht, etwa eine Frage von kanman mit Antworten oder auf wen die Story seit wann wartet. Sonst nennt sie den Stand in einem Satz, etwa „Im Review: Die Änderung ist gemacht und wird geprüft.“, und das Neueste, was passiert ist.
3. Ist sie fertig? Fertig, wenn listet die Akzeptanzkriterien mit ihrem Ergebnis (bestanden, fehlgeschlagen, unklar oder offen) und wie viele erfüllt sind. Darunter stehen die Merge Requests, Pipelines und Commits, die die Story geliefert haben, der Plan und deine To-dos. Mit Kriterien bearbeiten änderst du sie.
4. Was ist passiert? Die neuesten Einträge im Log der Story, mit Mehr zeigen der Rest. Danach folgen Kommentare und der vollständige Verlauf.

Größe, Serviceklasse, Labels, Testplan und Annahmen stehen unter Details: auf einem breiten Bildschirm als Spalte rechts, auf dem Telefon als Bereich zum Aufklappen. Wähle einen Wert, um ihn zu ändern. Seltenere Aktionen wie Mit kanman verfeinern, In Claude Code bearbeiten, das Issue in deinem Tracker und Ohne Lieferung schließen findest du im Menü … oben rechts.

Aufbau einer Story

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

Bevor eine Änderung gemergt wird, prüft ein unabhängiger Reviewer sie gegen jedes Kriterium, und die Checkliste der Story zeigt, welche Kriterien erfüllt sind. Siehe So prüft kanman seine Arbeit.

Kriterien während der Arbeit ändern

Manchmal zeigt sich während der Arbeit, dass ein Kriterium selbst nicht stimmte, zum Beispiel eine Ladezeitgrenze von 2,5 s, die nicht erreichbar ist, weil die Messung die Weiterleitung über deine Firmenanmeldung (Single Sign-on) enthält.

Bearbeite das Kriterium an der Story und schreib den Grund in die Notizen der Story. kanman liest die Änderung, wenn es das nächste Mal auf das Board schaut, passt die laufende Arbeit an, und der Reviewer prüft die Änderung gegen die Kriterien, wie sie jetzt sind. Die Änderung wird mit der Person und dem Zeitpunkt festgehalten.

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. Der Reviewer beurteilt damit, ob die Änderung tut, was verlangt war. Er besteht aus Art, Schritten und erwartetem Ergebnis:

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 im Review der Entwürfe Demonstrate-Schritt hinzufügen und kann nicht freigegeben werden.

Bereitschaft

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

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

Annahmen und offene Fragen

kanman fragt dich nicht nach dem, was es selbst herausfinden kann. Design- und Code-Details, etwa welches Element eine Linie trägt, welches Farb-Token oder welche Klasse passt oder wohin eine Änderung gehört, legt es anhand deines Repositorys und seiner Konventionen fest und schreibt jede Entscheidung unter Meine Annahmen auf. Es fragt nur, was ein Mensch entscheiden muss: Umfang, fachliche Absicht oder eine Abwägung, die es nicht ableiten kann. Jede Frage zeigt, ob sie Blockiert die Freigabe, und oft, was kanman nehmen würde (“Ich würde nehmen: …”).

Jede offene Frage hat drei Aktionen, in der Entwurfskarte im Gespräch, oben in jedem Entwurf der Prüfseite und auf der Story-Seite:

Geklärte Fragen bleiben unter Geklärte Fragen an der Story, mit der Antwort oder kanmans Wahl. Du kannst auch im Chat antworten; siehe Fragen von kanman beantworten.

Wenn du bei einer Story, die noch nicht bereit ist, auf Freigeben (auf der Prüfseite Genehmigen) klickst, sagt kanman, warum (“1 Frage blockiert die Freigabe. Beantworte sie zuerst.”) und bringt dich zur ersten blockierenden Frage. Inhaber und Admins des Workspaces können Mit offenen Fragen freigeben wählen, wenn nur noch Fragen eine Story aufhalten: Die Fragen bleiben als Notizen an der Story, die Freigabe steht im Audit-Log, und das Tracker-Issue führt sie unter Offene Fragen auf. Das Tracker-Issue nennt auch die Annahmen und die beantworteten Fragen, damit jeder, der die Story übernimmt, sieht, worauf sie sich stützt.

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; teile sie im Review der Entwürfe, bevor du sie freigibst.

kanman teilt große Stories auch selbst, wenn es die Arbeit plant: Eine Story der Größe L wird zu kleineren Stories, jede mit ihrem Anteil der Kriterien, und kanman sagt das in den Notizen der Story und im Aktivitätsprotokoll. Teile einer Story, zu der niemand Ja gesagt hat, warten wie die Story selbst auf ein Ja (siehe kanman fügt nie selbst Umfang hinzu), und Entwürfe, die du nicht freigegeben hast, Stories, die auf ein Ja warten, und Entwürfe, die nicht zu deinem Team passten, teilt kanman nie.

Der Testplan nennt die konkreten Prüfungen, die die Änderung braucht; der Reviewer prüft, dass die Änderung sie hat.

Wenn kanman lieber noch nicht anfängt

kanman beginnt nicht jede Story, die es bekommt. Ist eine Story vage, zu groß, riskant oder kollidiert sie mit anderer Arbeit, sagt kanman das, bevor die Arbeit beginnt: „Ich würde das lieber noch nicht anfangen, weil …“, und macht statt der Arbeit einen konkreten Vorschlag.

Du liest dieselben Worte überall, wo kanman über die Story spricht: in seiner Antwort in der Unterhaltung, in Slack und Microsoft Teams, in seinen Antworten auf Tracker-Issues und Pull Requests, an jedem Entwurf in der Entwurfskarte und im Review sowie auf der Story-Seite. Es ist eine Empfehlung, keine Sperre: Du entscheidest, zum Beispiel indem du den Entwurf teilst oder ihn so freigibst.

Schätzungen und was kanman nicht sicher weiß

Jede entworfene Story trägt eine Schätzung: ihre Größe, eine Aufwandsspanne und wie sicher kanman ist, mit einer kurzen Begründung, zum Beispiel Größe M · etwa 1–2 Tage · einigermaßen sicher: 3 Kriterien, betrifft den Rechnungsexport. kanman klingt nie sicherer, als die Fakten erlauben: offene Fragen, riskanter Boden oder mehrere Unbekannte senken die Sicherheit.

Unter Wobei ich nicht sicher bin listet kanman, was es nicht klären konnte, jeweils mit dem Grund und dem, was es klären würde: „Ich bin nicht sicher, welchen Mandanten der Export verwendet, weil die Story es nicht sagt. Klären würde es: ein Blick in die Mandantenkonfiguration.“ Dieselbe Liste geht in den Plan, den kanman schreibt, bevor es Code ändert, und der Plan endet mit dem, worüber kanman noch unsicher ist.

Unter Nah an anderer Arbeit nennt die Story die offenen Stories, Runs und Pull- oder Merge-Requests, mit denen sie sich überschneidet, und die Dateien, die sie teilen. Wo dein Tracker seine offenen Issues auflisten kann, vergleicht kanman auch mit diesen, sonst mit den Stories auf dem Board.

Bevor die Arbeit beginnt

Zwischen Entwurf und Start geht die Arbeit weiter. Bevor kanman eine Story beginnt, schaut es, was sonst in Arbeit ist. Ändert andere Arbeit dieselben Dateien, oder ist eine andere Story dieselbe Arbeit, ordnet kanman sie so, dass sie sich nicht in die Quere kommen, oder verknüpft das Duplikat, und sagt das im Aktivitätsprotokoll.

Wer an einer Story arbeitet

An einer Story arbeitet kanman, arbeiten Menschen, oder beide zusammen. Die Avatare unten auf der Karte im Board zeigen, wer dabei ist: kanmans Avatar mit dem kleinen Bot-Abzeichen, deine Kolleginnen und Kollegen mit ihren, und +2, wenn mehr Personen zugewiesen sind. Die Zahl neben der Sprechblase zählt die Notizen der Story.

• Niemand zugewiesen oder kanman zugewiesen: kanman bearbeitet die Story, sobald sie in Ready ist, wie gewohnt.
• Eine Person zugewiesen: Diese Person bearbeitet sie. kanman beginnt keine Arbeit daran und hilft stattdessen: Es antwortet in den Notizen der Story und hält das Board aktuell. Entferne die Person, oder füge kanman hinzu und entferne dich selbst, um die Story zurückzugeben; sobald sie in Ready ist, übernimmt kanman.

Um zu ändern, wer an einer Story arbeitet, öffne sie und wähle oben rechts die Avatare (oder Zuweisen). Wähle Mir zuweisen, kanman oder ein Mitglied deines Workspaces; die Zeile unter der Liste sagt, was deine Wahl für kanman bedeutet. Eigentümer, Admins und Mitglieder können zuweisen; Betrachter sehen, wer zugewiesen ist. Zugewiesene Personen werden benachrichtigt. Aus Claude Code oder Codex nutzt du assign_story.

Labels und der Board-Filter

Labels ordnen Stories und Ziele auf einen Blick. Sie erscheinen als farbige Chips oben auf der Karte im Board. Jedes Team hat eigene Labels:

• An einer Story öffnest du Details und wählst Label hinzufügen (oder die Chips), hakst passende Labels an oder tippst einen neuen Namen und wählst Label anlegen. Neue Labels bekommen die nächste freie Farbe.
• An einem Ziel öffnest du Details auf der Seite des Ziels.
• Für das ganze Team benennst du Labels unter Team > Team > Labels um, wählst eine von acht Farben oder löschst sie. Ein gelöschtes Label verschwindet von allen Stories und Zielen.

kanman vergibt beim Entwerfen von Stories Labels aus deinem Team, nur wenn eines eindeutig passt. Es erfindet nie neue Labels. Eigentümer, Admins und Mitglieder vergeben und entfernen Labels; Betrachter sehen sie.

Filtern oben rechts im Board zeigt nur Stories bestimmter Personen (du, jemand aus dem Team oder kanman) oder mit bestimmten Labels. Mehrere Personen oder mehrere Labels erweitern den Filter, beides zusammen grenzt ein; die Karte eines Ziels bleibt, wenn seine Labels oder eine seiner Stories passen. Filter löschen zeigt wieder alles.

Checkliste

Die Checkliste einer Story zeigt, wie weit sie ist: auf der Story-Seite unter Fertig, wenn und als dünner Balken mit „3/7“ auf ihrer Karte im Board. Sie hat drei Teile, und keiner lässt sich abhaken, nur weil es jemand behauptet:

• Akzeptanzkriterien gelten als erfüllt, wenn kanmans Prüfungen sie bestehen: deine CI und das unabhängige Review.
• Plan: die Schritte des Plans, nach dem kanman arbeitet. Ein Schritt ist erst abgehakt, wenn eine von kanmans Prüfungen ihn belegt hat (die Prüfung steht neben dem Schritt), nicht wenn das Coding-Werkzeug ihn für erledigt erklärt.
• To-dos: deine eigenen Punkte. Füge sie hinzu, hak sie ab oder entferne sie, auch während kanman an der Story arbeitet.

Die Checkliste zeigt den Fortschritt. Ob eine Änderung gemergt wird, entscheiden weiterhin deine CI und das unabhängige Review.

Notizen und Übergaben

Jede Story und jedes Ziel hat Notizen: ein Gespräch in Threads, unter Kommentare auf der Story-Seite und unter Details > Notizen auf der Seite eines Ziels. Antworte auf eine Notiz, damit ein Thread zusammenbleibt.

• Personen erwähnst du mit @ und dem Namen, um eine Notiz an sie zu richten; die Notiz bleibt im Thread der Story oder des Ziels für alle lesbar. kanman sagt jeder erwähnten Person in ihrem Chat mit dem Team Bescheid (in Persönlich bei Notizen außerhalb eines Teams), mit einem Link zur Story oder zum Ziel.
• kanman erwähnst du mit @kanman. kanman liest den Thread und antwortet darin, meist innerhalb weniger Minuten. Es antwortet auch, wenn du in einem Thread antwortest, den kanman begonnen hat, oder an einer Story schreibst, die kanman zugewiesen ist.
• kanman schreibt auch in die Notizen. Während es an einer Story arbeitet, notiert es, was es tut, und übergibt Schritte, die einen Menschen brauchen, und eine Frage an dich erscheint im Verlauf der Story mit Antworten, das die in deinem Chat angeheftete Frage öffnet.

kanman übergibt Arbeit über die Zuweisung der Story hin und her. Wenn der nächste Schritt deiner ist (zum Beispiel Testkonten bei Anbietern für einige Konnektoren anlegen), bereitet kanman eine Story vor, die auflistet, was nötig ist, weist sie dir zu und schreibt in die Notizen, was zu tun ist. Wenn du fertig bist, schreib „@kanman erledigt“ in die Notizen (und hinterlege Geheimnisse unter den Run-Secrets des Teams). kanman prüft die Story, übernimmt sie wieder und setzt die Arbeit fort, die darauf gewartet hat.

kanman handelt auf Notizen von Eigentümern, Admins und Mitgliedern. Notizen von Betrachtern liest es, folgt ihnen aber nie.

Eine Story ohne Lieferung schließen

Manchmal wird eine Story nicht eigenständig geliefert: Eine andere Story deckt sie bereits ab, sie ist ein Duplikat, oder dein Team entscheidet, sie nicht umzusetzen. Würdest du sie nach Done ziehen, zählte sie als geliefert. Owner und Admins schließen sie stattdessen:

1. Öffne auf der Story-Seite das Menü … oben rechts und wähle Ohne Lieferung schließen.
2. Wähle den Grund: Eine andere Story deckt sie ab, Sie ist ein Duplikat einer anderen Story oder Wir setzen sie nicht um. Bei den ersten beiden wählst du die Story desselben Teams, die sie abdeckt.
3. Ergänze bei Bedarf eine Notiz und wähle Story schließen.

kanman verschiebt die Story nach Done, verknüpft sie mit der abdeckenden Story, schließt ihre offenen Fragen und hält im Audit-Log fest, wer sie warum geschlossen hat. Die Story-Seite zeigt Geschlossen, nicht geliefert mit dem Grund und einem Link zur abdeckenden Story, die Karte auf dem Board ein gestricheltes Label Nicht geliefert. Der Wochenbericht zählt die Story nicht als geliefert. Mit Wieder öffnen auf der Story-Seite holst du die Story zurück ins Backlog.

Genauso kann kanman eine Wartungs-Story schließen, wenn ein späterer Scan nicht mehr findet, worum es in ihr ging. Ihr Grund ist Nicht mehr zutreffend. Siehe Was mit den Funden passiert.

Serviceklassen

Die Serviceklasse bestimmt die Dringlichkeit. Arbeit mit expedite (zum Beispiel eine CI-Regression, ein Ausfall oder ein Sicherheitsfix) kommt zuerst. fixed_date, standard und maintenance folgen den normalen Regeln. Um eine Story vorzuziehen, bitte kanman in der Unterhaltung darum, zum Beispiel “SBX-12 vorziehen”; “SBX-12 zurückstellen” setzt sie auf Standard zurück. Kritische Wartungsfunde werden automatisch als expedite angelegt.

Verwandte Seiten

• Anforderungen schreiben, die kanman abschließen kann
• Deine erste Story
• So prüft kanman seine Arbeit