Anforderungen schreiben, die kanman erledigen kann

kanman und sein Reviewer können nur prüfen, was verlangt wurde, wenn die Anfrage sagt, wie “fertig” aussieht. Dieser Leitfaden zeigt, was eine Story erledigbar macht, mit Beispielen zum Übernehmen.

Was kanman prüft

Jede Story durchläuft Bereitschaftsprüfungen, bevor sie freigegeben und in den Tracker geschrieben werden kann:

Der Bereitschaftswert (0 bis 100) fasst diese Prüfungen zusammen. Nur Stories, die alle bestehen, zeigen Bereit für kanman und lassen sich freigeben.

Mit dem Ergebnis beginnen, nicht mit der Lösung

Beschreib, was ein Nutzer oder ein System danach tun kann. Überlass die Umsetzung dem Team, außer sie ist wirklich wichtig.

kanman macht aus einem Ergebnis Kriterien und Schritte. Aus einer Lösung kann es ein Ergebnis nur durch Raten ableiten.

Akzeptanzkriterien als Given/When/Then schreiben

Jedes Kriterium ist eine Ausgangslage und ein beobachtbares Ergebnis:

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

Tipps:

• Ein Ergebnis pro Kriterium. “Dann lädt die Datei herunter, hat 3 Zeilen und heißt …” sind drei Kriterien.
• Verwende echte Werte. “3 Rechnungen im März” ist prüfbar, “einige Rechnungen” nicht.
• Nimm die Randfälle auf, die zählen: leere Ergebnisse, ungültige Eingaben, Berechtigungen.
• Beschreib die Oberfläche nicht pixelgenau. Nenne, was sichtbar sein oder zurückkommen muss.

kanman gibt jedem Kriterium eine stabile ID (ac-1, ac-2, …). Der unabhängige Reviewer prüft die Änderung gegen jedes davon, bevor kanman sie mergt.

Stories klein halten

kanman ordnet Stories den Größen S, M oder L zu. Die Größe bestimmt Kosten und Risiko:

• S: ein Verhalten in einem Bereich, typischerweise wenige Dateien.
• M: eine Funktion über zwei oder drei Bereiche, zum Beispiel API und Oberfläche.
• L: mehrere Verhaltensweisen oder Bereiche. Eine L-Story besteht die Bereitschaftsprüfung nicht.

Kleine Stories sind günstiger, schneller zu prüfen und scheitern auf leicht verständliche Weise. Ergibt eine Anforderung eine L-Story, teile sie in kleinere Stories, bevor du sie freigibst.

Offene Fragen in der Aufnahme beantworten

Lässt eine Anforderung etwas offen, das nur ein Mensch entscheiden kann, führt kanman es als offene Frage auf, statt eine Antwort zu erfinden. Typische Beispiele: “Soll der Export Rechnungsentwürfe enthalten?” oder “Welche Zeitzone bestimmt den Zeitraum?”. Details, die es aus deinem Repository ableiten kann, etwa welches Element eine Linie trägt oder welches Farb-Token passt, entscheidet es selbst und führt sie unter Meine Annahmen auf; prüf auch diese.

Jede Frage ist als Blockiert die Freigabe oder Blockiert nicht markiert. Beantworte sie in der Entwurfskarte, oben im Entwurf auf der Prüfseite oder per Antwort im Chat (“1: …, 2: nicht relevant”); kanman entscheiden lassen und Nicht relevant erledigen sie mit einem Klick. Eine Story mit blockierenden Fragen lässt sich nicht freigeben, außer durch Inhaber oder Admins des Workspaces mit Mit offenen Fragen freigeben. Siehe Annahmen und offene Fragen.

Dringlichkeit mit einer Serviceklasse markieren

Stories sind standard, solange nichts anderes gilt. Um eine Story vorzuziehen, bitte kanman in der Unterhaltung darum, zum Beispiel mit “SBX-12 vorziehen”; “SBX-12 zurückstellen” setzt sie zurück:

Checkliste

Bevor du eine Story freigibst, prüfe:

1. Der Titel sagt, was ein Nutzer danach tun kann.
2. Jedes Kriterium hat Given, When und Then mit echten Werten.
3. Die Größe ist S oder M.
4. Es sind keine blockierenden Fragen übrig, und die Annahmen unter Meine Annahmen stimmen.

Weiter mit: Wie kanman seine Arbeit prüft, dort steht, wie die Kriterien vor einem Merge geprüft werden.