Kontakt

Burndown Chart, Sprint Backlog, Improvement Backlog

Das Burndown Chart veranschaulicht den Fortschritt eines Sprints. Ein Burndown Chart stellt die noch zu bearbeitenden Items, z.B. als Story Points, im Verhältnis zur Zeit grafisch dar. Die Story Points sind dabei normalerweise auf der Y-Achse und die Zeit auf der X-Achse aufgetragen (siehe auch Burn-up Chart). Mit Hilfe des Burndown Charts lassen sich Abweichungen im Verlauf eines Sprints frühzeitig erkennen und angemessene Lösungsmaßnahmen können rechtzeitig begonnen werden.

Im Sprint Backlog befinden sich die im aktuellen oder kommenden Sprint zu bearbeitenden User Stories und Aufgaben. Die Lieferung der im Sprint Backlog befindlichen User Stories im Sprint wurde vom Team prognostiziert. Ziel eines Sprints ist die Fertigstellung eines nutzbaren und releasefähigen Inkrements.

Das Improvement Backlog ist eine nach Priorität geordnete Liste mit Maßnahmen zur Verbesserung der Zusammenarbeit. Die Improvements sind Ergebnisse der Sprint Retrospektiven und werden im Improvement Backlog als Stories abgebildet und zusammengefasst. Für die Pflege des Improvement Backlog ist nicht der PO sondern das Team verantwortlich.

Vision

Die Vision ist eine ganzheitliche Betrachtung der Projektziele oder des Produkts und wird vom Product Owner entwickelt. Er erzeugt (ggf. zusammen mit dem Scrum-Team, Stakeholdern, Marketing) ein Zukunftsbild der Idee / des Projekts. Die Vision soll die Stakeholder und das Team von dem Produkt überzeugen, sie motivieren und begeistern.

Stakeholder

Stakeholder sind zum Beispiel Kunden, Investoren, Anwender, Partner, Aktionäre, andere Mitarbeiter oder das Management. Die Stakeholder sind direkt oder indirekt von den Projektergebnissen betroffen und haben ein (wirtschaftliches) Interesse an dem Produkt. Sie sind jedoch nicht Teil eines Scrum-Teams. Die Stakeholder teilen dem Product Owner ihre Anforderungen und Wünsche an das Produkt mit und beeinflussen auf diese Weise die Produktentwicklung. Der Kontakt mit dem Scrum-Team während eines Sprints erfolgt ausschließlich über den Product Owner.

Product Backlog Refinement

Das Product Backlog Refinement ist neben dem Planning 1 und dem Sprint Review die wichtigste Schnittstelle zwischen Entwicklungsteam und Product Owner. Im Product Backlog Refinement werden vom Product Owner regelmäßig (z.B. jede Woche mindestens eine Stunden) neue User Stories vorgestellt, Fragen des Teams beantwortet und wenn möglich vom Team geschätzt. Ist eine Schätzung nicht möglich (Definition of Ready nicht erfüllt), klärt der Product Owner offenen Fragen und stellt die Story im nächsten Refinement erneut vor.

Planning 1

Planning 2

Daily

Durch das Daily wird der kontinuierliche Informationsaustausch zwischen den Teammitgliedern gefördert. Ziel des Dailys ist es, vorrangig einen Überblick darüber zu erhalten was die Teammitglieder am vorigen Tag getan haben, woran sie heute arbeiten werden und was sie in ihrer Arbeit behindert. So sorgt das Daily für Transparenz und die Möglichkeit für die Teammitglieder sich optimal zu unterstützen und Abhängigkeiten zu erkennen. Das Daily ist insbesondere kein Statusmeeting für den Product Owner oder gar den Scrum Master. Es ist streng darauf zu achten, dass Dailys die vereinbarte Zeit, optimalerweise 15 Minuten, nicht überschreiten.

Sprint Review

Im Sprint Review, am Ende eines jeden Sprints, präsentiert das Entwicklungsteam das fertiggestellte Produkt Inkrement.

Das Ziel des Sprint Reviews ist die Synchronisation aller Beteiligten über den aktuellen Stand der Arbeiten (keine Folien). Somit wird eine Entscheidungsgrundlage über die folgenden Produkterweiterungen für das Planning I gelegt.

Der Sprint Review kann für einen zweiwöchigen Sprint innerhalb von 30-60 Minuten durchgeführt werden. Eine detaillierte Vorbereitung und Abstimmung im Entwicklungsteam von maximal einer Stunde ist dabei angeraten.

Sprint Retrospektive

User Stories

User Stories sind eine umgangssprachliche Beschreibung der vom Markt gewünschten Funktionen. Die vom Product Owner zu schreibenden und zu priorisierenden User Stories sind üblicherweise in folgender Form geschrieben:

Als <Nutzer Rolle> will ich <gewünschtes Ziel> damit <Nutzen/Grund>

Beispiel einer User Story eines fiktiven Online Shops:
Als Kunde möchte ich in meiner Rechnung alle die von mir bestellten Produkte sehen, so dass ich eine Quittung über den Kauf, zur möglichen Regulierung von Garantiefällen habe.

Neben dieser Beschreibung brauchen User Stories sogenannte Akzeptanzkriterien. Hier am Beispiel des Online Shops:

Rechnungen sind internationalisiert (Sprachen sind zunächst Deutsch und Englisch)
Die Rechnung enthält die Rechnungsnummer
Die Rechnung wird als PDF bereitgestellt
…

Beim schreiben guter User Stories kann man sich an das Wort INVEST anlehnen. Gute User Stories sind Independent, Negotiable, Valueable, Estimable, Small and Testable.

Product Backlog

Produktinkrement

Definition of Ready

In der Definition of Ready (DoR) werden all die Kriterien gesammelt, die erfüllt sein müssen damit eine Story in den Sprint aufgenommen werden kann. In der DoR werden zum Beispiel folgende Punkte geprüft:

Die Story ist klar und verständlich geschrieben
Alle Teilaspekte der Story wurden mit dem Team besprochen und von diesem verstanden
Der Product Owner hat eine Priorisierung der Story vorgenommen
Das Team hat eine Schätzung abgegeben
Es wurden Akzeptanzkriterien (z.B. mindestens drei) genannt
Externe Abhängigkeiten wurden diskutiert

Planning Poker

Planning Poker ist eine Technik zur “Größenabschätzung” von Backlog Items (Stories, Tasks etc.), welche vor allem im Refinement und im Planning I Anwendung findet.

Der Grundgedanke hinter der Methode ist die relative Schätzung der Backlog Items. Planning Poker führt zu realistischen Einschätzungen des Teams und fördert durch die Diskussion der Schätzung und deren Hintergründe das gemeinsame Verständnis der Story im Team.

Bereits nach ca. 4-5 Sprints kann man erkennen wie viele Story Points ein Team im Sprint abarbeiten kann. Auf Basis dieser Erkenntnis ist es dann möglich, eine Releaseplanung durchzuführen.

Sprint

Definition of Done

Die Definition of Done ist eine Auflistung von Vorbedingungen welche erfüllt sein müssen, damit ein Backlog Item als fertig bezeichnet werden darf. Mit wachsender Erfahrung des Teams verändert sie sich im Laufe der Zeit. Die Definition of Done enthält unter anderen:

funktionale Anforderungen (“Die bereitgestellten Funktionen arbeiten wie gewünscht”)
nicht funktionale Anforderungen (“Die Antwortzeit muss unter einer Sekunde liegen”)
Prozessuale Bestandteile (“Freigabe durch den Product Owner ist erfolgt”)
Qualitätskriterien (“Code Review wurde durchgeführt”, “Test wurde erfolgreich durchgeführt” etc.)

Entwicklungsteam

“Ein Scrum Team besteht optimalerweise aus 4,6 Personen.”
Jeff Sutherland, in seinem Buch “SCRUM, The Art of Doing Twice the Work in Half the Time”

Ein Scrum Entwicklungsteam besteht heute dennoch meist aus 6-9 selbstorganisiert arbeitenden Personen.

Die Mitglieder eines Entwicklungsteams haben gemeinsam das Know-how, alle Aufgaben zur Produkterstellung durchzuführen. Dabei achten die Teammitglieder darauf, dass sich die jeweiligen Spezialisten (z.B. Frontend Entwickler) sich auch in anderen Bereichen (z.B. Test und Backend Entwicklung) mindestens oberflächlich auskennen (T Shape).

Scrum Master

Die Verantwortlichkeit für die Integration der Scrum Arbeitsweisen und Verfahren liegt beim Scrum Master. Er coacht dafür sowohl die Organisation, den Product Owner als auch die Team Mitglieder.

Der Scrum Master achtet auf die Durchführung der Aktivitäten im Rahmen der vereinbarten Zeiten (Timeboxing). Er stellt sicher, dass sich alle Team Mitglieder an die selbst getroffen Vereinbarungen halten. Er hilft dem Team erkannte Hindernisse zu beseitigen.

Der Scrum Master ist der Coach am Spielfeldrand. Er ist weder Mitspieler noch gibt er konkrete Vorgaben wie und welche Arbeiten erledigt werden sollen.

Er coacht die Team Mitglieder, verantwortet die Dokumentation des Fortschritts (Burn Down Chart) und hilft so dem Team qualitativ hochwertige Produkte zu erstellen.

Product Owner

Der Product Owner (PO) ist für die Ausgestaltung und somit den wirtschaftlichen Erfolg (ROI) des Produktes verantwortlich. Der Product Owner schützt das Entwicklungsteam durch seine Funktion (neben dem Scrum Master) gegenüber störenden Eingriffen weiterer Stakeholder.

Der PO ist bevollmächtigt endgültige Entscheidungen über das Produkt, seine Merkmale und die Reihenfolge der Implementierung zu treffen.

Der PO ist somit der Ansprechpartner für das Entwicklungsteam bei der Frage, welche Produkteigenschaften in welcher Reihenfolge entwickelt werden sollen. Um diese Funktion optimal wahrzunehmen, arbeitet der PO co-located beim Scrum Team und plant mindestens 60% seiner Zeit für die Arbeit am Produkt ein.

Zu diesem Zweck erstellt, priorisiert und managt er die Anforderungen im Product Backlog.

Der Product Owner überprüft ob die Arbeiten des Teams der Definition of Done entsprechen und somit als erledigt betrachtet werden können.

Ansprechpartner

Alena Walk

Ellen Lüsse

Kontaktformular und Anfahrt