management/verfahren/refinement.md

Refinement und Retro — die Termine des Frameworks

Kanban braucht wenige, aber verlässliche Termine, sonst verkommt das Board zur Ablage. Festgelegt in ADR-0005; hier steht, wie sie ablaufen.

Termine (festgelegt im Struktur-Workshop, 2026-08-06)

Termin	Wann
Refinement	sonntagabends, wöchentlich, 30–45 min
Retro light	im ersten Refinement des Monats, +20–30 min

Sonntag, weil die GitLab-Backups dort ohnehin laufen (00:00) — die Woche hat an dieser Stelle eine Kante, und die Abendblöcke, in denen real gearbeitet wird, liegen meist am Wochenende.

Die Retro bekommt keinen eigenen Termin: Ein monatlicher Extra-Termin im Solo-Betrieb ist ein Termin, der ausfällt. Sie hängt sich an das erste Refinement des Monats an — dann ist die Vorbereitung (die AARs des Monats) ohnehin offen.

Refinement (≈ wöchentlich, 30–45 min)

Der eine Termin, der das System am Leben hält. Immer dieselbe Reihenfolge:

1. Board von rechts nach links lesen — zuerst status:doing: Läuft es noch, oder ist es in Wahrheit blockiert? Dann status:wartet: Wartet es noch auf das, was im Issue steht? Erst zuletzt status:next.
2. WIP-Limit prüfen — höchstens zwei Issues in doing. Ist es voll, wird nichts Neues gezogen; stattdessen wird gefragt, was das Laufende blockiert.
3. Nachziehen — freie Plätze aus next füllen, next aus dem Backlog auffüllen. Auswahlkriterium ist nicht Priorität allein, sondern was still kaputtgeht (Fristen, abgeschaltete Schutzmechanismen) vor was nervt vor was Spaß macht.
4. Entscheidungsvorlagen — offene Fragen, die eine Entscheidung von sorb brauchen, werden als Optionen mit Empfehlung vorgelegt, nicht als offene Fragen geparkt. Dauerhafte Ausnahmen von Regeln werden hier zu ADRs.
5. Datumspflicht prüfen — jedes zeitkritische Issue trägt ein Datum, kein „bald".

Retro light (≈ monatlich, 20–30 min)

Drei Fragen, mehr nicht:

• Welche Verfahren haben diesen Monat getragen, welche haben gestört?
• Welche ADRs sind durch die Realität überholt (→ neues ADR, altes auf „abgelöst durch")?
• Fasert etwas aus? Gibt es wieder Arbeit, die nur in Chatverläufen lebt?

Grundlage sind die AARs des Monats — sie sind die Retro-Vorbereitung, nicht ihr Ersatz.

Ergebnisse werden unter retro/ abgelegt, eine Datei je Termin. Die erste: 2026-08-09.

AAR (anlassbezogen)

Nach jedem Deploy mit Übergabe und nach jedem Incident, Vorlage in aar-vorlage.md. Ein AAR ist keine Chronik, sondern ein Wissensspeicher: Was war das Ergebnis, welche Befunde, was hat die Eingrenzung ermöglicht, welche Lehren, was bleibt offen. Offene Punkte aus einem AAR werden im selben Zug zu Issues — sonst versacken sie in der Prosa (real passiert am 2026-08-01, nachgezogen als #14–#16).

Board-Pflege, wenn sorb länger nicht dazukommt

Festgelegt 2026-08-06. Eine Session darf das Board abbilden, aber nichts zusagen:

erlaubt	nicht erlaubt
status:wartet setzen (mit benanntem Grund)	nach status:doing ziehen
Erledigtes schließen, mit Begründung im Issue	status:next vergeben
Fristen ins due_date-Feld nachtragen	Prioritäten umsortieren
Befunde als neues Issue anlegen	Milestones neu zuordnen

Die Trennlinie ist nicht Vorsicht, sondern Bedeutung: doing und next sind die Zusage-Spalten — sie sagen, was als Nächstes wirklich passiert. Das entscheidet sorb. Alles links davon bildet nur ab, was ohnehin schon der Fall ist.

Jede Änderung wird im Issue begründet, nicht still vorgenommen. Ein Board, dem man nicht ansieht, wer warum etwas verschoben hat, ist beim nächsten Refinement wertlos.

Zusammenspiel mit den Sessions

Mehrere Claude-Sessions arbeiten parallel (Mac-Session, Host-Sessions auf CFGMON und Overmind). Für sie gilt:

• Die kanonischen Arbeitskonventionen stehen in CLAUDE.md und sind über den Gitea-Mirror von überall lesbar.
• Arbeit zwischen Sessions läuft über das Deploy-Übergabe-Verfahren — Auftrag, Meldung, Protokoll im Issue, nicht im Chat.
• Was eine Session lernt, gehört ins Repo (AAR/ADR/Doku), nicht nur in ihr Gedächtnis — Sessions gehen verloren, Repos nicht.