Ziele des Sprint Backlogs
Das Sprint Backlog sind alle User Stories für den laufenden Sprint, auf die sich das Team im Planungsmeeting committed hat. Im Prinzip stellt es den Umfang des kompletten Sprints dar. In Tools wie JIRA werden diese Tasks in der To-Do Lane angezeigt. Das Sprint Backlog sollte während des laufenden Sprints sich nicht verändern.
SCRUM Backlog
Umgang mit dem Sprint Backlog
Für das Sprint-Backlog gibt es keinen dedizierten verantwortlichen. Der Product Owner hat die Vollständigkeit der User Stories nach dem INVEST-Prinzip bereits während des Refinement-Meetings oder davor geprüft und das Team hat sich im Refinement-Meeting ebenso mit den User Stories vertraut gemacht.
Ratsam für das Team ist es, dass im Zuge des Refinement-Meetings zu jeder User Stories noch sogenannte Tasks angelegt werden. Diese beschreiben die technische Realisierung der User Story und sind als Unteraufgaben mit im Sprint-Backlog integriert. Hat ein Teammitglied eine Aufgabe erledigt, bedient er sich neuer Aufgaben aus dem Sprint-Backlog und weist sich das Ticket selbst zu und zieht es in die darauffolgende Lane, beispielsweise „in Progress“.
Wie erwähnt sollten nur solche User Stories in den Sprint aufgenommen werden, die durch das Team gereviewed, geschätzt und mit Tasks versehen wurden.
Die Summe aller User Stories, die im Sprint Backlog zu Beginn eines Sprints vorliegen, ist der „Startpunkt“ der Grafik im Sprint-Burndown.
Tipps für ein erfolgreiches Sprint-Backlog
Assignment
- Ein wesentlicher Ansatz von SCRUM und somit auch ein wesentlicher Vorteil gegenüber dem klassischen Wasserfallmodell ist es, dass unabhängig der einzelnen Person, die User Stories umgesetzt werden können sollen. Somit ist es ratsam, einzelne Stories im Sprint Backlog „unassigned“ also nicht einer Person zuzuweisen. Das gesamte Team ist dafür verantwortlich, dass der Sprint erfolgreich abgeschlossen wird. Bei Krankheiten, Urlauben etc. werden die Aufgaben durch andere Teammitglieder erledigt, was bei zugewiesenen Stories meist nicht funktioniert.
Vollständigkeit
- Spätestens bei der Umsetzung der User Stories während des Sprints, wird schnell verdeutlicht, wie sauber zuvor gearbeitet wurde. Nun stellt sich heraus, wenn Aufgaben nicht definiert wurden, die Akzeptanzkriterien unverständlich oder unvollständig beschrieben sind. Meist mit dem Resultat verbunden, dass User Stories nicht abgeschlossen werden können da Folgeaufgaben nicht rechtzeitig erledigt werden können.