Sprint Planning

​Das Sprint Planning

Scrum Sprint Planning

​Das Sprint Planning in Scrum ist das Event in dem der kommende Sprint geplant wird. Es teilt sich in der Regel in zwei Teile auf. Im ersten gibt der Product Owner an, was er gerne hätte. Im zweiten Teil bestimmt das Entwicklungsteam, wie es sich eine Umsetzung konkret vorstellt. Am Ende der Sprint Planung haben die Beteiligten ein gemeinsames Verständnis der umzusetzenden Arbeiten für den kommenden Sprint. Das Entwicklungsteam hat sich zudem auf den selbst bestimmten Umfang verpflichtet.

​Während es früher im Scrum Guide noch die "harte" Unterscheidung nach Teil 1 und Teil 2 gab, gibt es das heute nicht mehr. Trotzdem können Sie Ihr Sprint Planing in zwei Teilen vornehmen, denn es ist fast immer der logische Weg, den Scrum Teams gehen. Sie sollten sich nur nicht gezwungen fühlen, das machen zu müssen.

​Die Voraussetzungen

Damit das Sprint Planning wie gewünscht stattfinden kann, benötigt es einige Voraussetzungen. Zum einen sollte der Termin immer nach der Retrospektive stattfinden. Ein Sprint Planning findet damit immer direkt nach Ende des letzten Sprints statt. Es wird also nicht etwa eine gewisse Zeit gewartet.

Die Einladungen samt Ziel und Agenda sollten dem Team klar und durch den Scrum Master auch kommuniziert sein.

​Das Sprint Planning im zeitlichen Überblick

​Für einen vierwöchigen Sprint lässt sich mit dem Richtwert von 8 Stunden starten. Dabei werden nicht mehr die zwei Teile, also das Sprint Planning 1 und 2 betrachtet. Es geht in Summe um ein Event und die verfügbare Zeit. Wenn der Sprint kürzer ist, dann kann das Sprint Planung anteilig betrachtet werden. Ich persönlich tendiere bei einem guten Backlog Refinement immer dazu, das Sprint Planning 1 so kurz wie möglich zu halten. Das funktioniert immer dann gut, wenn die entsprechenden Product Backlog Einträge...

  • check
    ​... so gro​ß sind, dass sie das Entwicklungsteam ​theoretisch in einen Sprint nehmen ​kann
  • check
    ... ​bereits geschätzt sind und diese Schätzung nicht zu lange zurückliegt
  • check
    ​... alle Akzeptanzkriterien vorhanden sind

Wenn das Verständnis über das, was in den Sprint kommt vorhanden ist, geht der erste Teil des Plannings sehr schnell. Wie so oft gibt es verschiedene Rahmenbedingungen die berücksichtigt werden müssen, in den Projekterfahrungen (am Ende) gebe ich dazu auch noch ein paar Richtwerte. Beachten Sie auch immer, dass Sie keinen Overhead an Meetings erzeugen und immer mit den Werten in Scrum Guide starten.

Wer sich nicht sicher ist, startet immer mit der Definition im Scrum Guide und kann erst einmal wenig falsch machen.

​Inhalt des Sprint Plannings

Während die genaue Bezeichnung im Grunde egal ist, ist der Inhalt umso wichtiger. Hier geht es darum, dass zum einen der Product Owner dem Entwicklungsteam vorstellt, was er gerne hätte. Das Entwicklungsteam wählt dabei die Arbeit aus, die es glaubt in der Lage ist zu leisten. Es bestimmt dabei auch die konkrete Umsetzung, also das wie! Ein ganz entscheidender Aspekt ist dabei, dass das Entwicklungsteam auch wirklich an der Lieferung der entsprechenden Aufgaben arbeitet. Das adressiert auch einen der fünf Scrum Werte, nämlich das Commitment.

Je nach Erkenntnisgewinn kann es nötig sein, dass die Definition of Done justiert wird. Das Sprint Ziel ist durch den Product Owner und das Entwicklungsteam ebenso festgelegt. Hier hilft es, wenn der Product Owner mit einem Vorschlag in das Sprint Planning kommt und es gemeinsam mit dem Entwicklungsteam dann verabschiedet. Das Sprint Backlog enthält dann die Stories, die durch das Entwicklungsteam​ für die Umsetzung ausgewählt wurden.

​Abschluss des Sprint Plannings

​Das Sprint Planning schlie​ßt mit dem gemeinsamen Verständnis der zu leistenden Arbeit für den kommenden Sprint. Nach dem Abschluss des Sprint Plannings geht es direkt in die Umsetzung. Das Sprint Backlog ist erstellt und die Definition of Done ggf. noch einmal angepasst. Ebenso liegt das Sprint Ziel vor. Diese Artefakte sollten beim Team im Teamraum so hängen, dass diese bei der täglichen Arbeit auch wirklich sichtbar sind.

​Erfahrungen aus der Praxis

​Es gibt immer Teams die auf neue Ideen kommen, die unter bestimmten Rahmenbedingungen auch funktionieren können. Dabei sollen die hier vorgestellten Punkte der Orientierung dienen - sie können weder​ 1:1 kopiert werden, noch stellen diese eine Empfehlung dar!

  • ​Ein Aspekt, den ich bei Teams in der Transformation mit ehemaligen Projektleitern immer wieder finde, ist das das Product Owner schon eine Vorstellung des Sprint Backlogs mit in das SprintPlanning bringt. Dann steht das Sprint Backlog "zum Check" bei dem Entwicklungsteam. Es ist also kein Push der Arbeit und wenn das Entwicklungsteam sagt, es schafft es nicht, dann wird auch von diesem Plan abgewichen und der Product Owner nimmt die Einträge dann zurück ins Backlog.
  • ​Bei Entwicklungsteams, die (noch) nicht cross-funktional sind, findet sich in dem Sprint Planning der Aspekt, dass die Bestimmung der konkreten Aufgaben, die sich aus der User Story ableiten nicht gemeinsam stattfindet.
  • ​Wenn das Refinement sehr gut in den Teams läuft, dann ist es durchaus möglich das Sprint Planning 1 bei einem zwei oder drei wöchigen Sprint bei ca. 45 Minuten einpendeln zu lassen. Das hängt natürlich entscheidend davon ab, was die Teams entwickeln, wie die Aufgabenverteilung ist und wie gut die Teams die Umsetzung der Aufgabe annehmen können.
  • ​Wenn nicht mit User Stories gearbeitet wird und ein oft wasserfallähnliches Scrum durchgeführt wird, dann finden sich nicht selten im Planning 2 Einträge wie entwickeln, integrieren, testen, ... Das ist im Sinne von Scrum nicht optimal, denn es erhört das Risiko im Sprint und erzeugt keine fertige Arbeit.

​Achten Sie auf fertige Backlog Items

​Mir fällt immer wieder bei startenden Teams auf, dass die Product Backlog Items nicht soweit gereift sind, dass mit den ersten Sprint Plannings begonnen werden kann. Das führt unweigerlich zu

  • ​Frustration beim gesamten Team. Es kann nicht mit der Arbeit begonnen werden, da zu viel "unklar" ist.
  • ​Aussagen, dass Scrum ja auch nicht fuktioniert und ebenso wie das bisherige Vorgehen nicht für das Projekt passt. ("Unser Projekt ist eben doch so anders").
  • ​Schauen Sie sich unbedingt das Backlog Refinement an, denn wenn Sie keine fertigen Product Backlog Items besitzen, die das Team sich ziehen kann, liegt genau dort das Hauptproblem.

Stellen Sie Prioritäten sicher!

​Das Product Backlog ist der zentrale Input für das Sprint Planning. Wenn Sie hier keine ​klaren Prioritäten besitzen, dann laufen Sie zwangsläufig in Probleme.

  • ​Der Product Owner muss das Produkt und den Kunden kennen. Ohne diese Kenntnis kann kein Backlog nach Wert generiert werden.
  • ​Nur der Product Owner legt die Priortiät fest. Wenn er Hilfe dazu benötigt, dann sollte das auch im Vorfeld zum Sprint Planning geschehen.
  • ​Es ist nicht selten, dass Teams in Organisation zwischen 30-70% keine klaren Prioritäten besitzen und nicht wissen, was als nächstes wirklich wichtig ist.

​Das Sprint Backlog erstellen

​Ein zentrales Artefakt ist das Sprint Backlog. Überlegen Sie sich, wie Sie das Sprint Backlog physikalisch ​erstellen.

Leave a Reply 0 comments

Leave a Reply:







Cookie-Einstellung

Bitte treffen Sie eine Auswahl. Weitere Informationen zu den Auswirkungen Ihrer Auswahl finden Sie unter Hilfe. Datenschutz Erklärung für die Webseite | Impressum dieser Webseite

Treffen Sie eine Auswahl um fortzufahren

Ihre Auswahl wurde gespeichert!

Weitere Informationen

Hilfe

Um fortfahren zu können, treffen Sie bitte Ihr Cookie-Auswahl. Nachfolgend erhalten Sie eine Erläuterung der verschiedenen Optionen und ihrer Bedeutung.

  • Alle Cookies zulassen:
    Erlauben Sie mir alle Cookies? Danke :-)
  • Nur First-Party-Cookies zulassen:
    Cookies von dieser Webseite und Cookies, die es mir erlauben Ihr Erlebnis auf der Seite zu optimieren.
  • Keine Cookies zulassen:
    Es werden keine Cookies gesetzt, es sei denn, es handelt sich um technisch notwendige Cookies.

Sie können Ihre Cookie-Einstellung jederzeit hier ändern: Datenschutz Erklärung für die Webseite. Impressum dieser Webseite

Zurück

>