Sprint Planning
Was ist ein Sprint Planning?
Das Sprint Planning ist das Scrum Event, was den Start des Sprints einleitet. In ihm definiert das Scrum Team das Sprint Ziel als den Arbeitsschwerpunkt des Sprints und gestaltet partnerschaftlich sein Vorgehen aus, um dieses effektiv angehen zu können.
Weitere Infos zum
Sprint Planning
Teilnehmer
Scrum Team
Entwickler, Product Owner & Scrum master
Input
Product Backlog mit genügend Orientierung und Items
Output
Sprint Backlog orientiert an einem Sprint Ziel
Dauer
8 Stunden Timebox
bei einem 30 Tage Sprint
Die Inhalte des Sprint Plannings
Ein gutes Sprint Planning muss den Entwicklern den Kontext geben, damit sie die Verantwortung für das Sprint-Ziel und die Ausgestaltung der angestrebten Ergebnisse übernehmen können. Dazu reicht es nicht aus, dass Arbeitspakete runtergebrochen und zugewiesen werden. Es braucht ein tieferes Verständnis für die angestrebten Ergebnisse, um mitdenken und mitwirken zu können.
Um dies sicherzustellen, schreibt der Scrum Guide vor, folgende drei Themen zu behandeln:
- Setzen eines Sprint-Ziels
Um eine gemeinsame Orientierung zu haben, wie wir Mehrwert schaffen. - Auswahl von Einträgen aus dem Product Backlog
Um ein klares gemeinsames Verständnis zu haben, was wir diesen Sprint in Hinblick auf das Sprint-Ziel angehen und abschließen wollen. - Konkretisierung, wie wir diese Vorhaben angehen
Damit jeder Entwickler sich gut aufgestellt fühlt, die Themen erfolgreich anzugehen.
Wichtig für den Erfolg des Plannings
Alte Planungsmuster überwinden
Der Weg zu einem weltklasse Team ist lang und alte Arbeitsweisen wirken lange nach. Noch immer sind planungsgetriebene Denkmuster sowie die Einteilung unserer Arbeit in Phasen in unseren Köpfen präsent. Wir sind es gewohnt, dass der Planer vor der Arbeit das Denken übernimmt und in der Ausführung dann einfach nur gemacht wird. In Scrum ist das nicht mehr möglich. Die Planung eines Sprints hat daher nicht viel mit dem zu tun, was wir unter klassischer Planung verstehen. In der Praxis finden sich viele dieser alten Muster und Denkweisen fälschlicherweise im Sprint Planning wieder und sorgen nicht selten für Dysfunktionen bei der Ausführung von Scrum. Sie manifestieren sich beispielsweise darin, dass es sich ungewohnt anfühlt, wenn ein Team das Ziel eines Sprints festlegt und nicht ein “Teamleiter”. Ebenso, wenn wir das Gefühl haben, ein einzelner “Verantwortlicher” müsse die Verantwortung für das tragen, was das Team erarbeitet. Wir sind es gewohnt, dass Planen immer auch mit einer Zuweisung von Zuständigkeiten an einzelne Personen einhergeht. Eine Gewohnheit, die der gemeinsamen Verantwortung der Entwickler im Sprint zuwiderläuft.
In dem Artikel The Goal of Sprint Planning gibt Mike Cohn dazu noch ein paar ergänzende Gedanken.
Deal zwischen PO & Entwicklern
Der wichtigste Punkt, der die Natur des Sprint Plannings ausgestaltet, zeigt sich im Verhältnis zwischen PO und Entwicklern. Es lässt sich als eine Art impliziten “Deal” beschreiben, bei dem beide Parteien ein Ziel festlegen, das im Sprint erreicht werden soll. Für die Entwickler bedeutet das, eigenverantwortlich zu arbeiten, den PO allerdings in die Arbeit mit einzubinden. Dazu gehört, dass es sich bei Fragen oder relevante Änderungen rechtzeitig und proaktiv an ihn wendet, sodass es keine Überraschungen für den PO selbst oder gar für die Stakeholder gibt. Der PO lässt dem Team genügend Freiraum bei der Festlegung des Arbeitsumfangs, der Herangehensweise sowie auch bei der Arbeit selbst. Ein Mikromanagement seitens des PO sollte nicht notwendig sein.
Das Resultat aus dem Deal zwischen Entwicklern und PO ist ein Forecast an Arbeit, die die Entwickler in einem Sprint umsetzen möchte. Die Entwickler garantieren zwar nicht das Ergebnis, ist jedoch aus diesem Forecast an Arbeit “commited”, die Verantwortung für den Sprint zu übernehmen. Es sichert zu, das Sprint-Ziel eigenverantwortlich und unter Einziehung des POs zu erreichen.
Podcast-Folge zum Sprint Planning
Klicken Sie auf den unteren Button, um den Inhalt von Spotify zu laden.
Aufgrund dieser Andersartigkeit und des hohen Anspruchs an die Entwickler fällt es uns oft schwer, loszulassen und den Teams den Raum sowie die notwendige Unterstützung und das notwendige Vertrauen für diese Art der Arbeit zu geben. In der Folge “Sprint Planning” gehe ich genau auf diese Problematik ein und zeige anhand des Rollenverständnisses von Scrum, was die Intention des Sprint Plannings ist und wie ein Planning vorbereitet (Product Backlog, Definition of Ready) und ausgestaltet (Sprint-Ziel, Auswahl der Items) werden kann, damit alle mit einem guten Gefühl in den Sprint starten können. Aufgrund der fortwährenden Präsenz alter Muster gehe ich dabei auch gezielt auf Schwierigkeiten und Dysfunktionen ein.
Sprint Vorbereitung vor & im Planning
Um klar herauszustellen, wie an ein Sprint Planning sinnvoll herangegangen werden kann, macht es Sinn, die Verantwortlichkeiten der einzelnen Scrum-Akteure sowohl in der Vorbereitung als auch bei der Ausgestaltung des Plannings zu betrachten. Darüber hinaus ist es wichtig, den Einsatz einer Definition of Ready und die grundsätzliche Intention des Sprint-Ziels zu verstehen.
1. Die Scrum Verantwortlichkeiten im Scrum Team
- Product Owner (PO):
Der PO ist für die Pflege des Product Backlogs verantwortlich. Er bereitet das Product Backlog für den Sprint so vor, dass es für die Entwickler informativ ist und Items mit dem größtem Wert erkennbar sind. - Entwickler:
Die (früher Entwicklungsteam oder kurz Team) nutzen diese Informationen, um damit den Sprint eigenverantwortlich auszugestalten, sodass es qualitativ hochwertige Ergebnisse erzeugen kann. - Scrum Master (ScM):
Der ScM sorgt dafür, dass Team und PO eine Umgebung haben, in der dieses Zusammenspiel gut funktioniert.
Er sorgt dafür, dass Scrum Events stattfinden und fördert das Zusammenspiel und den Austausch durch diverse (Moderations-) Techniken.
Auch wenn die Verantwortlichkeiten im Scrum Guide klar geregelt sind, ist die Umsetzung nicht trivial. Häufig werden in der Praxis die einzelnen Verantwortlichkeiten und die damit verbundenen Aufgaben hinterfragt. Bei einer genaueren Betrachtung der Funktion des Scrum Masters zeigt sich ganz besonders deutlich, warum es wichtig ist, die urspüngliche Intention der einzelnen Verantwortlichkeiten zu wahren. Beispielsweise wird oft danach gefragt, warum nicht der PO anstelle des Scrum Masters die Organisation und Moderation des Sprint Plannings übernehmen kann. Dies ist besonders deswegen nicht sinnvoll, weil der Product Owner nicht unbefangen ist. Wenn der Druck, ein Produkt zu liefern sehr hoch ist, könnte es leicht passieren, dass seine Moderation dazu führt, dem Team unrealistische Pläne “aufzudrücken”. An dieser Stelle ist es aber wichtig, ein unabhängiges Feedback zu erhalten, um frühzeitig Probleme zu erkennen und die Zeit und das Budget zum Inspizieren und Adaptieren nutzen zu können. Es macht keinen Sinn, unrealistische Pläne zu lange aufrecht zu erhalten, nur um den Erwartungen anderer (z.B. der Stakeholder) gerecht zu werden. Um dieses unabhängige Feedback zu erhalten, fällt es in den Aufgabenbereich des Scrum Masters, sich um das Stattfinden und die Zweckerfüllung der Events sowie der Aufrechterhaltung des Zusammenspiels zu kümmern. Eine Mischung der Verantwortlichkeiten schafft Dysfunktionen, weshalb klar davon abgeraten werden kann.
Der Scrum Master sorgt dafür, dass die Vorbereitungen des Sprints gut verlaufen und der Austausch zwischen Team und PO stattfinden kann. Er stellt sicher, dass das Team nach der Planung des Sprints flüssig und fokussiert an sinnvollen Aufgaben arbeiten kann. Der Product Owner kann und muss sich in der Vorbereitung und im Sprint Planning voll und ganz auf das Refinement und die Priorisierung der Product Backlog Items konzentrieren und dafür sorgen, dass diese sinnvoll abgearbeitet werden können. Das bedeutet, er muss die Backlog Items so vollständig wie möglich erfassen, diese gemäß ihres Wertes für die Organisation priorisieren und dem Team ausreichend viele Optionen zur Verfügung stellen.
Ist das Product Backlog nicht ausreichend vorbereitet, kann das Planning nicht zielführend abgehalten werden. Ein häufiges Beispiel aus der Praxis ist die spontane Vorstellung neuer Items im Sprint Planning durch den PO. Das Planning wird damit zu einer Überraschungsparty, bei der der Product Owner plötzlich Items vorstellt, die den Entwicklern gänzlich unbekannt sind. Natürlich kann es immer einmal vorkommen, dass Items nachträglich hinzugefügt werden. Dies sollte sich allerdings im Rahmen halten, da das Team beim Hinzufügen von völlig unbekannten Items wenig Handlungsspielraum hat und in letzter Konsequenz diese ggf. nicht in den Sprint mit aufnehmen kann. Darüber hinaus sinkt dadurch die Motivation und es baut sich unnötigerweise Druck auf.
Ein weiteres Beispiel, das dazu führt, dass eine Auswahl an Items im Planning nicht sinnvoll erfolgen kann, ist das Fehlen an Optionen: Das Team benötigt eine Auswahl an Items, die es ihm erlaubt, zu wählen. Fehlende Optionen verringern auch hier wieder den Handlungsspielraum und nehmen dem Team die Möglichkeit, Items in sinnvoller Reihenfolge abzuarbeiten.
Erlebe den Kern von Scrum
Nutze unser kostenloses Webinar, um aus erster Hand zu erleben, worauf es in Scrum wirklich ankommt!
Montag
15.05.
18:15-20:00
2. Sprint-Ziel: Zentraler Orientierungspunkt statt Sprint Motto
Die Qualität des Product Backlogs beeinflusst die Qualität des Sprint-Ziels. Es ist daher ausschlaggebend für ein gutes Sprint-Ziel. Gut ist ein Backlog dann, wenn es dem Team einen Ausblick auf das übergreifende Gesamtziel bietet. Denn nur wenn ein klares Verständnis vom Gesamtziel gegeben ist, lassen sich Sprint-Ziele sauber daraus ableiten. Darüber hinaus benötigt das Team den notwendigen Kontext, um entweder selbst Vorschläge zu machen, oder die Vorschläge des PO diskutieren zu können.
Es geht bei der Definition des Sprint-Ziels also nicht um die bloße Festlegung eines Bündels an Items, sondern vielmehr darum, diese dem Kontext entsprechend sinnvoll und entsprechend des übergreifenden Gesamtziels zu wählen, sodass es dem Team im Sprint Orientierung gibt.
Ein fragmentierter, kurzfristiger Ausblick von Backlog Items hat zur Folge, dass in der Praxis häufig sogar das Sprint-Ziel weggelassen wird oder es zwar existiert, aber zu wenig Orientierung gibt. Dies sorgt dafür, dass ein effektives und fokussiertes Abarbeiten der Items erschwert wird.
In dem Artikel Creating effective Sprint Goals gibt Roman Pichler eine ergänzende Perspektive zum Thema.
3. Definition of Ready: Gemeinsames Verständnis von “Fertig” oder Brandschutzmauer?
Aus den Vorzügen, ein gemeinsames Verständnis von Fertig als „Definition of Done“ explizit zu machen, um dadurch die richtigen Themen konsistenter und besser liefern zu können, ist die Idee entstanden, dieses Konzept auch auf finale Backlog Items zu übertragen. Kurz: Die Definition of Ready beantwortet die Frage, ab wann unsere Items gut genug sind, um sie in den Sprint ziehen zu können. Bei der Definition of Ready geht es im Kern darum, ein gemeinsames Verständnis von Fertig zu schaffen, um dadurch für mehr Konsistenz zu sorgen. Darüber hinaus können dadurch Zusammenhänge und Probleme frühzeitig aufgedeckt und aus dem Weg geräumt werden.
In der Praxis kann dies ganz einfach umgesetzt werden. Ich nutze hierfür gern Labels (bei Papier-Backlogs beispielsweise Post-It’s), um die unterschiedlichen Themen zum Ausdruck zu bringen, die wir bei einer guten Backlog-Pflege im Blick haben sollten. Das können Risiken sein, aber auch Abhängigkeiten oder zugehörige Anforderungen.
Die Kehrseite des Sichtbarmachens von Abhängigkeiten und Risiken ist jedoch, dass das Team nicht selten vom PO fordert, Items in ihrer Komplexität zu reduzieren, bevor diese in den Sprint gezogen werden. Die Definition of Ready wird dann zur “Brandschutzmauer” und es entsteht ein hoher Anspruch an den PO. Eine sehr anspruchsvolle Definition of Ready kann dazu führen, dass ein PO mit seinen “frühen Items” alleine gelassen wird und gezwungen ist, eine Lösung für etwas zu finden, das er alleine gar nicht lösen kann. Eine derartige Entwicklung sollte beseitigt werden, denn die ursprüngliche Intention von Scrum ist es, Risiken oder Abhängigkeiten in der Zusammenarbeit zu betrachten und gemeinsam zu lösen.
4. Schätzung des Arbeitsumfangs (Kapazität/Velocity)
Zur Ausgestaltung des „Was“ gehört die Schätzung des Arbeitsumfangs. Um festzulegen, was alles im Sprint bearbeitet werden kann, beziehen Teams häufig Hilfsmittel in Form einer Kapazitätsplanung oder des durchschnittlichen Umfangs von Items in einem Sprint (Velocity) mit ein. Das Berechnen von Kapazitäten ist eine gute Praktik um zu erkennen, was das Team in einem Sprint schaffen kann. Die Items können dann in Tasks heruntergebrochen und und auf die verfügbaren Kapazitäten aufgeteilt werden, sodass klar ist, wie viel in einem Sprint bearbeitet werden kann. Dies macht Sinn, wenn wir beispielsweise die Verfügbarkeit einiger Teammitglieder in die Planung miteinbeziehen wollen.
Es ist allerdings wichtig zu beachten, dass die Berechnung von Kapazitäten nur eine Diskussionsgrundlage darstellt und dass nur das Team selbst entscheiden kann, wie viele Items in einem Sprint platz haben. Denn: wenn wir uns strikt auf Kapazitäten verlassen und uns basierend darauf zu 100 Prozent auslasten, übergehen wir die Tatsache, dass es Themen gibt, die erst im Sprint aufkommen. Beispielsweise kann es passieren, dass wir Risiken falsch einschätzen oder die Wissensverteilung im Team sich verändert hat.Ähnlich verhält es sich mit der Velocity: Wir schließen vom Umfang der Items der Vergangenheit auf die Zukunft. Ein striktes Festhalten an vergangenen Werten macht auch hier keinen Sinn. Kapazitäten sowie Velocity sind agile Tools, die bei der Planung helfen sollen und (wie alle agilen Tool) nicht nicht für den blinden Einsatz gedacht sind, sondern vielmehr dazu, einen Austausch im Team anzuregen. Ein striktes Festhalten an früheren Schätzungen kann dann dazu führen, dass die Qualität leidet oder, dass das Team aufgrund einer zu hohen Auslastung den Sprint nicht beenden kann.
5. Unterstützende Technik zur sinnvollen Auswahl der Backlog Items
Zur Ausgestaltung des „Was“ gehört auch die Auswahl der Backlog. Diese findet gemeinsam im Team statt. Hier gilt es zu beachten, dass es unterschiedliche Persönlichkeiten und Sichtweisen geben kann, und es wichtig ist, alle zu hören. Um dieses unabhängige Feedback sicherzustellen, können Moderationstechniken angewandt werden. Meinen Favoriten möchte ich gern näher vorstellen.
Unabhängige Auswahl von Items durch die Entwickler
Das Backlog wird gut sichtbar an einer Wand präsentiert. Hierbei ist wichtig, dass genügend Items platziert werden, sodass das Team eine gute Übersicht und genügend Optionen zur Auswahl hat. Jedes Teammitglied erhält daraufhin einen Post-It und ist aufgefordert, diejenigen Items zu markieren, die seiner Meinung nach im kommenden Sprint zu schaffen sind.
Die Technik hat meiner Meinung nach drei Vorteile: Sie ermöglicht es uns erstens, alle Teammitglieder zu “hören” und regt zweitens zu einem Gespräch an. Drittens schafft sie es, dass das Team sich nicht blind auf Kapazitäten oder Velocity verlässt.
6. Herunterbrechen der Items in einzelne Tätigkeiten
In der Ausgestaltung des “Wie” brechen die meisten Teams mit denen ich arbeite, ihre Backlog Einträge noch einmal in Tätigkeiten herunter. Sie erzielen dadurch, dass sie mit einer übersichtlichen Anzahl an Backlog Items (meine Faustregel sind 5 bis 10) gemeinsam alles im Blick haben und gleichzeitig durch detaillierte Tasks die konkrete Arbeit im Sprint sichtbar machen und koordinieren können.
Dies sorgt zum einen für Transparenz bei der Arbeit, zum anderen schafft es allen Beteiligten einen Überblick und ermöglicht das eigenverantwortliche Arbeiten als Team.
Es macht Sinn, dafür ein visuelles Task Board zu nutzen, das neben den priorisierten Backlog Items eine weitere Ebene an Tätigkeiten enthält, die mit einem einfachen Status gekennzeichnet sind: “to do”, “in Arbeit” oder “done”. Das Team hat damit die Möglichkeit, diese weitere Ebene an Tasks jederzeit zu überblicken (mehr zum Thema Task Board findet ihr hier).
Sprint Planning Agenda
Scrum ist ein minimaler Rahmen und jedes Scrum Team ist angehalten für sich den passenden Ablauf des Sprint Plannings zu finden und aus den gemachten Erfahrungen weiterzuentwickeln.
Eine immer gültige Sprint Planning Agenda kann es nicht geben und widerspricht der Idee von Scrum aus Erfahrung zu lernen.
Allerdings hat sich für uns der nachfolgende Aufbau bewährt und kann als erste Orientierung dienen, um ein effektives Sprint Planning aufzubauen.
Sprint Planning 1 und 2
Bis 2020 wurde in Scrum in einen ersten und einen zweiten Teil des Sprint Plannings unterschieden. Diese Trennung vorzuschreiben gibt zwar mehr Flexibilität in der Ausgestaltung von Scrum. Die Aufteilung des Sprint Plannings in zwei Teile hat sich für uns aber in vielen Fällen bewährt und kann ein sehr sinnvoller Startpunkt sein.
Sprint Planning 1
Im ersten Teil vom Sprint Planning setzt man sich als Scrum Team zusammen, um gemeinsam das Sprint-Ziel zu definieren und dazugehörig die Backlog-Items auszuwählen.
Um einen realistischen Umfang für den Sprint auszuwählen, werden hier typischerweise die Verfügbarkeit der Teammitglieder und die Velocity als Orientierungspunkt herangezogen.
Darüber hinaus ist es üblich, dass letzte Backlog-Items hier im Planning vorbereitet werden. Dies sollte sich aber wirklich auf wenige Items beschränken, um nicht in die Verlegenheit zu kommen, nicht mehr alles Vorbereiten zu können.
Einen weiterführenden Einblick zu einem Sprint Planning 1 in einer skalierten Umgebung bei LeSS bekommt ihr hier.
Sprint Planning 2
Im zweiten Teil vom Planning brechen dann die Entwickler die Backlog-Items in Tasks runter. Der Product Owner muss hier nicht mehr voll zur Verfügung stehen. Es reicht aus, wenn er für aufkommende Fragen greifbar ist und diese schnell geklärt werden können.
Sprint Planning Agenda und Checkliste erstellen
Orientiert euch an den obigen Tipps zur Ausgestaltung des Sprint Plannings. Nutzt folgendes Arbeitsblatt um euch eine eigene passende Agenda für euer Sprint Planning zu schaffen. Aus unserer Erfahrung hat es sich darüber hinaus bewährt sich die Agenda um eine Checkliste für die Sprint Vorbereitung und die Durchführung eines Sprint Plannings zu ergänzen, damit ihr nichts vergesst.
Ergänzende Tipps zum Sprint Planning
Hier einige ergänzende weiterführende Tipps und Tricks zur Durchführung eines Sprint Plannings von Johannes Geske bei Scrum.org.
Hier einige ergänzende Tipps und Tricks zur Durchführung eines Sprint Plannings von Alex Circei bei Forbes.
Hier diskutiert Mike Cohn, ob es sinnvoll ist, schon im Sprint Planning Aufgaben Personen zuzuweisen.
Sprint Planning Beispiele
Nachfolgend die Vorstellung der Praxisbeispiele aus dem Event:
Zusammenfassung
In der Praxis finden sich im Sprint Planning fälschlicherweise viele alten Muster und Denkweisen wieder und sorgen nicht selten für Dysfunktionen bei der Ausführung von Scrum. Unter Einbeziehung des Rollenverständnisses in Scrum wird deutlich, was die eigentliche Intention des Sprint Plannings ist. Eine Vorbereitung des Plannings ist besonders in Hinblick auf die adäquate Darstellung des Product Backlog wichtig. Dem PO kommt hier eine wichtige Rolle zu. Bei der Ausgestaltung des Plannings (Sprint-Ziel, Auswahl der Items) ist es entscheidend, dass das Team unabhängig und eigenverantwortlich Feedback gibt und entscheidet, was in den Sprint aufgenommen wird und was nicht. Das Ergebnis ist ein impliziter Deal zwischen PO und Team, das sich auf ein gemeinsames Sprint-Ziel „committed“, es eigenverantwortlich bearbeiten und unter Einbeziehung des POs erreichen möchte. Die Ausgestaltung des Sprint Plannings kann durch unterschiedliche Techniken effektiver gestaltet werden werden, damit alle mit einem guten Gefühl in den Sprint starten können.
Ich hoffe, ich konnte dir mit meinen Tipps neue Impulse und Ideen für die Vorbereitung und Ausgestaltung des Sprint Plannings geben. Hast du Fragen oder Anmerkungen? Ich freue mich immer über ein Feedback.
Ergänzende Perspektiven
Podcast Nachlese
Aufbauend auf dieser Folge habe mit Christoph Steinhauer ausgetauscht gesprochen.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Ergänzende Artikel
Tips & Tricks to facilitate Sprint Planning von Johannes Geske
What does the Scrum master do during the Sprint Planning? von Daria Bagina
6 common mistakes when doing Sprint Planning von Maarten Dalmijn
The perfect ingredients to fail your Sprint Planning von David Pereira
Typische Fragen zum Sprint Planning
Am Sprint Planning nimmt das ganze Scrum Team teil, also alle Entwickler, Product Owner und Scrum Master.
Da die Entwickler gemeinsam die Verantwortung für die Arbeit im Sprint übernehmen, ist es wichtig das Vorgehen gemeinsam mit dem PO abzustimmen.
In Scrum ist nicht definiert, wer das Sprint Planning moderiert. Typischerweise übernimmt diese Aufgabe der Scrum Master. Gerade wenn dieser nicht auch als Product Owner oder Entwickler tätig ist, kann er mit seiner Moderation ein effektives Zusammenwirken von PO und Entwicklern sicherstellen. Dazu möchte Scrum allerdings bewusst die Freiheit geben von dieser bewährten Praxis abzuweichen, um so möglichst gut auf die Bedürfnisse vom Kontext eingehen zu können.
Ein einmonatiger Sprint hat eine maximale Timebox von 8 Stunden. Ist der Sprint kürzer, ist entsprechend auch das Sprint Planning kürzer.
Der Umfang des Sprint Plannings mag im ersten Moment überraschen. Das Planning bündelt aber letztlich nur die gemeinsamen Absprachen zum Start der Entwicklung. Richtig gelebt schafft das Sprint Planning so sich fokussierter und effizienter abzustimmen.
Nein, eine Aufteilung in Sprint Planning Teil 1 und Teil 2 war nur bis 2020 im Scrum Guide vorgeschrieben.
Heute definiert der Scrum Guide nur noch, was in einem Sprint Planning verpflichtend behandelt werden muss. Die Form und Aufteilung ist bewusst offengelassen, um möglichst flexibel auf unterschiedlichste Kontexte eingehen zu können.
Nein, Scrum schreibt weder die Arbeit mit User Stories, Story Points noch Velocity vor.
Scrum ist bewusst als minimaler Rahmen definiert und jedes Scrum Team ist dazu angehalten, diesen passend zu seinem Kontext auszugestalten.
User Stories, Story Points und auch die Arbeit mit der Velocity sind bewährte Praktiken, die viele Teams für sich als hilfreich empfinden und nutzen.
