---
type: wiki-page
area: admin
related: []
---

# Refinement und Retro — die Termine des Frameworks

Kanban braucht wenige, aber verlässliche Termine, sonst verkommt das Board zur
Ablage. Festgelegt in [ADR-0005](../../adr/0005-pm-framework-kanban.md); 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 [`docs/sources/protokolle/`](../../sources/protokolle/retro-2026-08-09.md) abgelegt, eine Datei je Termin. Die
erste: [2026-08-09](../../sources/protokolle/retro-2026-08-09.md).

## AAR (anlassbezogen)

Nach jedem Deploy mit Übergabe und nach jedem Incident, Vorlage in
[docs/aar/template.md](../../aar/template.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`](../../../AGENTS.md) und
  sind über den Gitea-Mirror von überall lesbar.
- Arbeit zwischen Sessions läuft über das
  [Deploy-Übergabe-Verfahren](../deployment/deploy-uebergabe.md) — 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.