Zum Inhalt

Übungen "Sprint Backlog"

Zusammenfassung

Hier finden Sie die Definitionen der wichtigsten Begrifflichkeiten aus diesem Kapitel.

Sprint Backlog

Der Sprint Backlog ist eine Auflistung von Aufgaben oder Aktivitäten, die im kommenden Sprint durchgeführt werden sollen. Das Commitment zum Sprint Backlogs ist das Sprint Goal. Einträge für den Sprint Backlog werden aus dem Product Backlog entnommen. Developer sind für den Sprint Backlog verantwortlich, Änderungen können aber nur durch Product Owner vorgenommen werden. Der Sprint Backlog sollte für jeden sichtbar im Büro aufgehängt werden, alternativ bietet sich die Nutzung eines softwarebasierten Sprint Backlogs an

Sprint Goal

Für jeden Sprint wird während des Sprint Plannings ein Sprint Goal definiert, basierend darauf definiert sich der Inhalt des Sprint Backlogs. Das Sprint Goal wird vom Product Owner formuliert und es dient den Developern als Zielvorgabe. Das Sprint Goal ist die Verpflichtung (= das Commitment) der Developer zum Sprint Backlog. Es sollte SMART formuliert sein und die Frage beantworten: Warum wird dieser Sprint durchgeführt?

Daily Scrum (= Daily Stand-up Meeting)

Das Daily Scrum ist eine 15-minütige, tägliche Veranstaltung für die Developer. Während des Meetings wird der Fortschritt zum Sprint Goal überprüft und, falls nötig, das Sprint Backlog angepasst. Die geplanten und anstehenden Arbeiten werden untereinander abgestimmt. Das Daily Scrum verbessert die Kommunikation, identifiziert Impediments und fördert eine schnelle Entscheidungsfindung.

Impediments

Impediments sind Hindernisse, bzw. Störungen, die Teammitglieder oder das Team daran hinderen vernünftig zu arbeiten und damit das Erreichen des Sprint Goals gefährden.

Sprint Planning Meeting

Jeder neue Sprint beginnt mit dem Sprint Planning Meeting. Während des Meetings wird die Arbeit festlegt, die während des neuen Sprints durchgeführt werden soll. Das Endergebnis ist ein Plan, welcher in Zusammenarbeit mit dem gesamten Scrum Team erstellt wird. Das Meeting ist auf maximal acht Stunden für einen einmonatigen Sprint zeitlich begrenzt, bei kürzeren Sprints in der Regel entsprechend kürzer. Angesprochene Themen:

  • Warum ist dieser Sprint wertvoll?
  • Was kann in diesem Sprint erledigt werden?
  • Wie soll die ausgewählte Arbeit erledigt werden?

Übungsfragen

Bitte beantworten Sie die folgenden Fragen selbstständig. Nehmen Sie sich Zeit und überlegen Sie genau, was Sie antworten würden, bevor Sie sich die Lösungen anzeigen lassen.

Welche Frage sollten Sie sich bei der Erstellung des Sprint Goals stellen?

Warum wird dieser Sprint durchgeführt?

Was geschieht, wenn das Sprint Goal nicht erreicht wird / werden kann?

Falls während der Bearbeitung des Sprints die Ergebnisse nicht dem Sprint Goal entsprechen, können die Developer mit dem Product Owner den Fokus des Sprints ggf. neu verhandeln.

Wer darf das Sprint Goal während eines Sprints ändern?

Das Sprint Goal darf während des Sprints von niemandem geändert werden. Der Fokus der Sprints darf jedoch in Abstimmung mit dem Product Owner geändert werden. Außerdem kann der Prouct Owner den Sprint abbrechen, falls das vorher festgelegte Sprint Goal osoblet geworden ist.

Welches Akronym sollten Sie bei der Erstellung des Sprint Goals im Hinterkopf behalten? Wofür steht es?

Das Sprint Goal sollte "SMART" formuliert sein. SMART steht für spezfisch (specific), messbar (measurable), erreichbar (achievable), relevant (reasonable) und terminiert (time-bound).

Was ist der Sprint Backlog?

Der Sprint Backlog

  • ist die Liste der Product Backlog Items, die im laufenden Sprint bearbeitet werden sollen,
  • besteht aus Einträgen, die jeweils aus dem Product Backlog entnommen werden,
  • ist die Beschreibung der technischen Maßnahmen (Tasks) zur Umsetzung und Implementierung (z. B. Design, Architektur, Programmierung, Testing und Refaktorierung),
  • unterliegt der Verantwortung der Developer, da diese eine Vorhersage der Funktionalitäten treffen, die erarbeitet werden sollen,
  • ist für alle sichtbar im Büro angebracht. Die Wartung und Aktualisierung erfolgt rechtzeitig zum Daily Scrum,
  • dient der Visualisierung des Fortschritts.
Wer ist für die Erstellung des Sprint Backlogs verantwortlich?

Verantwortlich für die Erstellung und die Wartung des Sprint Backlogs sind die Developer.

Wer darf Anpassungen am Sprint Backlog während des Sprints machen?

Die Developer können Änderungen am Sprint Backlog durchführen, wenn z. B. während des Sprints festegestllt wird, dass ein Task aufwändiger ist, als im Vorfeld geschätzt.

Wie kann der Sprint Backlog am besten dargestellt werden, bzw. wie ist er aufgebaut?

Der Sprint Backlog ist in vier Spalten unterteilt. Ganz links sind alle User Stories aufgelistet, die im vorangegangen Sprint Planning Meeting ausgewählt wurden. Ganz oben findet sich die User Story, die am höchsten priorisiert ist, je weiter unten die User Stories im Sprint Backlog stehen, desto weniger hoch sind sie in Ihrer Priorität. Rechts daneben in der To-Do-Spalte stehen die Arbeiten, die sogenannten Tasks, welche für die Umsetzung der jeweiligen User Story in ein Increment notwendig sind. Die Tasks sind so angeordnet, wie die Developer sie im Sprint Planning Meeting bestimmt haben. Eine Spalte weiter wird aufgeführt, was gerade getan wird. Hierfür wird häufig die Abkürzung "WIP" genutzt, was für Work in Progress steht. In der ganz rechten Spalte sind die erledigten Arbeiten gelistet. Die Spalte heißt demnach "Done".

Wann sollte auf einen softwarebasierten Sprint Backlog zurückgegriffen werden?

Wenn die Developer über unterschiedliche Standorte verteilt sind, sollte ein softwarebasierter Sprint Backlog geführt werden.

Was bedeutet Scope Creep und was hat das mit dem Sprint Backlog zu tun?

Scope Creep bedeutet, dass während des Projektlebenszyklus die Anforderungen (engl. scope) an ein Projekt schleichend (engl. creep) und unkontrolliert mehr werden. In agil organisierten Projekten sind die Änderung und Anpassung von Anforderungen normal. Während eines Sprints gibt es jedoch ein Ziel – das Sprint Goal – und Tasks, die umgesetzt werden müssen. Das heißt, dass auch bei agilen Projekten, bezogen auf einzelne Sprints, Scope Creep auftreten kann. Wenn der Sprint Backlog aber gut geführt ist, dann wissen die Developer genau, was sie tun müssen, um die Tasks und damit die User Story umzusetzen.