> ## Documentation Index
> Fetch the complete documentation index at: https://docs.baenninger.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Meetings

Jeder Sprint beginnt mit einem Meeting (Sprint Planning) und endet mit zwei Meetings (Sprint-Review und Sprint-Retrospektive). Dazwischen ist lediglich das Daily Scrum vorgesehen.

## Sprint Planning

Das Ziel des Sprint Planning ist es, drei zentrale Fragen zu beantworten:

1. **Warum ist dieser Sprint wertvoll? → Sprint-Ziel**
2. **Was wird in diesem Sprint umgesetzt? → Product Backlog Items**
3. **Wie wird es umgesetzt? → Plan für die Umsetzung**

### Ziele

* Vermeidung von **Überlastung** und Sicherstellung einer **hohen Qualität**
* Die **Verlässlichkeit** der Prognosen sollte über mehrere Sprints hinweg verbessert werden

### Ablauf

* Der **Product Owner** schlägt zu Beginn ein **Sprint-Ziel** vor, das im Verlauf des Meetings angepasst werden kann
* Die **Entwickler** wählen aus den priorisierten Product Backlog Items diejenigen aus, die sie im Sprint umsetzen können
* Um eine **realistische Planung** zu gewährleisten, werden die Items oft geschätzt (z. B. durch Story Points oder T-Shirt-Sizing)
* Das Team gibt eine **Vorhersage (Forecast)** ab, wie viele Items realistisch im Sprint abgeschlossen werden können

## Daily Scrum

Das **Daily Scrum** ist ein tägliches, maximal **15-minütiges** Meeting der **Entwickler**, um die Arbeit auf das Sprint-Ziel auszurichten.

### Ziel

* Koordination und Einsatzplanung für das Team für den Tag

### Merkmale

* **Zeit und Ort**: Täglich zur gleichen Zeit am gleichen Ort
* **Format**: Stehendes Meeting zur Förderung von **Kürze und Fokus**
* **Dauer**: Maximal **15 Minuten**

### Typische Fragen zur Strukturierung

1. Was habe ich gestern gemacht, das uns hilft, das Sprint-Ziel zu erreichen?
2. Was werde ich heute tun, das uns hilft, das Sprint-Ziel zu erreichen?
3. Sehe ich Hindernisse, die uns am Erreichen des Sprint-Ziels hindern könnten?

## Sprint-Review

Das **Sprint-Review** dient dazu, das **Produkt** und dessen **Eignung für die Anwender** zu überprüfen.

### Ziele

* Überprüfung, ob das richtige Produkt entwickelt wird
* Evaluierung der Features auf **Benutzbarkeit und Zweckmässigkeit**
* Analyse, welche Funktionen noch fehlen
* Rückblick auf den Sprint: Welche **Sprint Backlog Items** wurden abgeschlossen?

### Ablauf

1. **Präsentation des Produktinkrements** durch die Entwickler
2. **Akzeptanz oder Ablehnung** der Features durch den **Product Owner**
3. **Feedback der Stakeholder** (Kunden, Anwender)
4. **Bewertung des Sprint-Ziels** durch den Product Owner
5. **Anpassung des Product Backlog** bezüglich dringlichen Feedbacks durch den Product Owner

<Check>
  * Stakeholder-Teilnahme ist **essentiell**, da sie wertvolles Feedback geben.
  * **Scrum Master** **moderiert**, um den Fokus auf **Lernen statt Rechtfertigung** zu legen.
</Check>

## Backlog-Refinement

Im **Backlog-Refinement** fügt man Details, Schätzungen, etc. in das Product Backlog. Scrum definiert dabei nicht, wann das Refinement erfolgt.

### Ziele

* Integration und Priorisierung neuer Einträge ins Product Backlog
* Schätzung neuer Product Backlog Items
* Neueinschätzung existierender Product Backlog Items
* Entfernen überflüssiger Product Backlog Items
* Detaillierung und Aufteilung hoch priorisierter Product Backlog Items

## Sprint-Retrospektive

Die **Sprint-Retrospektive** dient der kontinuierlichen Verbesserung der Zusammenarbeit und des Entwicklungsprozesses des Scrum-Teams.

### Ziel

* Verbesserung der Zusammenarbeit und der gemeinsamen Effektivität im Scrum-Team.

### Ablauf

* Der Scrum Master führt das Team durch die Retrospektive, um sicherzustellen, dass am Ende konkrete Verbesserungsmaßnahmen festgelegt werden.
* Die Massnahmen sollen idealerweise im nächsten Sprint umgesetzt werden.