Das Sprint Backlog ist ein kleines Mysterium. Eigentlich ist es ein so zentraler Teil von Scrum (und ähnlichen Ansätzen), dass jeder der schon einmal mit diesem Framework gearbeitet hat es kennen sollte, andererseits dürfte man aber bei den meisten Teams eher Ratlosigkeit verursachen wenn man danach fragt. Bestenfalls kommt irgendwann die Erkenntnis, dass das die Arbeit ist "die man in den Sprint zieht". Das ist auch nicht falsch, aber auch nicht ganz richtig. Es ist mehr als nur das.

Um mit dem Offensichtlichsten zu beginnen: genau wie im Fall des Product Backlog hat auch das Sprint Backlog im Englischen eine Bedeutung die sich problemlos ins Deutsche übersetzen lässt. Es ist das Backlog des Sprints, also der Rückstau (→ Backlog) unerledigter Arbeit, der während des nächsten Umsetzung-Zeitraums (→ Sprint) abgearbeitet werden muss. Das klingt zunächst banal, hat bei näherer Betrachtung aber Folgen, und zwar sowohl in Bezug auf die Größe als auch in Bezug auf die Darstellung.

Beginnen wir mit der Grösse. Um im nächsten Sprint abgearbeitet werden zu können darf der Rückstau nicht grösser sein als die Arbeitskapazität des Team in dieser Zeit. Auch das klingt banal, hat aber weitreichende Implikationen. Es verhindert, dass Wunschlisten undefinierbarer oder ausufernder Grösse in die Umsetzung gegeben werden und erzwingt eine Reduzierung auf das Wesentliche, da ja am Sprintende ein benutzbares Ergebnis stehen soll. Das gilt zwar theoretisch auch im klassischen Projektmanagement, in dessen grossen Releaseplanungen fällt "die eine zusätzliche Anforderung" aber oft nicht auf. Die maximal vierwöchigen Sprints erzwingen eine wesentlich grössere Disziplin.

Nun zur Darstellung. Selbst wenn Teams den Begriff des Sprint Backlogs kennen verwechseln sie ihn häufig mit der Summe aller Arbeit die im Sprint ist. Auch hier hilft eine Erinnerung an die Übersetzung: der Rückstau (→ Backlog) ist eben nicht "alles auf dem Board" sondern lediglich das was noch unberührt auf seine Erledigung wartet. Vereinfacht gesagt könnte man demnach alles was noch im To Do-Bereich ist als das Backlog bezeichnen, oder noch stärker vereinfacht - das Sprint Backlog ist der linke Teil des Boards.

Zusammengenommen ergibt sich aus diesen beiden Aspekten noch ein dritter, nämlich der der Planbarkeit, bzw. Prognostizierbarkeit. Da von einem Sprint mit fortschreitender Zeit immer weniger Tage übrigbleiben muss zwangsläufig auch das Backlog immer weiter schrumpfen wenn es noch umsetzbar bleiben soll. Das kann entweder dadurch passieren, dass nach und nach immer mehr Arbeit erledigt (und damit aus dem Rückstau/Backlog entfernt) wird, es kann aber auch heissen, dass Aufgaben wieder aus dem Sprint herausgenommen werden müssen¹ um ihn wieder erfolgreich abschliessbar zu machen.

Wer schon einmal in komplexen Entwicklungsprojekten gearbeitet hat dürfte mittlerweile ahnen, dass ein Sprint Backlog durchaus anspruchsvoll zu erstellen ist. Es soll in wenigen Wochen umsetzbar sein, ein brauchbares Ergebnis erzeugen, schrittweise abzuarbeiten sein und eine im Zweifel modifizierbare Grösse haben? Wie soll das gehen? Die kurze Antwort: durch schlankes, flexibles, ergebnisorientiertes und in Kommunikation eingebettetes Formulieren von Anforderungen. Mögliche lange Antworten stehen hier, hier, hier und hier.