Sprint Planning

English
Sprint Planning, Sprint Planning Meeting, Sprint Negotiation

Sprint Planning ist ein Element ("Event") von Scrum. Scrum ist ein Managementsystem des Agilen Projektmanagements, mit dessen Hilfe Scrum-Teams komplexe, von Veränderung geprägte Entwicklungsaufgaben bearbeiten. Das Sprint Planning steht am Beginn jedes einzelnen Sprints (zeitlich fest definierter Abarbeitungszeitraum für ein Team). Es dient zur Festlegung der in diesem Sprint zu bearbeitenden Inhalten.

Sprint Planning

Sprint Planning

English
Sprint Planning, Sprint Planning Meeting, Sprint Negotiation

Sprint Planning ist ein Element ("Event") von Scrum. Scrum ist ein Managementsystem des Agilen Projektmanagements, mit dessen Hilfe Scrum-Teams komplexe, von Veränderung geprägte Entwicklungsaufgaben bearbeiten. Das Sprint Planning steht am Beginn jedes einzelnen Sprints (zeitlich fest definierter Abarbeitungszeitraum für ein Team). Es dient zur Festlegung der in diesem Sprint zu bearbeitenden Inhalten.

Sprint Planning
Wir empfehlen zum Thema Scrum
Zertifizierter Product Owner und Scrum Master

Lassen Sie sich in einem nur 3-tägigen, kombinierten Praxistraining zum Product Owner und zum Scrum Master zertifizieren.  Mehr Infos

Einsatzmöglichkeiten

  • Planen der im kommenden Sprint zu erstellenden, in sich geschlossenen Teilprodukte oder Teilergebnisse (sog. "Produktinkremente")
  • Planen der Tätigkeiten, um diese Ergebnisse zu realisieren

 

Ergebnisse

  • Das vom Scrum-Team gemeinsam formulierte Sprint-Ziel ("Sprint Goal"). Das Sprint-Ziel beschreibt übergeordnet in ca. ein bis zwei Sätzen die im Sprint durch das Scrum-Team zu erbringende Leistung.
  • Das Sprint Backlog: eine vollständige Liste der zur Abarbeitung vereinbarten Backlog Items mit weiteren Informationen zur Bearbeitung.
  • Die Liste der Sprint Tasks, die zur Bearbeitung der einzelnen Backlog Items notwendig sind.

Vorteile

Kontinuität: Sprint Planning findet in einem definierten Rhythmus statt und gibt dadurch dem Entwicklungsprozess einen stabilen Rahmen.
Einvernehmlich und kollektiv: Das gesamte Scrum-Team plant die zu erstellenden Ergebnisse, die dafür erforderlichen Tätigkeiten und schätzt gemeinsam den Aufwand.
"Time-Boxed": Das Sprint-Planning hat eine festgelegte, stets gleiche Dauer von in der Regel mindestens vier, höchstens acht Stunden, abhängig von Teamgröße und Erfahrung der Mitarbeiter. Es wird dadurch für alle Verantwortlichen planbar.

Aufgabengebiete

Alle Kommentare (4)

Peter
Jetter

"Die iterative Abschätzung der Sprints lässt keine (sinnvolle) Abarbeitung des Projekts zu fixierter Dauer (terminierte Deadline) und fixiertem Aufwand (Festpreis) zu." Wie kommen Sie zu dieser Aussage? Nach meinem Verständnis sind in Scrum Qulalitä, time(date) und budget(HC, stabile Teams!) in der Regel fest. Variabel ist der Scope. Ziel ist den gelieferten Business Value innerhalb des time und budget Rahmens zu maximieren. Der scope wird dazu stets neu priorisiert, damit stets das Produktinkrement mit dem höchsten Business Value realisiert wird. Problem- und Lösungsverständnis entwickeln sich -in gegenseitiger Wechselwirkung- über die Zeit.

 

Daniel
Reinold

Vielen Dank für Ihren Beitrag. In wie weit die Zielsetzung im Allgemeinen fest oder variabel ist, möchte ich in der Methode „Sprint Planning“ nicht festlegen. Durch ergänzende/verknüpfende Methoden mag eine Bearbeitung zum Festpreis möglich sein (siehe z.B.: https://www.projektmagazin.de/artikel/sechs-schritten-zum-agilen-festpreis_1089027). Die allgemeine Diskussion zum Thema ist immer noch im Gange (z.B.: „Agiler Festpreis“). Da wir hier eine praxisnahe Darstellung liefern möchten, sind die Leser (und ich) dankbar für entsprechende Beispiele.

 

Martin
Rohner

Ich möchte mich hier Peter Jetter anschliessen. Das ist doch genau der Vorteil von SCRUM: fixe Kosten, da fixe Ressourcen (in der Regel) weil ja der Scope noch nicht ganz klar ist von Anfang an. Und das ist die Hauptaufgabe von PO und SCRUM Master, diesen durch Priorisierung und genaue Schätzung in den Backlog zu bringen. Somit kann genau eine sinnvolle Abarbeitung erzielt warden, indem die dem Endnutzer wichtigen Funktionen möglichst schnell zur Verfügung gestellt werden. Ich habe mittlerweile als externer Projektleiter / SCRUM Master genau aus diesen Gründen (Fixpreis, das Wichtige zuerst) schon mehrere Kundenprojekte erfolgreich geleitet. Ausschlaggebend für den Erfolg war jeweils vor allem dass die entsprechenden Rollen und Verantwortlichkeiten klar waren und die Spielregeln von Anfang an (und immer mal wieder) kommuniziert und eingehalten wurden. Im generellen bin ich sowieso der Meinung, dass die Sprint Planung als solches eigentlich gar keine Methode ist, sondern ein Werkzeug in der Methode SCRUM, resp. agiles Projektmanagement, aber dies ist einfach meine Sicht.

 

Guest

Auch ich finde die Formulierung "Die iterative Abschätzung der Sprints lässt keine (sinnvolle) Abarbeitung des Projekts zu fixierter Dauer (terminierte Deadline) und fixiertem Aufwand (Festpreis) zu." unglücklich. Es stimmt schon, dass das Sprint Planning auf die Planung des nächsten Sprints fokussiert. Betrachte ich also isoliert nur dieses Event ist natürlich eine Sprint-übergreifende Planung (die dann die "sinnvolle" Abarbeitung eines Projekts ermöglicht) nicht präsent. Das Problem hierbei ist aber die isolierte Betrachtung; und das Vernachlässigen der Aufgaben des Product Owners, der genau diese übergreifenden Themen bei der Pflege des Product Backlogs stets im Auge behält. Der Eindruck, der durch die Äußerung entsteht, ist, dass Scrum für diese Art der Planung nicht geeignet sei (insbesondere durch die Verwendung einer Wertung in Form von "keine (sinnvolle) Abarbeitung". Dies ist schlicht falsch. Es ist gerade der Vorteil der iterativen Abarbeitung insbesondere bei festem Termin und/oder Festpreis dem Kunden das unter diesen Rahmenbedingungen beste Produkt zu liefern. Dies wird -- gerade durch das iterative Vorgehen -- ermöglicht, weil dem Kunden enge Feedbackschleifen angeboten werden. Insofern schließe ich mich den Äußerungen von Peter Jetter und Martin Rohner an. Als weiteres: Den als ersten genannten Punkt unter "Nachteil / Grenzen / Risiken" verstehe ich auch nicht. Schließlich ist agiles Vorgehen nun mal verschieden vom klassischen Projekt. Konsequenterweise müssen sich Personen, die sich hierauf einlassen mit Veränderungen umgehen. Dies allerdings unter der Rubrik "Nachteil / Grenzen / Risiken" zu führen, empfinde ich als unglücklich. Denn dies gilt doch für jedwede anderen Arbeitsweisen, die für ein Projektteam neu sind und die "einen starken Einschnitt in die gewohnten Arbeitsabläufe des Projektteams darstellen".