Backlog Refinement kann auch als Backlogpflege bezeichnet werden und ist kein „echter“ Bestandteil von Scrum, sondern ein „Best Practice“, das sich über die Jahre etabliert hat. Das Meeting kann formell, oder auch informell stattfinden. Wie sich das Team dabei organisiert ist jedem Team selbst freigestellt. Die wesentlichen Punkte des Backog Refinement werden hier im folgenden […]
Monat: Juli 2016
Sprint Planungssitzung
In der Sprint Planungssitzung stellt das Team ein realistisches Sprint Backlog, das alle Anforderungen enthält, die bis zum Ende des Sprint umgesetzt werden. Die Aufgaben in dieser Sitzung sind wie folgt verteilt: Product Owner plant und stellt das Sprint-Ziel und eine Vorauswahl der umzusetzenden Anforderungen vor Team identifiziert die für die Anforderungen notwendigen Aufgaben und […]
Daily SCRUM
An jedem Tag findet ein kurzes (maximal 15-minütiges) Daily Scrum statt. Scrum definiert keine konkrete Uhrzeit für das Meeting, das Meeting sollte jedoch täglich zur gleichen Zeit stattfinden. Empfohlener Zeitpunkt für das Scrum-Meeting ist die Zeit nach dem Mittagessen, da morgendliche Scrum-Meetings oft mit flexiblen Gleitzeitregelungen kollidieren und der müde Punkt nach dem Mittagessen bei […]
Sprint Review
Am Ende eines Sprint findet das meist zweistündiges Sprint-Review statt. (Für detaillierte Zeiteinschätzungen siehe Sprint, Zeitplanung.) Nach einem Sprint wird das Sprint-Ergebnis einem informellen Review durch Team und Kunden unterzogen. Dazu wird das Ergebnis des Sprints (die laufende Software) vorgeführt, eventuell werden technische Eigenschaften präsentiert. Der Kunde und/oder der Product Owner prüft, ob das Sprint-Ergebnis […]
Sprint Retrospektive
In der Retrospektive wird die zurückliegende Sprint-Phase betrachtet. Es handelt sich dabei nicht um Lessons Learned, sondern um einen zunächst wertfreien Rückblick auf die Ereignisse des Sprints. Die je nach Sprintlänge ca. zweistündige Sprint Retrospektive findet unmittelbar nach dem Sprint Review statt und schließt den Sprint ab. Alle Teilnehmer notieren dazu die für sie wichtigen […]
Product Backlog
Das Product Backlog enthält die Features des zu entwickelnden Produkts. Es beinhaltet alle Funktionalitäten, die der Kunde wünscht, zuzüglich technischer Abhängigkeiten. Vor jedem Sprint werden die Elemente des Product Backlogs neu bewertet und priorisiert, dabei können bestehende Elemente entfernt sowie neue hinzugefügt werden. Hoch priorisierte Features werden von den Entwicklern im Aufwand geschätzt und in […]
Kano Modell
Eine Gliederung von Anforderungen ist nach dem Kano Modell möglich. Es wurde von Dr. Noriaki Kano 1978 entwickelt und hilft bei der Klassifizierung von Kundenwünschen und Anforderungen. Das Modell vergleicht die erreichbare Zufriedenheit von Kunden, basierend auf dem Erfüllungsgrad ihrer gestellten Anforderungen. Kano unterscheidet drei Anforderungsklassen: die Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren. Basisfaktoren sind selbstverständliche Grundforderungen, […]
Releaseplan
Der Releaseplan vom Product Owner erstellt und beschreibt wann welche Anforderungen erfüllt sein werden. Voraussetzungen um einen Releaseplan zu erstellen: Product Backlog ist gefüllt und der Aufwand ist abgeschätzt Risiken sind abgeschätzt und Anforderungen im Product Backlog priorisiert Entwicklungsgeschwindigkeit des Teams ist ermittelt Schritte um einen Releaseplan zu erstellen Zeitraum bestimmen, in dem alle Einträge […]
Impediment Liste
In die Impediment Liste werden alle Hindernisse mit ihrem Auftrittsdatum und einem möglichen Lösungsdatum des Projekts eingetragen. Der Scrum-Master ist dafür zuständig, diese gemeinsam mit dem Team auszuräumen. Hindernisse werden im Daily Scrum systematisch identifiziert und in die Impediment Liste aufgenommen. Gelöste Hindernisse werden gestrichen. Die Impediment Liste hilft uns zu identifizieren, welche Hindernisse den […]
Sprint Burndown Bericht
Der Sprint Burndown Bericht zeigt den Fortschritt im Sprint auf. Er reflektiert die Summe der Aufwände (Arbeitsstunden) über die Tage eines Sprints. Auf der x-Achse stehen die Anzahl der Tage für einen Sprint. Auf der y-Achse die kumulative Anzahl der im Sprint Backlog enthaltenen Aufwände. Eine gerade zeigt den idealen Burndown und erlaubt dem Team einen Vergleich […]
Sprint Endbericht
Der Sprint Endbericht enthält die wesentlichen Rahmendaten des Sprints und dokumentiert, wie viele der geplanten Anforderungen erfolgreich umgesetzt und vom Product Owner abgenommen wurden. Es ist sinnvoll, dass der Bericht auch vom Product Owner erstellt wird und seine Erkenntnisse in den Release Plan aufgenommen werden. Folgende Struktur wird vorgeschlagen (Max. zwei Seiten): Sprint Daten Sprint […]
Definition of Done (DoD)
Als Definition of Done (DoD) wird ein gemeinsames Verständnis aller Teammitglieder bezeichnet, wann eine Arbeit als „Fertig“ bezeichnet werden kann. Beispielhafte Prüfpunkte für eine Definition of Done Hierzu zählen in der Regel folgende allgemeine Kriterien: Qualitätsstand Dokumentation Bedienbarkeit (Unit-) Testabdeckung Vollständigkeit (Code-) Review Mit wachsender Erfahrung des Scrum-Teams kann sich auch eine DoD weiterentwickeln und mehr, oder feiner spezifizierte Kriterien […]
Sprint Backlog
Das Sprint Backlog enthält alle Aufgaben, die notwendig sind, um das Ziel des Sprints zu erfüllen. Eine Aufgabe sollte dabei nicht länger als 16h dauern. Längere Aufgaben sollten in kurze Teilaufgaben zerlegt werden. Bei der Planung des Sprint werden nur so viele Aufgaben eingeplant, wie das Team an Kapazität aufweisen kann. Die Kapazität berechnet sich […]
Der Sprint
Zentrales Element von Scrum ist der Sprint. Ein Sprint bezeichnet die Umsetzung einer Iteration, Scrum schlägt ca. 30 Tage als Iterationslänge vor. Vor dem Sprint werden die Produkt-Anforderungen des Kunden in einem Product Backlog gesammelt. Auch technische und administrative Aufgaben werden dort aufgenommen. Das Product-Backlog muss nicht vollständig sein; es wird laufend fortgeführt. Die Anforderungen […]
