Ich beobachte häufig, dass Backlog Items im Sprint nicht fertig werden. Betrachtet man im Nachgang die Schätzungen im Verhältnis zur Umsetzung und befragt das Team, ob sie die Schätzung noch mal so machen würden, stellt man fest: „Wenn wir nur das gemacht hätten, was in dem Item steht, hätte die Schätzung schon hingehauen.“ Kleinigkeiten hier und da zu ergänzen oder noch mal was zu refactoren, kostet am Ende mehr Zeit, als man denkt. Teilweise verliert man sich in Details und Edge Cases. Währenddessen warten andere für den Sprint vorgesehene Items sehnsüchtig auf ihre Umsetzung.

Gut geschriebene Backlog Items sind unerlässlich

Ein häufiger Grund ist die unzureichende Beschreibung der Backlog Items. Wie detailliert und präzise beschrieben das Backlog Item sein muss, ist abhängig vom Team und dessen Lernprozess dazu. Selbstverständlich ist es unabdingbar, den Nutzen des Backlog Items zu formulieren, sodass die Erarbeitung der Akzeptanzkriterien wesentlich einfacher fällt. 

Dazu eignet sich hervorragend das sogenannte Connextra Template. Das Schema “Als (Persona/Anwenderrolle) brauche ich (Funktion), um/damit (Nutzen).” Damit ist nachvollziehbar, für wen, was wozu entwickelt werden soll. Zur Beschreibung der sich daraus ableitenden Akzeptanzkriterien kann man sich an den INVEST-Kriterien orientieren (s. Wikipedia). 

Man kann sich immer fragen: “Was wird benötigt, um den Nutzen für den Anwender zu erreichen?“. Ich plädiere hier vor allem am Anfang dieses Lernprozesses für „Mehr ist mehr“. Das Team sollte lieber ein Akzeptanzkriterium mehr als zu wenig erfassen. Und warum beschreibt man nicht mal das, was man nicht machen möchte? So wird die Aufgabe klar von weiteren Backlog Items abgegrenzt und es wird verhindert, dass man mehr umsetzt, als das Backlog Item vorsieht.

Dem Backlog Item treu sein

Nachdem das Backlog Item gut beschrieben ist und vom Team als „ready“ eingestuft wurde, muss das Bewusstsein geschärft werden, sich an dessen Inhalt zu halten. Ein Backlog Item sollte grundsätzlich immer als unveränderlich im Sprint behandelt werden. Vermutlich könnten einige nun sagen: „Das ist doch nicht agil! Alles kann sich jederzeit verändern und man muss darauf reagieren!“ 

Das Team hat sich zusammen auf einen Plan für den Sprint festgelegt. Wenn die Items währenddessen einfach geändert werden, kann man nicht mehr einschätzen, welcher Mehrwert in dem Sprint geliefert wird. Das kann negative Konsequenzen auf zugesicherte Liefertermine haben. 

Folgende Fragen sollte man sich stellen, wenn während der Umsetzung von der Anforderung abgewichen wird: Hat sich die Kundenanforderung geändert? Ist diese Mehrarbeit wirklich wertsteigernd? Muss die Mehrarbeit genau jetzt getan werden, oder reicht es auch, sie später umzusetzen? Wer bezahlt die kleinen Extras, die wir jetzt zusätzlich machen? Das ist natürlich nur eine Auswahl an möglichen Fragestellungen und Problemen, die auftreten können. 

Sofern auf diese Fragen keine zufriedenstellende Antwort gefunden wird, dann muss die Mehrarbeit vermieden werden. Andernfalls kann mit dem Product Owner oder im ganzen Team darüber gesprochen werden, um zu entscheiden, was passieren soll. Es ist immer möglich, während der Entwicklung im Sprint gewonnene Erkenntnisse in neue Backlog Items zu gießen, die zur Wertsteigerung des Produktes beitragen oder aufgrund von technischer Notwendigkeit entstehen.

Verlässlichkeit durch genaue Vorhersagen der Umsetzungen

Wenn man sich an das oben beschriebene hält, und nur das, was im Backlog Item formuliert ist, umsetzt, dann ist die Schätzung eines Backlog Items brauchbar. Es ist ungemein hilfreich für die Auswertung einer Velocity und das Planen von Releases, verlässliche Zahlen zu haben. So kann man dem Kunden letztendlich das liefern, was ihm zugesichert wurde. Zuverlässige Lieferung und ein qualitativ hochwertiges Produkt sind die Basis für eine vertrauensvolle und produktive Zusammenarbeit mit den Kunden.

von Carolin Neufert