5 2 Stimmen
Artikel-Rating

In meiner Arbeit als Agile Coach und Scrum Master erlebe ich immer wieder, dass Scrum Teams daran scheitern, ein (gutes) Sprintziel zu formulieren. Denn ganz so einfach, wie es beispielsweise im Blog von t2informatik steht, ist es in der Praxis leider selten.

Das eigentliche Problem ist, dass das Sprint Backlog bereits so durcheinander ist, dass ein Sprintziel gar keinen Sinn mehr ergibt. Und dann ist es nicht mehr als ein Schleifchen, das ein Team um seine Aufgaben wickeln möchte.

Das Phänomen

Die allermeisten Scrum Teams scheitern im Sprint Planning daran, ein gutes Sprintziel zu formulieren. Ironischerweise hat dieses Phänomen seinen Ursprung jedoch bereits im Product Backlog, da sich dort eine Vielzahl an unterschiedlichen Projekten und Anforderungen wiederfinden und zu einer Ursuppe aus Hotfixes, Eskalations-ToDo’s und Deadlines vermischen.

Im Ergebnis bedeutet dieser Zustand, dass sich diese Ursuppe im Sprint Planning vom Product Backlog auf das Sprint Backlog überträgt. Das Sprint Backlog dieser Teams besteht dann schlichtweg aus dem gleichen Mischmasch aus Anforderungen, Projektaufgaben und ToDo’s.

In einer fragwürdigen Abschluss-Zeremonie des Plannings wird dann ein Sprintziel formuliert, um aus diesem Konglomerat aus User Stories ein Ganzes zu postulieren, das gar nicht existiert.
0
Kommt Dir bekannt vor? Wie gut gelingt es Eurem Team aktuell, Sprintziele zu formulieren?x

Das Sprintziel ist dann nur noch ein nettes Schleifchen, das man um ein Gesamtpaket schnürt, weil man in Scrum ja ein Sprintziel formulieren soll.

5 Hotfixe für Dein Product Backlog, um gute Sprintziele zu formulieren

Wenn Du als Product Owner in einer ähnlichen oder identischen Situation bist, kannst Du über eine verbesserte Sortierung Deines Product Backlogs darauf hinarbeiten, die Formulierung eines sinnvollen Sprintziels einfacher zu machen. Dazu gibt es fünf Hotfixes, die ich Dir hier kurz vorstellen möchte.

Hotfix 1: Sortiere Dein Product Backlog auf Feature-Ebene

Zuallererst solltest Du Dein Product Backlog nicht mehr nur auf Ebene Deiner User Stories zu priorisieren, sondern auch auf Feature- bzw. Epic Ebene. Viele Product Owner nutzen übergreifende Elemente im Product Backlog wie Feature oder Epic lediglich als Container oder „Klammer“ für User Stories. Und so wandern dann (logischerweise) 3 User Stories zu Feature 1, 4 User Stories zu Feature 2 und 4 User Stories zu Feature 3 in das Sprint Backlog.

Hotfix 2: Lege ein WIP-Limit für aktive Features (und Epics) fest

Genauso wie Dein Sprint ein WIP-Limit für die Anzahl gleichzeitig bearbeiteter User Stories ist, solltest Du für Dich als Product Owner ein WIP-Limit für Features und/oder Epics festlegen, damit Du nicht alles gleichzeitig machst. In der Regel wirst Du dieses WIP-Limit anfangs reißen, da bereits viele angefangene Features (oder Projekte) in Deinem Product Backlog sind.

Wenn Du jedoch angefangene Features konsequent abschließt, bevor Du neue beginnst, kannst Du aktiv darauf hinarbeiten, Dein WIP-Limit zu erreichen. Der Kanban-Grundsatz „Stop starting, start finisishing“ gilt also auch für Features und Epics.

Ich will anders arbeiten!

Scrum, Kanban & agiles Produktmanagement

Du möchtest Scrum in Deinem Unternehmen oder Deinem Team einführen, weißt aber nicht wie Du vorgehen sollst? Du hast von Kanban gehört, weißt aber nicht, wo Du starten solltest? Du möchtest Dein Unternehmen mit Objectives & Key Results agiler machen? Wir beraten Dich gerne!

Ich will anders arbeiten!

Hotfix 3: Could-Have Features

Nicht immer wird es notwendig sein, alle zunächst angedachten User Stories eines Features auch umzusetzen. Stellt sich heraus, dass andere Features mehr Nutzen für Kunden stiften als ein angefangenes Feature, solltest Ihr die Arbeit daran beenden.

In diesem Fall ist es eine gute Praxis, die restlichen User Stories in eine Art Could-Have-Feature zu verschieben. Sowohl das Could-Have-Feature als auch die dazugehörigen User Stories im wandern im Product Backlog ganz nach unten. (Das ursprüngliche Feature kann dann geschlossen werden und das neue, wichtigere Feature gestartet werden.)

Hotfix 4: Priorisiere erst auf Feature-Ebene und dann auf User-Story-Ebene

Sortiere Dein Produkt Backlog zunächst auf Feature-Ebene, um für mehr Einheitlichkeit im Sprint Backlog zu erreichen. So sorgst Du dafür, dass bestenfalls nur ein einziges Feature pro Sprint bearbeitet wird.

Wenn Du diese Praxis lange genug umgesetzt, wird Dir die nachfolgende Priorisierung von User Stories sehr viel leichter fallen. Der Weg zum gut formulierten Sprintziel ist dann nur noch der letzte Schritt auf diesem Weg.

Hotfix 5: Experimentiere mit der Umsetzung kleiner Feature-Elemente

Sehr häufig finden neue Features ihren Weg durch die Forderungen wichtiger Stakeholder in das Product Backlog. Diese sind dann in der Regel extrem umfangreich und der potenzielle Nutzen für den Kunden ist eher geraten als gewusst. Verfolgst Du den Ansatz des Evidence-Based Managements, ist es eine gute Praxis, von angeforderten Features (die eigentlich eher Epics sind) nur einen kleinen Teil umzusetzen. So kannst Du anhand zuvor festgelegter Kriterien überprüfen, ob sich der Aufwand überhaupt rechnet.

Hier kannst Du für diese Mini-Features Hypothesen formulieren, die erst validiert werden müssen, damit das gesamte Feature umgesetzt wird. Die Validierung eines Features ist im Übrigen ebenfalls ein hervorragendes Sprintziel.

Fazit

Mit einem gut priorisierten Product Backlog, das nicht nur auf User-Story-, sondern auch auf Feature- & Epic-Ebene sortiert ist, kannst Du als Product Owner sehr viel dazu beitragen, das Formulieren von Sprintzielen deutlich einfacher zu machen.

Neben meinen 5 Hotfixes gibt es sicherlich noch einige weitere Möglichkeiten, die ich hier nicht erwähnt bzw. vergessen habe. Schreib mir doch einen Kommentar, wie gut es Dir und Deinem Team aktuell gelingt, Sprintziele zu formulieren. Ich bin gespannt, welche Kniffe Ihr angewendet habt, um diesen Zustand zu erreichen.