Theorie "Sprint Backlog"

Das Sprint Goal: Die Verbindung zwischen Sprint Planning Meeting und Sprint Backlog?¶

Im vorherigen Kapitel haben Sie gelernt, dass das Sprint Goal feststehen muss, bevor das Sprint Planning Meeting beendet ist. Doch das Sprint Goal zieht sich wie ein roter Faden vom Sprint Planning Meeting durch den gesamten Sprint – denn das Sprint Goal ist wortwörtlich das einzige Ziel des Sprints. Zwar werden während des Sprints User Stories abgearbeitet, doch nur mit dem Ziel das Sprint Goal zu erreichen und den Sprint damit erfolgreich abzuschließen. Das Sprint Goal spielt aber nicht nur während des Sprint Planning Meetings und während des Sprintings eine zentrale Rolle – auch für das Sprint Backlog ist das Sprint Goal essentiell. Denn: Das Sprint Goal ist das Commitment, welches zum Artefact "Sprint Backlog" gehört.

Das Sprint Goal als Commitment soll das Scrum Team dazu ermutigen an einem Strang zu ziehen und es schafft eine gemeinsame Vision. Nach der Erarbeitung wird es in den Sprint Backlog aufgenommen und dient den Developern als Zielvorgabe, auf welche sie fokussiert zuarbeiten können, getreu dem Motto: Ein Ziel, welches man sieht, kann man besser treffen, als eines, welches man nicht sieht. Doch das Sprint Goal ist nicht nur für die Developer wichtig, auch Stakeholder haben ein berechtigtes Interesse am Sprint Goal, denn dieses spiegelt wider, weswegen ein Sprint wertvoll für sie ist und sie können den Mehrwert des Sprints auf einem Blick sehen.

Ihr ausformuliertes Sprint Goal sollte Ihnen immer diese Frage beantworten: Warum wird dieser Sprint durchgeführt?

Beispiele von Sprint Goals sind:

• Suchfunktion auf Website integrieren: Warum ist das sinnvoll? Nur so können potenzielle Kunden die Website durchsuchen.
  
• Bezahlung via PayPal ermöglichen: Warum ist das sinnvoll? Kunden können auf diese Art und Weise einfach bezahlen und das Unternehmen kann damit Geld verdienen.
  
• Weblearning-Konzept erarbeiten: Warum ist das sinnvoll? Basierend auf dem Konzept können die Inhalte erstellt werden.

Probleme mit Sprint Goals¶

Bei der Formulierung des Sprint Goals beantworten Sie sich die Frage, warum Sie den Sprint überhaupt durchführen und wieso es sich lohnt ihn durchzuführen. User Stories oder PBIs sind kein Sprint Goal – dieses sollte weiter gefasst sein, aber dennoch die Richtung vorgeben. Wird ein Sprint Goal jedoch als zu umfangreich formuliert, treten Probleme auf: Es könnte sein, dass die Developer das Sprint Goal nicht erreichen können, was dazu führen kann, dass der Sprint abgebrochen wird. Wenn das Sprint Goal jedoch zu vage beschrieben ist, kann es passieren, dass die Developer dieses Ziel aus den Augen verlieren und nicht darauf zu arbeiten. Problematisch wird es auch, wenn die Developer den Sinn des Sprint Goals nicht vor Augen haben und die Motivation dadurch sinkt.

Daher ist es wichtig, das Sprint Goal direkt "richtig" zu formulieren und dafür können Sie sich an der SMART-Formulierung orientieren.

Die Lösung: Das Sprint Goal sollte SMART sein¶

Sie kennen es bestimmt schon von Ihren vorherigen Projekten oder anderen Tätigkeiten: Ziele müssen SMART sein – und so verhält es sich auch beim Sprint Goal. Es sollte spezfisch (specific), messbar (measurable), erreichbar (achievable), relevant (reasonable) und terminiert (time-bound) sein.

Specific

Was soll erreicht werden?

Measurable

Wie wird gemessen, ob das Ziel erreicht wurde? Legen Sie vorab fest, wie Sie das Sprint Goal planen zu messen.

Achievable

Das Sprint Goal sollte weder unter- noch überfordern. Es muss erreichbar sein.

Reasonable

Die Umsetzung sollte für Kunde / Stakeholder relevant, aber auch aus Sicht der Developer sinnvoll sein.

Time-bound

Ein Sprint ist grundsätzlich terminiert, d. h. das Ende ist vorgegeben.

Wie geht es nach dem Sprint Planning Meeting weiter?¶

Am Ende des Sprint Planning Meetings ist allen Teilnehmenden das Sprint Goal bekannt und die ausgewählten User Stories, die umgesetzt werden müssen, um dieses Sprint Goal zu erreichen sind geschätzt und in Tasks unterteilt. Die Tasks wurden in den Sprint Backlog - z. B. in Form eines Scrum-Task-Boards - übertragen. Dieses wird täglich aktualisiert wird, sodass darüber im Daily Scrum gesprochen werden kann. Die Akutalisierungen und ggf. Änderungen werden von den Developern durchgeführt. Der Sprint Backlog soll an einer gut sichtbaren Stelle – im Büro oder virtuell – angebracht sein. Somit ist jederzeit ersichtlich, wo sich der Sprint gerade befindet, welche User Stories gerade bearbeitet werden und welche Tasks noch erfüllt werden müssen. So behalten die Developer einen Überblick, über den gesamten Sprint.

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.

Aufbau des Sprint Backlogs¶

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 – ähnlich wie beim Product Backlog. 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". So lässt sich jederzeit gut visualisieren, woran gerade gearbeitet wird. Spätestens wenn die Developer über verschiedene Standorte verteilt sind, sollte man über den Einsatz eines softwarebasierten Sprint Backlogs nachdenken.

Wieso ist ein Sprint Backlog sinnvoll?¶

Durch die Verwendung eines Sprint Backlogs können die Developer direkt erkennen, wo der Sprint sich gerade befindet, außerdem können sie den Sprint Backlog nutzen, um basierend darauf die Fragen im Daily Scrum zu beantworten. Durch die Visualisierung erkennen die Developer auch, wenn sich Tasks zu lange in der Spalte "Work in Progess" befinden. Wenn Tasks sich außergewöhnlich lange in dieser Spalte befinden, sollten sich die Developer fragen, weswegen dies der Fall ist. Wurde der Task falsch eingeschätzt? Liegen Probleme vor? Ist ersteres zutreffend, dann können die Developer diese Information nutzen, um in nachfolgenden Sprints ihre Schätzfähigkeiten zu verbessern. Falls Probleme vorliegen, muss im Daily Scrum darüber gesprochen werden, um diese Hindernisse zu beseitigen und den oder die Developer zu unterstützen. Ein weiterer Vorteil einer guten Implementierung eines Sprint Backlogs besteht darin, dass Scope Creep verhindert wird.