Angenommen, unser Backlog ist gepflegt und priorisiert und das Planning gut vorbereitet. Im Planning wird dann zwischen Product Owner und Entwicklungsteam besprochen, was in den nächsten Sprint mitgenommen wird. Daraus ergeben sich das Sprintziel und die zu implementierenden Backlog Items. 

Warum passiert es dennoch so häufig, dass wir unser Sprintziel, auf das wir uns so eifrig committed haben, verfehlen? Ein Grund könnte sein, dass wir das Sprint Planning mit einer unsortierten Liste an Backlog Items beenden. Die Abarbeitung der Items verläuft dann nicht zwingend von oben nach unten ab, das Entwicklungsteam bearbeitet die aus ihrer Sicht „spannendsten“ Themen zuerst.

Eine Lösungsidee

Das Sprint Backlog sollte sich wie das Product Backlog verhalten. Beispielsweise lassen sich folgende Punkte sehr gut zur Bewertung der Wichtigkeit eines Items heranziehen: Value, Komplexität, Abhängigkeit und Testaufwand. 

• Value: Gibt es ein Kernfeature in diesem Sprint? Worauf wird sich der Kunde am meisten freuen, nach was sehnt er sich am meisten? Was bringt meinem Produkt die größte Wertsteigerung (durch den glücklichen Kunden)?
• Komplexität: Welches Item ist am komplexesten umzusetzen und bedeutet den meisten Aufwand und Gehirnschmalz? In welchem Item sehen wir das größte Risiko bei der Umsetzung? Bei welchem Item benötigen wir vermutlich länger zur technischen Einarbeitung? Welche Kleinigkeiten können wir für das Sprintende aufheben, um wenig Story Punkte zu verlieren, falls wir uns verplant haben?
• Abhängigkeiten: Sind wir bei der Umsetzung abhängig von anderen? Sind andere von diesem Item abhängig? Zugegeben, schlechte Lage, manchmal aber nicht vermeidbar, vor allem, wenn man teamübergreifend an einer Schnittstelle arbeitet. Sind andere von uns abhängig, sollten wir sicherstellen, auch fristgerecht zu liefern, das heißt, das Item mit als erstes fertigzustellen. 
• Testaufwand: Oft erleben wir es, dass Tester*innen vernachlässigt werden und erst ganz am Schluss eines Sprints ihre Tests durchführen und anpassen können. Wichtig beim Planning ist es, die Tester*innen zu involvieren und zu wissen, bei welchen Items sie die größten Testaufwände sehen, für die mehr Zeit benötigt wird. 

Investiert 5 Minuten in eure Sprint Backlog Priorisierung

Wenn wir wissen, welche Items uns am wichtigsten sind, fokussieren wir uns auf diese und es tut uns am Sprintende weniger weh, falls wir doch mal was liegen lassen müssen – vorausgesetzt, dass wir diese sortierte Liste im Sprint von oben nach unten abarbeiten. Zudem sollte damit das Sprintziel nicht in Gefahr sein, da alle dem Sprintziel zuträglichen Items hoch priorisiert sind. Das hilft uns schlussendlich ein positives Erlebnis für uns und die Stakeholder im Review zu schaffen, eine verlässliche Velocity aufzubauen und den Product Owner in seinen planerischen Tätigkeiten zu unterstützen.

von Carolin Neufert