Das Daily Scrum ist eines der wichtigsten Meetings im Scrum. Aber warum wird es oft so ineffizient durchgeführt? Auf Grund des kurzen Zeitraumes ist eine Straffung des Meeting notwendig. Aber dennoch muss es „gewinnbringend“ durchgeführt werden. Gewinnbringend bedeutet, dass jedes Teammitglied einen Mehrwert aus diesem Meeting herausziehen sollte. Wer kennt nicht dieses Gefühl: „Ach, schon […]
Kategorie: SCRUM
Business Value Points
Eine der schwierigsten Aufgaben eines Product Owners ist die Priorisierung der Features seines Produktes. Hierbei kommt schnell der Geschäftswert (auch Businesswert, Business Value genannt) mit ins Spiel. Nicht jedes Unternehmen ist marktgetrieben und kann leicht feststellen, welchen Geldwert ein neues Feature haben wird. Der Wert eines Features wird dann oft auch nicht zuletzt durch den Zeitpunkt des […]
Was kann man tun, um Sprints besser zu organisieren?
Im allgemeinen wird das Team innerhalb eines Sprints mehr oder weniger sich alleine überlassen, doch kann man ihm eine Struktur mitgeben, um die Sprints besser zu organisieren? Generell arbeitet das Team autonom an seinen User Stories und trifft sich im Daily Scrum, um die klassischen Fragen zu besprechen: Was habe ich gestern getan? Was tue ich […]
User Stories
Eine User Story beschreibt eine bestimmte Funktionalität, die für den Benutzer des Systems einen wahrnehmbaren Wert hat. Jede User Story sollte so einfach wie möglich und aus Sicht des Benutzers beschreiben, was der Benutzer mit der Funktionalität erreichen will. Der Fokus hierbei liegt auf den Fragen: Für wen ist das Feature gedacht? Was will derjenige […]
Backlog Refinement – Grooming
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 […]
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 […]
