FAQ-Glossar zur Scrum Schulung

In der Scrum Schulung lernen Sie Scrum als leichtgewichtiges Rahmenwerk kennen, das auf Empirie (Transparenz, Überprüfung, Anpassung) und kurze Iterationen (Sprints) setzt. Wir üben praxisnah, wie cross-funktionale Teams in jeder Iteration nutzbare Inkremente liefern, wie sich ein klares Sprintziel auf Fokus und Lieferfähigkeit auswirkt und wie Sie mit Stakeholdern evidenzbasiert entscheiden.

Praxisbeispiel aus der Scrum Schulung:

- Empirie: Transparenz → Überprüfung → Anpassung
- Fokus auf nutzbare Inkremente pro Sprint
- Rollen: Scrum Master, Product Owner, Developers
- Events: Sprint, Planning, Daily, Review, Retrospektive

Im Kurs bilden diese Bausteine das Fundament, auf dem alle Übungen (Planung, Review, Retro) aufsetzen.

In der Scrum Schulung erleben Teilnehmende die Verantwortlichkeiten im Zusammenspiel: Der Product Owner maximiert Wert und verantwortet das Product Backlog, der Scrum Master coacht Team & Organisation in Scrum, die Developers liefern gemeinsam ein qualitativ hochwertiges Inkrement. Wir trainieren klare Schnittstellen, Entscheidungswege und typische Stolperfallen (z. B. Proxy-PO, Single-Developer-Bottlenecks).

Praxisbeispiel aus der Scrum Schulung:

- Product Owner: Priorisierung im Backlog-Workshop (Wert, Risiko, Ziel)
- Scrum Master: Daily moderieren, Impediments sichtbar machen
- Developers: Definition of Done einhalten, technische Qualität sichern

Die Übung macht Verantwortungen greifbar und verhindert Lücken/Überlappungen im Alltag.

Wir erarbeiten die Artefakte Product Backlog, Sprint Backlog und Inkrement und verknüpfen sie mit den Commitments Product Goal, Sprint Goal und Definition of Done. So wird klar, wie Ausrichtung, Qualität und Transparenz entstehen – und wie man sie sichtbar hält (Boards, Metriken, Demos).

Praxisbeispiel aus der Scrum Schulung:

- Product Backlog ↔ Product Goal
- Sprint Backlog ↔ Sprint Goal
- Inkrement ↔ Definition of Done

Die Visualisierung hilft, Prioritäten (Goal-First) statt Task-Listen zu steuern.

Wir simulieren Sprint Planning, Daily Scrum, Sprint Review und Retrospektive. Teilnehmende erfahren Timebox, Teilnehmerkreis, typische Anti-Patterns (Status-Daily, Folien-Review) und wie Events als Inspektions- und Anpassungszyklen echten Wert schaffen.

Praxisbeispiel aus der Scrum Schulung:

Sprint Planning → Ziel & Plan
Daily Scrum → 15 Min Ausrichtung
Sprint Review → Produkt & Feedback
Retrospektive → Prozess & Zusammenarbeit

Die Simulation zeigt, wie Events Entscheidungsqualität und Geschwindigkeit erhöhen.

Der Sprint ist eine feste Iteration (1–4 Wochen). Das Sprintziel ist der Leitstern: Es bündelt Entscheidungen, erhöht Fokus und macht Kompromisse transparent. Wir üben, Ziele wertorientiert und überprüfbar zu formulieren – weg von Auslastung, hin zu Outcome.

Praxisbeispiel aus der Scrum Schulung:

**Sprintziel (Schulungsübung):** „Erste Registrierung per E-Mail ermöglichen (inkl. Double-Opt-In)“

Konkrete, testbare Ziele machen Fortschritt sichtbar und Reviews aussagekräftig.

PBIs beschreiben Nutzer-/Business-Wert und werden im Refinement laufend präzisiert (Akzeptanzkriterien, Größe, Risiko). Wir trainieren Splitting-Patterns (Workflow, Datenpfad, Regeln) und zeigen, wie gute PBIs Vorhersagbarkeit und Qualität verbessern.

Praxisbeispiel aus der Scrum Schulung:

pbi:
  title: Registrierung via E-Mail
  as_a: Besucher
  i_want: mich mit E-Mail registrieren
  so_that: ich Zugang erhalte
  acceptance:
    - Double-Opt-In Link per E-Mail
    - Fehlermeldung bei ungültiger Adresse

Schlanke Templates halten Fokus auf Nutzerwert und testbare Kriterien.

Die DoD ist die gemeinsame Qualitätsbasis: Ab wann ist Arbeit wirklich „fertig“? Wir erarbeiten teamweite DoD-Kriterien, heben sie schrittweise an und verknüpfen sie mit Metriken (Defects, MTTR, Deploy-Frequenz).

Praxisbeispiel aus der Scrum Schulung:

- Code Review (4-Augen)
- Tests grün (Unit/Integration)
- Security-Checks bestanden
- Doku aktualisiert
- Staging-Deploy erfolgt

Eine gelebte DoD senkt Nacharbeit, erhöht Vertrauen und Planbarkeit.

Wir unterscheiden klar: Story Points schätzen Komplexität/Unsicherheit, Prognosen leiten sich empirisch aus Throughput/Velocity ab. In Übungen vergleichen wir Plan-Vorgaben vs. datenbasierte Vorhersagen.

Praxisbeispiel aus der Scrum Schulung:

- Story Points: 1, 2, 3, 5, 8, 13 …
- Durchsatz (Übung): 12 PBIs/Sprint → Prognose aus echten Daten

Empirie schlägt Wunschdenken – für belastbare Kommunikation mit Stakeholdern.

Die DoR ist kein offizielles Scrum-Element, kann aber als Leitplanke helfen, Startklar-Kriterien für PBIs zu klären. Wir achten darauf, dass DoR das Lernen nicht verhindert (kein starrer Gatekeeper).

Praxisbeispiel aus der Scrum Schulung:

- Ziel verständlich
- Akzeptanzkriterien vorhanden
- Grobgröße bekannt
- Abhängigkeiten sichtbar

Leitplanke statt Bürokratie – sonst bremst sie den Fluss.

Wir simulieren kurze, regelmäßige Refinements (Flow statt Großmeeting), arbeiten mit Beispiel-getriebener Spezifikation, Splitting-Mustern und früher Risiko-Klärung (Spikes/PoCs).

Praxisbeispiel aus der Scrum Schulung:

- Split nach Regeln (Happy Path vs. Edge Cases)
- Beispiele vor Regeln (Acceptance by Example)
- Risiken zuerst (Spike, PoC)

Guter Refinement-Flow reduziert Überraschungen im Sprint deutlich.

Commitment gilt dem **Sprintziel**, nicht einer fixen Taskliste. Das Sprint Backlog darf sich ändern, solange das Ziel erreichbar bleibt – Ergebnisverantwortung statt Scope-Verträge.

Praxisbeispiel aus der Scrum Schulung:

Sprintziel bleibt Fixstern → Tasks können variieren, um es zu erreichen.

Das schützt Fokus und ermöglicht sinnvolle Kurskorrekturen innerhalb der Iteration.

Wir integrieren Visualisierung, WIP-Limits, klare Policies und Fluss-Metriken in den Scrum-Rahmen. Ziel: Wartezeiten senken, Kontextwechsel vermeiden, Vorhersagbarkeit erhöhen.

Praxisbeispiel aus der Scrum Schulung:

- WIP-Limit „In Arbeit“: 3
- Policy: Kein Start ohne Review-Slot
- Metriken: Cycle Time, Throughput

Flow-Optimierung beschleunigt Lieferung ohne Überlastung.

Wir fokussieren Outcome-Metriken (z. B. Aktivierungsrate, Time-to-Learn) und Team-Flow (Durchsatz, Cycle Time, 85%-Perzentil). Keine Metriken zur Bestrafung – sie sollen Entscheidungen verbessern.

Praxisbeispiel aus der Scrum Schulung:

- Outcome: % aktivierte Nutzer im Onboarding
- Flow: 85%-Cycle-Time ≤ 8 Tage

Messbar machen, was zählt – und daraus gemeinsam lernen.

Story-Splitting (Workflow-Schritte, Regel-Varianten, Datenpfade), relative Schätzung (Planning Poker) und optional No-Estimates bei stabilem Fluss. Ziel: kleine, wertvolle Inkremente, früheres Feedback, geringeres Risiko.

Praxisbeispiel aus der Scrum Schulung:

- Split: MVP → Edge Cases → Verbesserungen
- Relative Schätzung mit Referenz-Items

Kleiner schneiden heißt schneller lernen – und besser planen.

Ein Produkt, ein Product Owner, ein Product Backlog. Synchronisierung über gemeinsame Ziele, leichtgewichtige Abhängigkeits-Boards und regelmäßige Austauschformate (z. B. Scrum of Scrums).

Praxisbeispiel aus der Scrum Schulung:

- Gemeinsames Product Goal
- Einfaches Abhängigkeits-Board
- Sync-Meeting 2×/Woche

Skalierung erhöht Kommunikationskosten – Einfachheit bewahren.

Review = Arbeitsmeeting am Inkrement, mit echtem Feedback und nächsten Schritten. Wir üben Live-Demos, Metriken-Gespräch und das direkte Ableiten von Backlog-Updates.

Praxisbeispiel aus der Scrum Schulung:

- Live-Demo des Inkrements
- Kennzahlen & Beobachtungen teilen
- Optionen → Backlog aktualisieren

Wert entsteht durch gemeinsames Lernen – nicht durch Statusfolien.

Systemisch denken: Ursachen sichtbar machen, Ownership klären, Eskalationspfade definieren. Wir quantifizieren Warte- und Kontextkosten, um Priorität zu begründen.

Praxisbeispiel aus der Scrum Schulung:

impediment:
  beschreibung: 'Test-Umgebung instabil'
  auswirkung: 'Builds scheitern 2x/Woche'
  gegenmaßnahmen:
    - 'Monitoring & Ownership klären'
    - 'Rollback-Strategie definieren'
  status: 'in Bearbeitung'

Dokumentation & Ownership sichern nachhaltige Lösungen.

Formate wie Start/Stop/Continue, 4Ls, Sailboat, Team Health Check. Wichtig: konkrete Experimente, klare Messgrößen und Follow-Up im nächsten Sprint.

Praxisbeispiel aus der Scrum Schulung:

- Experiment: „Pairing 2h/Tag auf kritischen Stories“ → Metrik: Defects ↓

Retros führen zu spürbaren Veränderungen – nicht nur zu Diskussion.

Unbekanntes zuerst: Risiken früh ins Sprint Backlog ziehen (Spikes, Prototypen), Thin Slices liefern und Lernpfade planen. Das senkt Spät-Fails und erhöht Planbarkeit.

Praxisbeispiel aus der Scrum Schulung:

Unbekanntes zuerst → Lernkurve ↑, Spät-Fails ↓

Frühes Lernen spart teure Umbauten am Ende.

Remote-Basics: gute Audio/Video-Qualität, gemeinsame Boards, klare Working Agreements, überlappende Kernzeiten und asynchrone Dokumentation. Wir üben Moderations- und Kollaborationstechniken.

Praxisbeispiel aus der Scrum Schulung:

- Working Agreement: Fokus-Zeiten, Antwortfenster, Meeting-Guidelines

Bewusste Regeln kompensieren fehlende Flurgespräche.

Technische Schulden sichtbar machen, DoD schrittweise anheben und Qualitätsmaßnahmen als PBIs planen. Wir verknüpfen Qualität mit Outcomes (MTTR↓, Defects↓, Release-Frequenz↑) und üben Priorisierung im Backlog.

Praxisbeispiel aus der Scrum Schulung:

- PBI: „CI-Build < 10 Min“
- Outcome: „Release-Frequenz 2×/Woche“

Qualität ist Feature – sie beschleunigt nachhaltige Lieferung.