methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session30-90 minWorkshop oder asyncPrioritized Backlog

Session: MoSCoW

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Methoden-Session mit 3-12. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik
Artefakt fertigstellen

Die Session arbeitet direkt auf Prioritized Backlog hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Sektion 1: Definition Must

    10 min

    Für diesen Release Must explizit definieren („ohne dieses Item ist Launch nicht möglich oder regulatorisch fehlerhaft“). Beispiele aus vergangenen Releases nennen. Hinweis: Wenn Must = „wichtig finde ich“ verhandelt wird, kollabiert die Methode. Schärfe in der Definition rettet den ganzen Workshop.

    FacilitatorPrioritized Backlog
  2. 2

    Sektion 2: Solo-Ranking durch PO

    10-15 min

    PO geht die Liste einmal durch und vergibt initiale Kategorie pro Item. Ohne Diskussion, nur Vorschlag. Andere notieren Abweichungen. Hinweis: PO-Ranking als Ausgangspunkt vermeidet endlose Gruppendiskussion. Andere bringen Korrekturen sichtbar mit, nicht im Vorbeigehen.

    FacilitatorRelease Scope
  3. 3

    Sektion 3: Diskussion und Konvergenz

    20-40 min

    Items mit Disagreement aufgreifen. Pro Item: Argument für Hochstufung, Argument für Herabstufung, Entscheidung durch PO. Kapazitätskontrolle: Musts müssen in <60% der Team-Kapazität passen. Hinweis: Wenn Musts >60% Kapazität, ist Release-Risiko hoch. Strikt prüfen: was kann zu Should werden, ohne dass Release platzt?

    FacilitatorTradeoff Notes
  4. 4

    Sektion 4: Won't this time klären

    10 min

    Items, die explizit raus sind, in Won't-Spalte. Mit Begründung dokumentieren. Klar machen: Won't = nicht jetzt, nicht „nie“. Hinweis: Won't this time explizit zu zeigen reduziert Stakeholder-Frust. Wenn ein Item nicht auftaucht, vermuten Stakeholder es sei vergessen.

    FacilitatorPrioritized Backlog
  5. 5

    Sektion 5: Kapazitäts-Reality-Check

    10 min

    Geschätzten Effort der Musts und Shoulds gegen verfügbare Team-Kapazität rechnen. Wenn Musts allein schon >100% Kapazität, Release in Gefahr und Scope-Verhandlung nötig. Hinweis: Häufige Falle: Musts werden ohne Aufwandsrechnung gestapelt. Methode wirkt strukturiert, Release kollabiert trotzdem an Kapazität.

    OwnerRelease Scope
  6. 6

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerPrioritized Backlog
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

Session Brief: MoSCoW

Ziel

Artefakt: Prioritized Backlog

Arbeitsfrage

Welche Items müssen zwingend im Release sein, welche sind verhandelbar, und welcher Scope bleibt für die Verhandlung mit Stakeholdern?

Kontext

Backlog mit Item-Beschreibungen; Effort-Schätzung pro Item (T-Shirt oder Story Points); bekannte Abhängigkeiten und Risiken; Constraints (Compliance, Verträge, externe Termine); Definition von „Must“ für diesen Release.

Setup

  • Format: Methoden-Session
  • Dauer: 30-90 min
  • Modus: Workshop oder async
  • Teilnehmende: Ein Product Owner mit Mandat zur finalen Priorisierung; ein Facilitator (oft Scrum Master oder Delivery Lead); 2-5 Stakeholder, die Item-Verständnis und Business-Kontext einbringen; Team-Vertreter aus Engineering.
  • Owner: Ein Product Owner mit Mandat zur finalen Priorisierung
  • Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
  • Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf Prioritized Backlog hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Backlog-Tool (Linear, Jira, Notion) mit Status- oder Label-Feld für MoSCoW; Whiteboard oder digitales Board mit vier Spalten (Must, Should, Could, Won't this time); Timer.

Vorbereitung

Vier Spalten als Board. Definition Must / Should / Could / Won't this time vorab erklären (Must = Release fällt sonst weg; Should = wichtig, Release ohne aber möglich; Could = wenn Zeit; Won't = bewusst nicht jetzt). Timer auf 60 min.

Agenda

  1. Sektion 1: Definition Must (10 min) Owner: Facilitator Aktion: Für diesen Release Must explizit definieren („ohne dieses Item ist Launch nicht möglich oder regulatorisch fehlerhaft“). Beispiele aus vergangenen Releases nennen. Hinweis: Wenn Must = „wichtig finde ich“ verhandelt wird, kollabiert die Methode. Schärfe in der Definition rettet den ganzen Workshop. Output: Prioritized Backlog

  2. Sektion 2: Solo-Ranking durch PO (10-15 min) Owner: Facilitator Aktion: PO geht die Liste einmal durch und vergibt initiale Kategorie pro Item. Ohne Diskussion, nur Vorschlag. Andere notieren Abweichungen. Hinweis: PO-Ranking als Ausgangspunkt vermeidet endlose Gruppendiskussion. Andere bringen Korrekturen sichtbar mit, nicht im Vorbeigehen. Output: Release Scope

  3. Sektion 3: Diskussion und Konvergenz (20-40 min) Owner: Facilitator Aktion: Items mit Disagreement aufgreifen. Pro Item: Argument für Hochstufung, Argument für Herabstufung, Entscheidung durch PO. Kapazitätskontrolle: Musts müssen in <60% der Team-Kapazität passen. Hinweis: Wenn Musts >60% Kapazität, ist Release-Risiko hoch. Strikt prüfen: was kann zu Should werden, ohne dass Release platzt? Output: Tradeoff Notes

  4. Sektion 4: Won't this time klären (10 min) Owner: Facilitator Aktion: Items, die explizit raus sind, in Won't-Spalte. Mit Begründung dokumentieren. Klar machen: Won't = nicht jetzt, nicht „nie“. Hinweis: Won't this time explizit zu zeigen reduziert Stakeholder-Frust. Wenn ein Item nicht auftaucht, vermuten Stakeholder es sei vergessen. Output: Prioritized Backlog

  5. Sektion 5: Kapazitäts-Reality-Check (10 min) Owner: Owner Aktion: Geschätzten Effort der Musts und Shoulds gegen verfügbare Team-Kapazität rechnen. Wenn Musts allein schon >100% Kapazität, Release in Gefahr und Scope-Verhandlung nötig. Hinweis: Häufige Falle: Musts werden ohne Aufwandsrechnung gestapelt. Methode wirkt strukturiert, Release kollabiert trotzdem an Kapazität. Output: Release Scope

  6. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: Prioritized Backlog

Abschluss

  • Ergebnisartefakt aktualisieren: Prioritized Backlog
  • Ablageort, Version und Review-Empfänger festlegen.
  • Owner, nächster Schritt und Reviewtermin festlegen.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

Prioritized Backlog: MoSCoW

Arbeitsfrage

Welche Items müssen zwingend im Release sein, welche sind verhandelbar, und welcher Scope bleibt für die Verhandlung mit Stakeholdern?

Kontext

Backlog mit Item-Beschreibungen; Effort-Schätzung pro Item (T-Shirt oder Story Points); bekannte Abhängigkeiten und Risiken; Constraints (Compliance, Verträge, externe Termine); Definition von „Must“ für diesen Release.

Beteiligte

  • Owner: Ein Product Owner mit Mandat zur finalen Priorisierung
  • Teilnehmende: Ein Product Owner mit Mandat zur finalen Priorisierung; ein Facilitator (oft Scrum Master oder Delivery Lead); 2-5 Stakeholder, die Item-Verständnis und Business-Kontext einbringen; Team-Vertreter aus Engineering.

Input

Backlog-Tool (Linear, Jira, Notion) mit Status- oder Label-Feld für MoSCoW; Whiteboard oder digitales Board mit vier Spalten (Must, Should, Could, Won't this time); Timer.

Vorlage

MoSCoW Arbeitsvorlage

Ziel

Priorisiert Scope in Must, Should, Could und Won't.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

  • Prioritized Backlog:
  • Release Scope:
  • Tradeoff Notes:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Fertigstellungscheck

  • Prioritized Backlog ist vollständig genug für Review:
  • Ablageort:
  • Version / Status:
  • Review durch:
  • Nächster Schritt:

Nächster Schritt

  • Ergebnis prüfen
  • offene Fragen markieren
  • Review oder Entscheidung terminieren
Vorlagenbasis

MoSCoW Arbeitsvorlage

Vorlage ansehenKompakte Arbeitsvorlage für MoSCoW mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
markdown

moscow-working-template.md

Kompakte Arbeitsvorlage für MoSCoW mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

MoSCoW Arbeitsvorlage

Ziel

Priorisiert Scope in Must, Should, Could und Won't.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

  • Prioritized Backlog:
  • Release Scope:
  • Tradeoff Notes:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Prioritized Backlog.
  • Pro Release-Runde eigene Version mit Datum und Release-Name. Verschiebungen zwischen Kategorien während des Sprints dokumentieren (z. B. „Item X von Should zu Must verschoben am 12.06., Grund: Compliance-Update“).
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet