Meine Session planen

# Session Brief: Scrum

## Ziel
Artefakt: Product Backlog

## Arbeitsfrage
Welches inkrementell lieferbare, wertvolle Sprint-Ziel verfolgt das Team in den nächsten 1-4 Wochen, und wie passt es das Vorgehen anhand der Sprint-Ergebnisse an?

## Kontext
Product Goal; aktuelles Product Backlog mit Priorisierung; Definition of Done; geplante Sprint-Länge (1-4 Wochen, 2 Wochen typisch); Kapazitätsschätzung des Teams; Stakeholder-Verfügbarkeit für Reviews.

## Setup
- Format: Methoden-Session
- Dauer: Laufend, pro Sprint: 2 h Planning, 15 min Daily, 1 h Review, 1 h Retro pro 2-Wochen-Sprint
- Modus: Workshop oder async
- Teilnehmende: Ein Product Owner (Backlog-Ordnung, Maximierung Wert); ein Scrum Master (Prozessschutz); 3-9 Developers (cross-funktional, liefern Increment); Stakeholder als Reviewer im Sprint Review.
- Owner: Ein Product Owner (Backlog-Ordnung, Maximierung Wert)
- 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 Product Backlog hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Backlog-Tool (Jira, Linear, GitHub Projects); Sprint-Board (Kanban-Spalten); Whiteboard für Sprint Planning; Definition of Done als sichtbares Dokument; Kalender für wiederkehrende Events; Retrospektive-Tool.

## Vorbereitung
Kalender-Serie für alle 5 Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). Sprint-Board eingerichtet. Definition of Done sichtbar. Stakeholder-Einladung für Review-Termine.

## Agenda
1. Phase 1: Sprint Planning (2 h für 2-Wochen-Sprint)
   Owner: Facilitator
   Aktion: Drei Teile: (1) Warum dieses Sprint? Sprint Goal aus Product Goal ableiten. (2) Was? Backlog-Items auswählen, die das Sprint Goal liefern. (3) Wie? Plan grob skizzieren, Spitzen identifizieren. Hinweis: Ohne Sprint Goal wird die Auswahl beliebig. Sprint Goal ist eine Outcome-Aussage, nicht eine Sammlung von Tickets. Wenn das nicht in einen Satz passt, ist der Sprint zu unfokussiert. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Product Backlog

2. Phase 2: Sprint-Arbeit und Daily Scrum (1-4 Wochen, Daily 15 min)
   Owner: Facilitator
   Aktion: Team arbeitet täglich am Sprint Goal. Daily Scrum am gleichen Ort, zur gleichen Zeit, max 15 min: was hilft uns heute das Sprint Goal zu erreichen? Hindernisse benennen. Hinweis: Daily ist kein Statusreport an den Scrum Master oder PO. Wer drei Sätze pro Person als Pflicht fordert, hat den Zweck verfehlt. Ziel ist Anpassung, nicht Berichterstattung. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Sprint Backlog

3. Phase 3: Sprint Review (1 h für 2-Wochen-Sprint)
   Owner: Facilitator
   Aktion: Increment vor Stakeholdern zeigen (Demo, nicht Slides). Feedback einholen. Backlog anpassen. Markt- oder Strategie-Updates aufnehmen. Review ist Arbeitssitzung, kein Show-and-Tell. Hinweis: Wenn Stakeholder nur Beifall klatschen, fehlt Feedback-Substanz. Konkrete Fragen vorbereiten („was würde dich abhalten, das morgen zu nutzen?“). Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Increment

4. Phase 4: Sprint Retrospective (1 h für 2-Wochen-Sprint)
   Owner: Facilitator
   Aktion: Was lief gut, was nicht, was ändern wir? Maximal 1-2 konkrete Verbesserungen pro Retro, mit Owner und Erfolgskriterium. Eine Verbesserung wandert ins nächste Sprint Backlog. Hinweis: Wenn die Retro nur Sammlung ohne Action wird, sterben Verbesserungen. Mindestens eine konkrete Aktion pro Retro, getrackt im nächsten Sprint. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Sprint Goal

5. Phase 5: Backlog Refinement (laufend) (10% der Sprint-Kapazität)
   Owner: Owner
   Aktion: Product Owner pflegt Backlog: priorisiert, schreibt Items neu, ergänzt Akzeptanzkriterien. Team hilft bei Klärung und Schätzung. Ziel: nächste 1-2 Sprints sind ready. Hinweis: Backlog ohne Refinement führt zu unklaren Sprint Plannings. Wenn Items mehr Diskussion als Schätzung brauchen, sind sie nicht ready. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Product Backlog

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: Product Backlog

## Abschluss
- Ergebnisartefakt aktualisieren: Product Backlog
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Product Backlog: Scrum

## Arbeitsfrage
Welches inkrementell lieferbare, wertvolle Sprint-Ziel verfolgt das Team in den nächsten 1-4 Wochen, und wie passt es das Vorgehen anhand der Sprint-Ergebnisse an?

## Kontext
Product Goal; aktuelles Product Backlog mit Priorisierung; Definition of Done; geplante Sprint-Länge (1-4 Wochen, 2 Wochen typisch); Kapazitätsschätzung des Teams; Stakeholder-Verfügbarkeit für Reviews.

## Beteiligte
- Owner: Ein Product Owner (Backlog-Ordnung, Maximierung Wert)
- Teilnehmende: Ein Product Owner (Backlog-Ordnung, Maximierung Wert); ein Scrum Master (Prozessschutz); 3-9 Developers (cross-funktional, liefern Increment); Stakeholder als Reviewer im Sprint Review.

## Input
Backlog-Tool (Jira, Linear, GitHub Projects); Sprint-Board (Kanban-Spalten); Whiteboard für Sprint Planning; Definition of Done als sichtbares Dokument; Kalender für wiederkehrende Events; Retrospektive-Tool.

## Vorlage
# Scrum Arbeitsvorlage

## Ziel

Iteratives Framework für komplexe Produktentwicklung mit kurzen Sprints, festen Rollen und definierten Events.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Product Backlog:
- Sprint Backlog:
- Increment:
- Sprint Goal:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- Product 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