Wie umgehen mit Backlog Items unterschiedlicher Granularität?

Die Granularität, oder auch Kleinteiligkeit, von Product Backlog
Items ist eine ständige Herausforderung für Product Owner. Manchmal
sind die Product Backlog Items zu groß oder man leider unter viel
zusätzlicher Verwaltungsarbeit, weil immer wieder ganze Pakete an
kleinteiligen Items repriorisiert werden müssen. Das zentrale Thema
der Folge ist also die Größe eines Backlog Items. Während der Scrum
Guide lediglich fordert, dass Einträge innerhalb eines Sprints
abgeschlossen sein sollten, empfehlen Dominique und Oliver eine
zusätzliche Regel: Ein Item sollte nicht mehr als die Hälfte des
Sprints in Anspruch nehmen. Diese Daumenregel hilft dabei, das
Risiko zu minimieren, dass sich ein einzelnes Item über den
gesamten Sprint zieht und zu wenig Spielraum für Anpassungen
bleibt. Doch Granularität ist nicht nur eine Frage der Planung,
sondern auch der langfristigen Produktstrategie. Items, die erst in
ferner Zukunft relevant sind, können zunächst grob formuliert sein.
Je näher der Umsetzungstermin rückt, desto feiner werden sie
definiert. Oliver betont, dass eine zu frühe Detailierung oft
überflüssig ist, weil sich Prioritäten im Laufe der Zeit ändern.
Das Zusammenfassen und Neuformulieren von Items kann deshalb ebenso
sinnvoll sein wie das Zerteilen größerer Einträge. Ein weiteres
Thema ist die Handhabung von Granularität im Sprint.
Unterschiedlich große Items innerhalb eines Sprints sind kein
Problem, solange sie alle einen Mehrwert liefern und das Team die
Zusammenhänge versteht. Eine gesunde Mischung aus kleinen,
mittleren und größeren Items kann sogar dabei helfen, besser zu
lernen und das Forecasting zu verbessern. Ein rein auf gleich große
Einträge ausgerichtetes Backlog – wie es beim No Estimates-Ansatz
oft gefordert wird – kann zwar die Vorhersagbarkeit erhöhen,
schränkt aber unter Umständen die Flexibilität ein. Die Diskussion
zeigt, dass Product Owner die Granularität ihrer Backlog Items
bewusst steuern sollten. Refinement-Aktivitäten sind notwendig, um
sicherzustellen, dass ein gemeinsames Verständnis im Team herrscht.
Dabei ist jedoch auch Mut zur Lücke gefragt: Nicht jedes Item muss
bis ins kleinste Detail ausformuliert werden. Gerade bei sehr
kleinen Verbesserungen kann es sinnvoller sein, sie direkt
umzusetzen, anstatt sie ins Backlog aufzunehmen. Letztlich ist die
optimale Granularität immer vom jeweiligen Produkt und Team
abhängig. Product Owner sollten sich bewusst machen, dass sie nicht
nur für den Inhalt des Backlogs verantwortlich sind, sondern auch
für seine Struktur und Handhabbarkeit.