Priorisierung der Stories im Sprint?

Priorisierung im Sprint
Von Sebastian Schneider // 17.03.2017 // 1 Kommentare

Das Sprint Backlog in Scrum kommt mit einer indirekten, abgeleitet Priorisierung aus dem Product Backlog, gestützt mit der Fokussierung durch das Sprint Ziel und einer sinnvollen Priorisierung der Tasks an den User Stories.

Priorisierung im Sprint (Backlog)

Sehr wahrscheinlich kennst du die relative Priorisierung aus dem Product Backlog. Sie ist ein sehr wichtiges uns zentrales Mittel, um wertorientiert planen zu können. Weniger oft gefragt wird die Priorisierung im Sprint Backlog. Und genau dieser Priorisierung im Sprint Backlog widme ich mich hier einmal genauer.

Auf dem Weg zum Sprint Backlog

Wenn der Product Owner sein Product Backlog richtig verwaltet (wodurch er Scrum Coaching durch den Scrum Master bekommen kann, wenn das noch nicht so richtig klappt), dann hat er eine sortierte Liste, die damit auch eine Priorisierung darstellt.

Im Sprint Planning (Teil 1 und Teil 2) stellt leitet sich aus diesem Product Backlog eine Reihenfolge ab. Das Entwicklungsteam darf nicht sagen welche Product Backlog Items es gerne machen würde, sondern nur wie viele.

Auch wenn das Entwicklungsteam natürlich nicht mit Blut unterschreiben muss, dieses alles umzusetzen, geht doch ein gewisses Commitment (Scrum Wert) mit einher. Das Entwicklungsteam verpflichtet sich zum Liefern. Zum Glück gibt es da noch das Sprint Ziel, mit dem sich Product Owner und Entwicklungsteam übergreifend auf eine Richtung einigen können.

Wer stellt diese Frage?

"Müssen wir nun die Stories und Tasks im Sprint priorisieren?" kann von unterschiedlichen Stellen kommen. Vielleicht kommt dir die eine oder andere Art auch bekannt vor? Dann schau mal hier:

  • Das Entwicklungsteam: "Brauchen wir eine Priorisierung? Was ist, wenn wir etwas nicht schaffen?"
  • Product Owner: "Priorisierung im Sprint? Ist doch jetzt wohl hoffentlich klar!"
  • Manager (außerhalb Scrum Team): "Ich will jetzt aber mal genau wissen woran ihr arbeitet, was ist davon denn das wichtigste?"

Bevor wir das nun auflösen, ob und wenn ja wie, wir eine Priorisierung im Sprint benötigen, schauen wir uns nun etwas mehr die Details an.

Das Sprint Backlog

Im Sprint Backlog stehen nun alle für den Sprint umzusetzenden Product Backlog Items. Wir haben eine entsprechende Reihenfolge als auch implizit im Sprint Backlog (so gesehen, eine abgeleitete Reihenfolge).

Wertorientierte Planung

In Scrum folgenden wir einer wertorientierten Planung. Das bedeutet, wir richten unser Priorität immer nach dem Wert des Kunden aus. Das ist etwas anderes, als eine kapazitative Planung als Grundlage zu nutzen.

Reihenfolge der Tasks oder Backlog Items?

Schauen wir in das Sprint Backlog rein (nachstehende Folie) dann haben wir dort zwei Dinge, die uns zur Priorisierung im Sprint veranlassen können:

  • Die Reihenfolge aus dem Product Backlog, also das selected Backlog und
  • die Einträge (Aufgaben, Tasks) im Sprint Backlog, die das Entwicklungsteam sich erstellt hat.

Fokus!

Im Sprint Backlog haben wir die gleiche Priorisierung, die wir auch im Product Backlog haben. So kann das Entwicklungsteam nicht die Reihenfolge der Selected Product Backlog Items ignorieren. Insofern halten wir fest, die Priorisierung im Sprint Backlog ist aus Sicht der Product Backlog Items erst einmal gleich und verändert sich nicht.

Ich finde es - ebenso im Sinne des Fokus - auch wichtig schnell entscheiden zu können, welche Tasks oder auch Selected Product Backlogs (nach Rücksprache mit dem Product Owner) im Zweifelsfall fallen gelassen werden können. Das Sprint Ziel kann auch hier helfen und im Grunde werden es immer die untersten Product Backlog Items (die selektiert worden sind) sein, wenn es knapp wird. Auch hierbei gilt zum einen für die Product Backlog Items die Rücksprache mit dem Product Owner, die Freiheit innerhalb des Sprints obliegt dem Entwicklungsteam.

Freiheit des Entwicklungsteam

Innerhalb der Product Backlog Items hat das Entwicklungsteam frei Wahl. Es organisiert sich selbst und prüft dabei, wie genau es Product Backlog Items umsetzen kann. Wenn Task 1 vor Task 2 kommt ist das gut, solange das Product Backlog an erster Position weiterhin das wichtigste Element bleibt.

Abhängigkeiten

Für die Reihenfolge der Tasks (wie auch Product Backlog Items) gibt es immer drei Möglichkeiten, auf die du achten musst.

  • Chronologische Abhängigkeiten
  • Inner-Sprint Abhängigkeiten
  • Zusammengesetzte Abhängigkeiten

Während du die ersten beiden Abhängigkeiten mehr oder weniger so oder so über die Reihenfolge der Tasks und Product Backlog Items steuerst, ist der letzte Fall eine Situation, die du nicht möchtest. Zusammengesetzte Abhängigkeiten fördern nur phasenorientierte Pseudo-Agilität und ignorieren die INVEST Kriterien der User Stories bzw. Product Backlog Items.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>