Product Backlog ohne u.w.e.

Innerhalb des agilen Projektmanagements bezieht sich Product Backlog auf eine priorisierte Liste von Funktionalitäten. Sie gilt als „Artefakt“ innerhalb von Scrum. Die regelmäßige Priorisierung des Backlogs wird im Refinement durchgeführt. Im Refinement stellt der Product Owner dem Entwicklungsteam die User Stories vor, die er für den nächsten Sprint(s) vorsieht. Das Team und der Product Owner sprechen so lange über die jeweilige User Story, bis das Team offiziell sagen kann „wir haben verstanden“. Erst dann geht die Story ins Planning und kann in das Sprint Backlog aufgenommen werden.

Beim Refinement ist es wie beim Bier trinken, schmeckt die Krone und die ersten Schlucke noch hervorragend und erfrischend, so erwärmt sich mit der Zeit das Bier, Kohlensäure verfliegt und der Rest wird schal. Im Product Backlog entstehen mit der Laufzeit des Projekts oder der Produktentwicklung ebenfalls solche „schalen“ User Stories. Stories sie seit langem keine Priorität bekamen oder immer zu unklar waren. In den wenigsten Fällen besteht aber der Mut im Team und beim Product Owner sich von diesen Stories zu trennen, sie also zu löschen. Könnte sein, dass man sie nochmal braucht. Diese Stories werden u.w.e. Bei jedem Refinement nimmt man sie kurz auf und verwirft weiteres Gespräche darüber wieder. So kann ein Bodensatz im Backlog bestehen, der die Refinements ineffizient macht und den Wert des Backlogs falsch darstellt.

Seien Sie mutig. Trennen Sie sich von u.w.e-Stories. Wenn sie wirklich benötigt werden, werden sie automatisch aus den Anforderungen der Stakeholder entstehen und wieder ins Backlog wandern. Gestehen sie sich zu, dass alle Stories, die bei einer Sprintlänge von 4 Wochen mehr als 6 Monate im Backlog liegen, ohne in einen Sprint zu wandern, zu löschen. Nutzen Sie dabei z.B. auch die Indexierung von Tracking-Tools wie Jira. Sollten sie im Refinement Stories mit drei- oder vierstelligen Vorgangsnummer besprechen und dabei auf 2-Stellige treffen, so können sie sicher sein: das ist u.w.e.