Anforderungen schreiben, die kanman erledigen kann

kanman kann nur belegen, 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 fünf Bereitschaftsprüfungen, bevor sie freigegeben und in den Tracker geschrieben werden kann:

Prüfung	Bestanden, wenn
Klare Akzeptanzkriterien	Jedes Kriterium hat eine Ausgangslage (Given), eine Aktion (When) und ein beobachtbares Ergebnis (Then)
Testbar	Die Story hat einen Testplan, und jedes Ergebnis lässt sich durch einen Test oder ein Skript prüfen, nicht durch Meinung
Klein genug	Die Story passt in Größe S oder M; L-Stories müssen geteilt werden
Keine offenen Fragen	Alles, was kanman in der Aufnahme gefragt hat, ist beantwortet
Hat einen Demonstrate-Block	Es gibt konkrete Schritte, die das Ergebnis zeigen

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

Mit dem Ergebnis beginnen, nicht mit der Lösung

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

Statt	Schreiben Sie
“Eine CSV-Bibliothek und einen neuen Endpunkt hinzufügen”	“Kunden können ihre Rechnungen für einen Zeitraum als CSV-Datei für ihre Steuerberatung herunterladen.”
“Die Geldformatierung reparieren”	“Jeder Betrag in der Rechnungsliste und auf der Rechnungsseite wird als `€4,125.00` angezeigt, wie heute auf der Rechnungsseite.”
“Performance verbessern”	“Die Rechnungsliste eines Kunden mit 5.000 Rechnungen lädt auf dem Staging-Server in unter 1 Sekunde.”

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.
Verwenden Sie echte Werte. “3 Rechnungen im März” ist prüfbar, “einige Rechnungen” nicht.
Nehmen Sie die Randfälle auf, die zählen: leere Ergebnisse, ungültige Eingaben, Berechtigungen.
Beschreiben Sie die Oberfläche nicht pixelgenau. Nennen Sie, was sichtbar sein oder zurückkommen muss.

kanman gibt jedem Kriterium eine stabile ID (ac-1, ac-2, …). Das Nachweispaket meldet jedes als bestanden, gescheitert oder unbekannt, mit Datei- und Zeilenverweisen.

Einen Demonstrate-Block schreiben

Der Demonstrate-Block ist der wichtigste Teil einer Story. Er ist das kurze Skript, dem eine Kollegin folgen würde, um Ihnen zu zeigen, dass die Funktion läuft, und kanman macht daraus die ausführbare Akzeptanz-Spec.

Ein guter Demonstrate-Block hat eine Art (UI, API, CLI oder Konfiguration), konkrete Schritte und das erwartete Ergebnis:

Kind: UI
Steps:
  1. Open /invoices
  2. Pick the date range 2026-03-01 to 2026-03-31
  3. Click "Download CSV"
Expected: a CSV file downloads with the columns date, number, amount and 3 rows

Kind: API
Steps:
  1. GET /api/invoices/export?from=2026-03-01&to=2026-03-31 with Accept: text/csv
Expected: status 200, content type text/csv, header row date,number,amount

Was als Demonstrate-Block nicht funktioniert:

“Tests laufen durch.” Tests gehören zur Prüfung, sie sind nicht das Ergebnis.
“Es funktioniert.” Da gibt es nichts auszuführen.
Schritte, die Produktivdaten, das Login einer Person oder ein Fremdsystem brauchen, das die Testumgebung nicht erreicht.

Achtung

Eine Story ohne Demonstrate-Block lässt sich in der Aufnahme nicht freigeben und kann Ready nicht erreichen. Die Story zeigt Demonstrate-Schritt hinzufügen, damit Sie einen ergänzen.

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, teilen Sie sie in kleinere Stories, bevor Sie sie freigeben.

Offene Fragen in der Aufnahme beantworten

Lässt eine Anforderung etwas offen, 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?”. Beantworten Sie sie in der Anforderungsprüfung. Eine Story mit offenen Fragen lässt sich nicht freigeben.

Dringlichkeit mit einer Serviceklasse markieren

Stories sind standard, solange nichts anderes gilt. Um eine Story vorzuziehen, bitten Sie im Reiter Anforderungen des Teams darum, zum Beispiel mit “SBX-12 vorziehen”; “SBX-12 zurückstellen” setzt sie zurück:

Klasse	Wofür
`expedite`	Störungen, CI-Regressionen, Sicherheitskorrekturen. Wird nie durch Budgets oder Drosselung gestoppt.
`fixed_date`	Arbeit mit echter Frist
`standard`	Alles andere (Standard)
`maintenance`	Pflegearbeit aus dem Wartungsmodus (automatisch gesetzt)

Checkliste

Bevor Sie eine Story freigeben, prüfen Sie:

Der Titel sagt, was ein Nutzer danach tun kann.
Jedes Kriterium hat Given, When und Then mit echten Werten.
Der Demonstrate-Block lässt sich gegen eine frische Testumgebung ausführen.
Die Größe ist S oder M.
Es sind keine offenen Fragen übrig.

Weiter mit: Ein Akzeptanz-Manifest anlegen, damit kanman den Demonstrate-Block als echten Test ausführen kann.