Das Sprint Ziel richtig nutzen!

Von Sebastian Schneider // 03.09.2016 // 5 Kommentare

In Scrum stellt das Sprint Ziel einen Rahmen für die Umsetzung von Teilen des Product Backlogs. Es gibt dem Entwicklungsteam eine Orientierung, warum es das Inkrement erstellt und was die Erwartungshaltung bzw. die Zielsetzung konkret ist. Dabei ist das Sprint Ziel keine simple Aggregierung von Product Backlog Items, sondern nutzt eine abstraktere Sicht in einer verständlichen Sprache. 

Das Ziel vom Ziel

Das Sprint Ziel definiert den Nutzen, den ein Produktinkrement am Ende des Sprint erreicht. Das Sprint Ziel ist nicht die Summe der umzusetzenden User Stories. Ein Sprint Ziel schreibt den Nutzen des Produktinkrements in einer abstrakten Form, so ist es möglich das Sprint Ziel zu erreichen, auch wenn z.B. eine User Story getauscht wurde oder nicht umgesetzt wurden konnte.

Hilfreicher Fokus

Durch so ein Ziel hast du noch einmal die Möglichkeit, deinen Fokus zu schärfen. Es geht nicht mehr nur darum zu sagen, "wir machen jetzt mal diese 5 Product Backlog Items", sondern viel mehr einen weiten Blick, wie die Erwartungshaltung für den ganzen Sprint ist.

Verständlichkeit

Selbst als Außenstehender sollte ich das Sprint Ziel in Scrum immer verstehen. Das hat nichts mit Technik zu tun und ist keine Geheimsprache! So wird auch schnell Stakeholdern oder Produktfremden klar, um was es hier geht.

Transparenz, Inspektion & Adaption

Ein sauber definiertes Sprint Ziel hilft allen Beteiligten eine klare Transparenz über das Ziel und den Weg zum Inkrement zu bekommen. Damit eignet es sich auch für eine Inspektion und eine Reflexion (z.B. im Daily Scrum).

Schwierigkeiten

Kein Sprint Ziel möglich

Häufig sehe ich Teams, die tatsächlich nicht in der Lage sind, ein tatsächliches Ziel zu beschreiben. Das kann natürlich an unterschiedlichen Aspekten liegen, wie zum Beispiel:

  • Das Team ist kein Team und besteht aus Spezialisten, die alle für sich arbeiten und als Team tatsächlich kein Ziel aufstellen können.
  • Es existiert kein wirkliches Produkt Inkrement und das "Team" arbeitet nicht wirklich als Team und löst unterschiedliche Teile für ein Produkt.
  • List Element

Sprint Ziel ändert sich während des Sprints

Wir wollen keine Änderungen im Sprint, die das Ziel gefährden - so schreibt es der Scrum Guide. Ändert sich das Sprint Ziel häufig und ist da mit nicht der typische Sprintabbruch adressiert, wie ihn nur der Product Owner vornehmen darf, dann hast du ein anderes Problem: das Sprint Ziel ist zu detailliert und beschreibt sehr wahrscheinlich eher Product Backlog Items, als tatsächlich ein Ziel.

Ablauf zum Erstellen

Im Folgenden möchte ich dir kurz eine Übersicht geben, wie du in der Praxis direkt vorgehen kannst.

Diskussion über das Ziel

Das Entwicklungsteam, der Product Owner und der Scrum Master definieren gemeinsam das Sprint Ziel. Dabei gehen die Scrum Teams in der Regel so vor, dass der Product Owner ein solches Ziel als Vorschlag mit in das Team bringt. Dann wird mit dem Entwicklungsteam darüber diskutiert und im besten Falle gleich übernommen. Es kann auch vorkommen, dass das Entwicklungsteam kleine Anmerkungen hat oder das Sprint als utopisch ansieht - dann muss in die Verhandlung mit dem Product Owner gegangen werden. 

Sprint Backlog nutzen

Hänge das Sprint Ziel am besten direkt beim Sprint Backlog auf. Das hilft zum einen sehr im Sinne der Visualisierung - das Team schaut zwangsläufig immer jeden Tag (zu Beispiel im Daily Scrum) auf dieses Ziel und wird erinnert. Ach wenn dieser Aspekt oft als "lächerlich" oder "überflüssig" angesehen wird, ist es in meinen Augen sehr entscheidend.

Daily Scrum

Während das Entwicklungsteam das Daily Scrum abhält, kann es viel besser die drei Fragen im Daily Scrum auf dieses Sprint Ziel beziehen. Das gibt erneut einen Fokus und hilft in die richtige Richtung zu laufen.

Sprint Review

Ein guter Einstieg in das Sprint Review ist es, mit der Frage zu starten, ob das Sprint Ziel erreicht wurde. Das setzt den Rahmen und dann können die verschiedenen Parteien weiter in die Details einsteigen.

Sprint Retrospektive

Nicht immer, aber gerade wenn es nicht erreicht worden ist, eignet sich der Blick in der Retrospektive auf das Sprint Ziel. Wie oben angedeutet ist es im Sinne von Inspect & Adapt sehr wertvoll.

Beispiele

Machen wir noch ein Praxisbeispiel mit unterschiedlichen Blickwinkeln und Qualitäten. Das erstellen von guten Sprint Zielen musst du einfach im Team auch üben.

  • Ersten haptischen Prototypen für das neue Navigationsgerät erstellen
  • die Loginfunktionalität des Portals etablieren
  • Umgang mit Scrum lernen

Konkrete Product Backlog Items sollten dann bei dir nicht im Sprint vorhanden sein! Es soll konkret genug sein, dass die Richtung klar ist, aber weit genug, um keine Details festzulegen, die später geändert werden müssen.

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.

>