rel="nofollow" href="#uc6b439e0-d581-4895-b1d4-6e361bddd48f">3.15.2 Inspektion: Einholen von Feedback zum Produktinkrement
3.15.3 Adaption: Integration des Feedbacks in das Product Backlog
3.15.3.1 Zusätzliche und alternative Praktiken im Sprint-Review
3.15.4 Und was ist mit der Abnahme?
3.16.1 Refinement im Sprint-Review
3.16.2 Refinement im Sprint Planning
3.16.3 Refinement zwischen Sprint-Review und Sprint Planning
3.16.4 Ad-hoc-Refinement-Meetings
3.16.5 Regelmäßige Refinement-Meetings
3.16.6 Refinement-Optionen im Vergleich
3.17 Das Kapitel in Stichpunkten
4.1 Entwickler:innen (Cross-Funktionalität, Autonomie, Selbstorganisation)
4.1.2 Autonomie und Selbstorganisation
4.1.3 Entwickler:innen nur in einem Team
4.3 Lieferbare Produktinkremente
4.4 Technische Herausforderungen
4.4.1 Herausforderung 1: lieferbares Produktinkrement ab dem ersten Sprint
4.4.2 Herausforderung 2: inkrementelle Architekturentwicklung
4.5 Sprint Planning: das »Wie«
4.5.2 Story Points als Größenmaß
4.5.3 Vorteile von Story Points
4.5.5 Varianten des Planning Poker®
4.5.6 Erfahrungen mit Planning Poker®
4.5.7 Inkrementelles Ziehen in den Sprint
4.5.8 Das »Wie« im Sprint Planning: Task-Breakdown
4.5.10 Was wir nicht im Sprint Planning festlegen
4.6 Taskboard als Sprint Backlog
4.8.1 Umgang mit Problemen im Daily Scrum
4.8.2 Der Product Owner im Daily Scrum
4.8.3 Hindernisbearbeitung im Daily Scrum
4.9 Das Kapitel in Stichpunkten
5 Kontinuierliche Verbesserung
5.1 Scrum-Master-Verantwortung
5.1.1 Scrum-Master-Dienste für den Product Owner
5.1.2 Scrum-Master-Dienste für das Scrum-Team
5.1.3 Scrum-Master-Dienste für die Organisation
5.1.4 Der Scrum Master und die Entwickler:innen
5.1.5 Der Scrum Master und der Product Owner
5.1.6 Der Scrum Master und die Organisation
5.1.7 Der Scrum Master und die Scrum-Meetings
5.1.8 Haltung und Einstellung des Scrum Masters
5.1.9 Braucht es einen Vollzeit-Scrum-Master?