# Software-Backlog: Runbook für eine entscheidbare Monatswarteschlange

Stand: 29. August 2026  
Herausgeber: Midnight Motion  
Verwendung: kostenlose, herstellerneutrale Arbeitsvorlage ohne E-Mail-Gate

> Hinweis: Alle Beispiele sind fiktiv. Dieses Runbook ist kein Scrum-, Kanban-, Kosten-, Termin- oder Liefervertrag. Team, Produkt, Risiko und Betriebsmodell bestimmen die passende Arbeitsweise. Angaben zu Datenschutz, Sicherheit, Vertrag und Regulierung müssen durch die jeweils verantwortlichen Stellen geprüft werden.

## 1. Ziel der Planung

Am Ende der Planung existieren:

- ein aktuelles Produkt- oder Prozessziel;
- ein benannter Priorisierungsentscheider;
- eine eindeutige Reihenfolge startfähiger Arbeit;
- eine getrennte Liste begrenzter Discovery-Fragen;
- ein klarer Ausnahmeweg für akute Wiederherstellung und verbindliche Schutzplanken;
- verfügbare fachliche Mitwirkung und Abnahme;
- ein Entscheidungslog für bewusst zurückgestellte Arbeit.

Nicht das Ziel: möglichst viele Tickets mit „hoch“ markieren oder einen vollständigen Jahresplan vortäuschen.

## 2. Rollen vor der Entscheidung

| Rolle | Verantwortet | Liefert Input | Entscheidet nicht automatisch |
|---|---|---|---|
| Backlog-/Produktverantwortung | Ziel, Reihenfolge, Entscheidungslog | Stakeholder, Nutzung, Geschäftskontext | technische Machbarkeit allein |
| Entwicklung | technische Optionen, Abhängigkeiten, Spanne, Risiken | Codebasis, Betrieb, Architektur | Geschäftspriorität allein |
| Fach-/Process Owner | Problem, Regeln, Abnahme, Mitwirkung | reale Arbeitsfälle und Daten | Gesamtwarteschlange allein |
| Design/Research | Nutzerproblem, Interaktion, Lernfrage | Beobachtung, Tests, Prototypen | Umsetzung allein |
| Betrieb/Sicherheit/Datenschutz | Schutzplanken und prüfbare Anforderungen | Risiko, Zugriff, Monitoring | pauschale Produktentscheidung außerhalb ihres Mandats |

Eine Person kann mehrere Rollen übernehmen. Verantwortung und Freigaben bleiben trotzdem sichtbar.

## 3. Eintrittskriterium für die Monatsentscheidung

Ein Kandidat enthält mindestens:

1. Zielbezug;
2. betroffene Nutzer oder Geschäftsprozesse;
3. beobachtetes Problem und vorhandenen Beleg;
4. erwartete, später prüfbare Wirkung;
5. reale Frist oder ausdrücklich „keine harte Frist“;
6. Schaden oder entgangenen Lernwert bei Nichtumsetzung;
7. bekannte Abhängigkeiten und notwendige Mitwirkung;
8. grobe Aufwandsspanne und Unsicherheit;
9. prüfbares Fertig-Kriterium;
10. verantwortliche Person.

Unvollständige, möglicherweise wichtige Kandidaten wechseln in „Discover“. Sie verdrängen nicht still startfähige Arbeit.

## 4. Ausnahmeweg definieren

Vor der Planung festlegen:

- Welche Ereignisse öffnen den Expedite-Weg?
- Wer darf eine Ausnahme erklären?
- Wer triagiert fachlich und technisch?
- Welche geplante Arbeit wird sichtbar pausiert oder verschoben?
- Wann endet der Ausnahmezustand?
- Wie gelangen Ursachen- und Präventionsarbeit zurück in das normale Backlog?

Beispielhafte Kategorien, keine automatische Einstufung:

- produktionskritischer Ausfall;
- aktiv relevantes Sicherheitsproblem;
- verbindliche rechtliche oder vertragliche Frist;
- Datenverlust oder unkontrollierte fehlerhafte Verarbeitung.

Ein wichtiger Stakeholder oder ein kurzfristiger Wunsch allein öffnet den Weg nicht.

## 5. Entscheidung in sechs Durchgängen

### D-01 – Ziel und Schutzplanken

- Ein primäres Ziel für den nächsten Planungszeitraum notieren.
- Betriebs-, Sicherheits- und Rechtsanforderungen getrennt markieren.
- Owner und notwendige Mitwirkung bestätigen.

Ergebnis: gemeinsamer Entscheidungsrahmen.

### D-02 – Kandidaten schneiden

- Dubletten zusammenführen.
- Lösungsidee und beobachtetes Problem trennen.
- Große Vorhaben in einen ersten vertikalen, abnehmbaren Arbeitsfall schneiden.
- Kandidaten ohne aktuelles Wiederaufnahme-Signal schließen statt endlos parken.

Ergebnis: vergleichbare Arbeitspakete.

### D-03 – Wirkung und Zeitkritik

Für jeden Kandidaten beantworten:

- Welcher Beleg existiert?
- Was ist nur eine Annahme?
- Welche Wirkung soll später sichtbar sein?
- Existiert ein Datum oder Ereignis, das den Wert verändert?
- Was passiert wahrscheinlich, wenn die Arbeit wartet?

Ergebnis: belegte Wirkung mit markierter Unsicherheit.

### D-04 – Startfähigkeit

- Vorgänger und blockierte Nachfolger benennen.
- Externe Zugänge, fachliche Entscheidungen und Datenverfügbarkeit prüfen.
- Aufwand als Spanne oder relative Größe einordnen.
- Abnahme, Testdaten und verantwortliche Person bestätigen.

Ergebnis: startfähig, Discovery nötig oder blockiert.

### D-05 – Paarweise Reihenfolge

Die Kandidaten nicht nur in Klassen sortieren. Je zwei Kandidaten vergleichen:

> Wenn nur einer jetzt möglich ist: Welcher trägt unter Ziel, Schutzplanken und aktueller Evidenz mehr bei – und warum?

Die Antwort und die bewusst verdrängte Arbeit protokollieren. Wiederholen, bis eine eindeutige Reihenfolge entsteht.

Ergebnis: Queue 1, 2, 3 … statt mehrere „Priorität 1“.

### D-06 – Pull-Vertrag

- Festlegen, wann der nächste Eintrag gestartet werden darf.
- Begonnene Arbeit nach Arbeitsart begrenzen.
- Fachliche Rückfragen, Review und Abnahme als Kapazität berücksichtigen.
- Scope-Änderungen und Blockaden sichtbar halten.

Ergebnis: beendbare statt nur begonnene Arbeit.

## 6. Entscheidungslog

| Datum | Kandidaten | Entscheidung | Begründung und Beleg | Verdrängte Arbeit | Annahme | Wiedervorlage-Ereignis | Entscheider |
|---|---|---|---|---|---|---|---|
| Fiktiv | B-118 vor B-121 | Schutzplanke zuerst | Rollenreview und klarer Abnahmefall | B-121 wartet | Ausnahmen sind vollständig erfasst | Rollenmatrix ändert sich | Fiktiv: PO |

Das Log erklärt spätere Änderungen. Es ist kein Instrument, um eine überholte Entscheidung zu verteidigen.

## 7. Review nach Abschluss

Für jeden abgeschlossenen Eintrag prüfen:

- Wurde das Fertig-Kriterium einschließlich fachlicher Abnahme erreicht?
- Ist die erwartete Wirkung bereits sichtbar, später messbar oder widerlegt?
- Welche Annahme hat sich geändert?
- Wie lange war die Arbeit gestartet, blockiert und in Prüfung?
- Welche ungeplante Arbeit hat die Queue verändert?
- Entsteht Folgearbeit, ein neues Risiko oder ein Grund zum Schließen weiterer Einträge?

## 8. Monatlicher Flow-Check

Keine universellen Zielwerte vorgeben. Stattdessen Verlauf und Ursachen betrachten:

- begonnene, aber nicht abgenommene Arbeit;
- Durchlaufzeiten vergleichbarer Arbeitstypen;
- Alter und Ursache blockierter Einträge;
- verdrängte Planarbeit und Expedite-Gründe;
- fertiggestellte Arbeit mit Ergebnisbeleg;
- wartende Abnahmen oder fehlende Fachentscheidungen.

## 9. Verbindung zum Software-Abo

Diese Vorlage kann den priorisierten Workstream eines Software-Abos strukturieren. Sie definiert jedoch keine enthaltene Kapazität, Anzahl paralleler Aufgaben, Reaktionszeit, Laufzeit, Rechte, Betriebsleistung oder Ausschlüsse. Diese Punkte gehören in den konkreten Leistungsrahmen.

Weitere Einordnung: https://midnightmotion.studio/softwareentwicklung-im-abo