.st0{fill:#FFFFFF;}

Scrum Guide

Das Sprint Ziel richtig nutzen!

 September 3, 2016

von  Sebastian

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 Reflektion (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

Ein paar Worte über den Autor

Agile Team Facilitator Sebastian Schneider
ICP-ACC Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

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.

  • Und was wenn in einem Sprint 4 Stories stecken und sich diese Thematisch an 4 verschiedenen Randbereichen des Produktes befinden? Wie findet man in so einem Fall ein Ziel?

    • Hallo Fred,

      was wäre das für ein konkretes Beispiel?

      Grundsätzlich sollte der Product Owner pro Sprint im Gedanken etwas haben, was am Ende des Sprints als Wert für den Kunden liefern möchte. Das Sprint Ziel ist das Ergebnis des ganzen Scrum Teams, muss folglich aber eine Richtung haben. Wenn das nicht geht, ist meine Vermutung pauschal (ohne das Beispiel zu kennen), dass entweder das Team nicht richtig geschnitten ist oder es Probleme mit der Priorisierung des Backlogs gibt. Vielleicht auch noch mal auf die Vision schauen…

      Viele Grüße
      Sebastian Schneider

      • Nehmen wir an unser Produkt wäre MS Word. Im Backlog befinden sich im Moment fünf Userstories:
        1) Kreditkartenverifizierung für Office365 Verlängerung
        2) Bug beim Ausklappen des Ribbon Menüs
        3) Eine neue Anzeige der Schriftarten
        4) Eine Mappingverbesserung beim PDF Export
        5) Das neue Firmenlogo im About Text

        Das Team schafft es sich im nächsten Sprint zu den ersten dreien zu committen.
        Ich würde kein eindeutiges Ziel formulieren können.

        • Das ist ein interessantes Beispiel. Also wenn ich die ersten drei Dinge lese, dann ist letztendlich 1) was (aus meiner Sicht) einen richtigen erlebbaren Kundenwert darstellt. Ist 1) komplett in einem Sprint zu erledigen? Ich bin ja ein Verfechter von User Stories (auch wenn sie nicht verplichtend sind) aber ich könnte mir unter dem Aspekt vorstellen, dass „Verifizierung von Kreditkarten“ als Ziel nehme (oder ähnlich) und dazu dann aber mehr als ein Product Backlog Item für 1) verfügbar ist (kann sein, muss nicht. Hängt vom Team, vom Inhalt, Sprintlänge etc ab). Ich persönlich nutze auch Ziele wie „Verifizierung von Kreditkarten“ und erlaube es, dass es die ein oder andere (wichtige und priorisierte) Aufgabe gibt, die im Sprint getan wird, aber nicht 100% auf das Ziel einzahlt. Also könnte 2 & 3 mit drin sein. Das Sprint Ziel muss auf die Vision einzahlen, insofern auch da noch mal gegen checken.

          Wenn ich mir nun alle Items (1-5) ansehe, dann werde ich das Gefühl nicht los, dass es sich aktuell um eine Art „Maintenance“ oder „Verbesserungsphase“ handelt. Kann das sein? Wenn ja, das wäre zum Beispiel ja auch ein Ziel das nutzbar wäre. Ist 1) nun wirklich so klein, dass es problemlos umgesetzt werden kann als ein Item, dann würde mich interessieren, wie lange die Sprints sind – denn kann sich das Team wirklich nur auf drei Items committen? Ich würde nachbohren und tippen das Item 1 größer ist (wenn es jetzt nicht Auslagern über API an Drittanbieter ist und trivial damit wird) – aber auch dann, ist zu wenig im Sprint. Dann schauen, ob mehrere Items möglich sind, die vielleicht doch auf ein Ziel einzahlen.

          Hilft das?

  • Danke für Ihre ausführliche Antwort. Sie hilft mir soweit weiter, als dass ich es zur weiteren Reflexion mit in mein Team nehmen werde.
    Schöne Grüße

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

    __CONFIG_colors_palette__{"active_palette":0,"config":{"colors":{"62516":{"name":"Main Accent","parent":-1}},"gradients":[]},"palettes":[{"name":"Default Palette","value":{"colors":{"62516":{"val":"var(--tcb-skin-color-0)"}},"gradients":[]}}]}__CONFIG_colors_palette__
    Hier gehts lang!
    >

    Psssst - hier gibts was sehr cooles!

    Der Scrum Newsletter

    Willst du mal schauen? :-)