Was ist ein Sprintplanungsmeeting?
Softwareentwicklungsteams setzen Sprints ein, um mit der Einführung neuer Softwareversionen, den sogenannten Iterationen, Schritt halten zu können. Angesichts konkurrierender Anforderungen, was in eine Iteration aufgenommen werden soll, muss ein Entwicklungsteam sehr genau wissen, worauf es sich während eines Sprints konzentrieren soll – sollten zum Beispiel bestimmte Fehlerbehebungen Vorrang vor der Einführung neuer Funktionen haben oder umgekehrt?
Agile Methoden sind auch in anderen Bereichen und Branchen beliebt, da dieser fokussierte Ansatz die Effektivität, Produktivität und Qualität steigern kann.
Bevor ein Sprint beginnt, nimmt das Projektteam an einer Sprintplanungssitzung teil. In dieser Sitzung werden zwei wichtige Entscheidungen getroffen:
-
Sprintziel: Das ist das geleistete Ergebnis des Sprints.
-
Sprint-Backlog: Die Liste der Aufgaben, die während des Sprints abgeschlossen werden müssen, um dieses Ziel zu erreichen.
Die Sprintplanung ist zeitlich begrenzt und findet in der Regel für eine Stunde pro Woche über einen Zeitraum von etwa acht Wochen statt.
Agile Project Management E-book
How can Agile PM help you do more with less?
Agile project management empowers teams to adapt to change with increased speed and flexibility. Learn how to implement Agile PM and get the most out of the methodology.
Sprintplanung passt zu Scrum und anderen agilen Methoden
Sprintplanung spielt eine wichtige Rolle im Universum der agilen Entwicklungsmethoden, bei denen Reaktionsfähigkeit, Flexibilität und kontinuierliche Verbesserung im Vordergrund stehen und Unternehmen dabei unterstützt werden sollen, herausragende Arbeit in einer Welt von unstetigen Prioritäten und Märkten zu leisten. Wenn sich die Kundenanforderungen und der Wettbewerb weiterentwickeln, bestimmt die Sprintplanung, welche Arbeiten als Nächstes zu erledigen sind.
In der Softwarebranche bestimmt die Sprintplanung, welche Produktänderungen oder Funktionen geliefert werden können und wie sie in der nächsten Iteration am effizientesten eingeführt werden können. Dieser Planungsprozess stellt sicher, dass das Team ein realistisches Arbeitspensum bewältigt und die wichtigsten Aufgaben zuerst erledigt. Denn in einem Sprint kann nur eine bestimmte Menge an Arbeit erledigt werden, ohne dass die Qualität darunter leidet.
Sprintplanung wird auch für hybride Agile-Methoden verwendet, wie Scrumban, ein Kofferwort aus Scrum und Kanban, dem visuell basierten, Pull-orientierten Arbeitssystem, das von Toyota entwickelt wurde. Scrumban kombiniert Iterationen mit fester Länge mit einem standardisierten Übergabeprozess, was bedeutet, dass mehr als ein spezialisiertes Team an einem einzigen Arbeitselement arbeiten kann.
Um zu verstehen, wie Sprintplanung mit Scrum funktioniert, ist es hilfreich, sich zunächst die wichtigsten Rollen und Prozesse der Methode anzusehen. Während der Sprintplanung arbeitet das Projektteam mit dem Product Owner zusammen (dem wichtigsten Interessenvertreter im Unternehmen oder in der Organisation für das Produkt) und wird von einem Scrum Master unterstützt (der Person, die als unterstützende Führungskraft dafür sorgt, dass der Ablauf des Prozesses funktioniert, indem sie das Team betreut und die Kommunikation und das Verständnis des Ziels erleichtert).
Diese Teilnehmer erstellen ein Sprint-Backlog, d. h. eine Liste mit Funktionen oder Änderungen aus dem Produkt-Backlog, die am Ende des Sprints entwickelt und eingeführt werden sollen. Das Sprint-Backlog wird durch das Sprintziel bestimmt, also dadurch, was während des Sprints geleistet werden kann.
“The most common mistake I’ve seen is when a team tries to plan a sprint when the product backlog is not ready with good user stories that are immediately actionable,” says Scrum Master Scott Luse of Dassault Systèmes and other companies. “Another, less common, mistake is to conduct a sprint planning meeting without having the product owner in the room to discuss the work and sprint goals. In both cases, the sprint will typically start with a low chance of success. A good Scrum master should protect the team and ensure this doesn’t happen” he adds.
Scrum and Agile expert Laura Neves, Program Manager at Microsoft, urges teams to make sure at the start that everyone is on the same page in terms of language and terminology.
„Eine ganz einfache, aber sehr nützliche Angewohnheit: Verwenden Sie keine Abkürzungen, wenn Sie die Sprintziele, Roadmaps und die Definition von „Erledigt“ festlegen. Gehen Sie nie davon aus, dass jeder genau weiß, was sie bedeuten, besonders wenn es Neulinge im Team gibt. Ersparen Sie sich eine Menge Erklärungen und Nacharbeit. Wenn Sie sie [Abkürzungen] ausbuchstabieren, sind Sie auch dazu gezwungen, die Aktualität lange verwendeter Konzepte neu zu bewerten. Wissen Sie (und Ihr Team) wirklich noch, was in Ihrem E2E-Ablauf von Anfang bis Ende geschehen soll?“, fragt sie.
Möchten Sie einen agileren Ansatz bei der Verwaltung von Projekten?
Erfahren Sie alles über Agile-Projektmanagement und Tipps, die Ihnen helfen, bewährte Vorgehensweisen für Agile-Projektmanagement zu implementieren.
Sichern Sie sich das kostenlose E-Book, um bewährte Vorgehensweisen für Agile zu implementieren
Wie lange dauert ein Meeting zur Sprintplanung?
Scrum-Experten empfehlen in der Regel, für jede Woche des Sprints etwa eine Stunde für die Sprintplanung aufzuwenden, also insgesamt bis zu acht Stunden. Hochkomplexe Projekte erfordern möglicherweise mehr Zeit. Je nach Reife des Scrum-Teams kann es fast doppelt so lange dauern.
Um zu verstehen, warum die Zeit, die ein Team zusammen war, ein so wichtiger Faktor für die Bestimmung der Länge eines Sprints ist, betrachten wir die Arbeit des Psychologen Bruce Tuckman, der 1965 die Idee vertrat, dass die Entwicklung einer Gruppe in bestimmten Phasen verläuft:
-
Forming: Wenn sich ein neues Team zusammenfindet oder neue Mitglieder in ein Team aufgenommen werden
-
Storming: Wenn die Mitglieder beginnen, sich über die Arbeitsweise zu streiten
-
Norming: Wenn sich die Teammitglieder mit den Rollen und Beziehungen aller Beteiligten in der Gruppe arrangieren
-
Performing: Wenn das Team in Fahrt kommt, die Produktivität maximiert wird und die Differenzen zwischen den Teammitgliedern minimiert werden
Es ist daher nicht verwunderlich, dass Teams, die sich noch in einem frühen Entwicklungsstadium befinden, mehr Planungszeit benötigen, um einen Konsens zu schaffen, als Teams, die schon länger zusammenarbeiten.
Dieser Akklimatisierungsfaktor kann erklären, warum Sprintplanung von einigen Kritikern als Zeitverschwendung angesehen wird. Scrum-Experten hingegen halten die Sprintplanung für eine wichtige Vorstufe eines jeden Sprints. Zum einen verbessert die Sprintplanung die Effizienz eines Sprints und verhindert, dass sich Entwickler mehr vornehmen, als sie bewältigen können. Der Prozess schafft auch einen Konsens mit dem Projektmanager über die Ergebnisse des Sprints. Darüber hinaus gibt es Agile-Entwicklern ein Gefühl der Autorität über ihre Arbeit und verhindert, dass sie sich ständig gezwungen sehen, konkurrierende Anforderungen mit ihrer eigenen Arbeitskapazität in Einklang zu bringen.
“It's vitally important that the team drives the sprint goal and commits to something it can deliver. As much as the product owner wants to hear team members promise the moon and the stars, they can always bring in more work later if they complete what they’ve committed to,” says Jeff Crowl, a Scrum Master and Agile coach who has worked at Nike, T-Mobile, and other companies. “This goes double for a scaled enterprise, where other teams' sprints could actively depend on the work being done in two weeks,” he notes
Die Definition des Sprintziels ist entscheidend für den Erfolg
Experten sagen, dass sich der Aufwand für die Definition des Sprintziels auszahlt, da das Team so sicherstellen kann, dass der Sprint dem Unternehmen und seinen Kunden den maximalen Wert bietet.
Das Team schreibt das Sprintziel in Zusammenarbeit mit dem Product Owner (Produktinhaber). Die Zielbeschreibung ist kurz (nur ein paar Sätze).
Richard Hundhausen, President of Accentient Inc., which coaches companies in Scrum, says that the sprint goal is crucial: “I’d say the most common mistake is not collaborating with the product owner to create a sprint goal. Scrum teams typically jump right to forecasting without any consideration for a common theme for the work (the sprint goal). Without having a sprint goal, what will the Scrum team commit to? During the daily scrum, what goal will the development team plan their next 24 hours around?”
Scrum Trainer David Sabine of Agile consultancy Berteig says that without a clearly defined sprint goal, participants will struggle to determine what to tackle in the sprint. “The most common mistake in Sprint planning is that the team fails to achieve a clear sprint goal, making it impossible for team members to regulate the types of activity that belong in the sprint and the types of activity that do not,” he says.
Wie Ziele im Allgemeinen sind auch gute Sprintziele SMART (spezifisch, messbar, ausführbar, realistisch und terminiert). Ein gutes Sprintziel für ein Entwicklungsteam einer Online-Plattform für Freiberufler könnte zum Beispiel lauten: „Erstellen Sie einen Generator für Verdienstberichte, der eine Überprüfung des in einem Steuerjahr erzielten Einkommens für Freiberufler ermöglicht“ oder „Erstellen Sie eine Multimedia-Nachrichtenschnittstelle innerhalb der Plattform, sodass Freiberufler und Klienten nicht auf Nachrichtendienste Dritter angewiesen sind.“ Klar formulierte Ziele machen es leicht, Ziele und Fortschritte an diejenigen zu kommunizieren, die nicht direkt am Sprint beteiligt sind.
Bei der Formulierung eines Sprintziels sind eine Reihe von Überlegungen erforderlich. Wie passen zum Beispiel untergeordnete Ziele, die innerhalb eines einzelnen Sprints erreicht werden sollen, zu übergeordneten strategischen Zielen oder zur langfristigen Vision für ein Produkt? Welche Aufgaben im Produkt-Backlog sind für das Sprintziel relevant und sollten in das Sprint-Backlog aufgenommen werden? Und sind die Sprintziele basierend auf der Anzahl der verfügbaren Ressourcen und Entwickler erreichbar und realistisch? Denken Sie daran, Feiertage, Urlaube von Teammitgliedern und Firmenveranstaltungen miteinzubeziehen, wenn Sie die verfügbare Arbeitszeit betrachten.
Das Sprintziel ist keine reine Formsache, die abgeschlossen und dann beiseitegelegt werden muss, sobald der Sprint richtig in Gang kommt. Es gibt nicht nur die Richtung vor, in die die Arbeit während des Sprints gehen soll, sondern ist auch der Maßstab, an dem der Erfolg eines Sprints bei der anschließenden Nachprüfung gemessen wird. Es lohnt sich also, ein Ziel zu haben, das das Team mit seinen Ressourcen tatsächlich erreichen kann.
Die Definition des Sprint-Backlogs legt den Arbeitsplan des Teams fest
Das Sprint-Backlog enthält eine Liste der Aufgaben, die während eines Sprints abgeschlossen werden müssen. Es wird zwar gemeinsam vom Scrum-Team und dem Product Owner erstellt, aber letzterer ist in der Regel nicht an der detaillierten Sprintplanung beteiligt. Scrum-Teams sind per Definition selbstorganisierend, d. h. die Teammitglieder treiben den Prozess voran. Der Product Owner ist oft nicht in der Lage, zu entscheiden, wie das Team die Aufgaben bewältigen soll. In der Tat kann die enge Beteiligung des Product Owners für diesen Teil der Planung sogar kontraproduktiv sein.
Stattdessen besteht die Rolle des Product Owners in der Regel darin, das Sprintziel zu spezifizieren, mögliche Elemente für das Sprint-Backlog vorzubereiten, Anforderungen für diese Elemente zu formulieren und mit dem Entwicklerteam über die Zusammensetzung des Backlogs zu verhandeln, bis beide Parteien einen Konsens finden.
Natürlich behält sich der Product Owner das Recht vor, Fragen zu den Elementen im Sprint-Backlog, ihrer Reihenfolge und ihrer Erfüllung zu stellen. Das Scrum-Team erstellt sowohl eine Liste der Backlog-Elemente, für die es sich verpflichtet, als auch eine Liste von Aufgaben und Teilaufgaben, die für die Fertigstellung dieser Elemente erforderlich sind. Dabei schätzt das Team auch den Aufwand, der für die Fertigstellung jedes Backlog-Elements erforderlich ist, in der Regel unter Verwendung von Kurzbezeichnungen wie Kleidergrößen oder Story-Punkten.
Ron Madison, a Scrum Master at PayPal, says that it’s important at this stage to know what work comprises each task. “A mature team does tasking of stories before sprint planning, including both development and quality assurance,” he points out.
Der Arbeitsaufwand für einen einzelnen Sprint muss überschaubar bleiben, in der Regel mit etwas Pufferzeit. Es ist nicht ungewöhnlich, dass 20 % der Sprintkapazität als Puffer eingeplant werden. Dazu verwenden Teams eine Messzahl namens Sprint Velocity (Sprintgeschwindigkeit), die den Umfang der Arbeit in Story-Punkten angibt, die während eines einzelnen Sprints abgeschlossen wird. In der Regel verwendet man die Zahlen des letzten Sprints. Diese Praxis wird als „Yesterday's Weather“ bezeichnet, da man annimmt, dass die Geschwindigkeit des letzten Sprints die genaueste Vorhersage für die Geschwindigkeit des nächsten Sprints liefert. Die Sprintgeschwindigkeit wird basierend auf der Verfügbarkeit von Teammitgliedern und der Zusammensetzung des Scrum-Teams angepasst.
“The most common mistake is overfilling a sprint with work,” says Troy Magennis, President of Focused Objective, a software development consulting firm. “If you are doing lots of first time work, uncertainty will be very high, so it's preferable to acknowledge that fact up front and leave space to get customer satisfaction for and high quality from the stories you do choose. The second and third biggest mistakes of sprint planning are also overfilling. Don't let quality suffer because you bite off more than the team can chew.”
Die Sprintplanung kann in zwei verschiedene Phasen unterteilt werden: das WAS-Meeting und das WIE-Meeting. Während des WAS-Meetings wird das Sprintziel definiert, das Sprint-Backlog erstellt und die Teamkapazität festgelegt. Beim WIE-Meeting erstellt das Scrum-Team die Liste der Aufgaben, die zum Abschließen der einzelnen Backlog-Elemente erforderlich sind. Bei Software erstrecken sich diese Aufgaben in der Regel auf Entwurf, Implementierung, Tests und Dokumentation, wobei jede Aufgabe nicht länger als ein paar Tage dauern sollte. Wenn eine Aufgabe mehr als ein paar Tage dauert, deutet dies darauf hin, dass die Elemente im Sprint-Backlog zu groß für Sprintarbeiten sind – sie sollten möglicherweise aufgeteilt werden.
Dann schätzt das Scrum-Team den Arbeitsaufwand in Personalstunden, die für die Fertigstellung von Backlog-Elementen erforderlich sind, und berechnet die wahrscheinliche Gesamtdauer der Sprintaktivitäten. Wenn die Mitglieder des Scrum-Teams das Gefühl haben, dass sie während eines Sprints mehr (oder weniger) erledigen können, so können sie je nach Kapazität des Teams eine Iterationsanpassung anfordern, um den Arbeitsumfang zu erhöhen oder zu verringern.
Mike Cohn, President of Mountain Goat Software, cautions teams against overplanning. “The biggest problem I see during sprint planning is teams taking it too seriously. They do this by trying to identify every task they'll need to do. That level of detail isn't needed. Identify enough tasks to know you're selecting the right product backlog items, but that doesn't mean you have to include every little task. ‘Get in, get’ out should be the rule for sprint planning,” he says.
Wer ist bei Sprintmeetings anwesend?
Bei der Sprintplanung sind drei Hauptakteure beteiligt: das Scrum-Team, der Scrum Master und der Product Owner.
Das Scrum-Team besteht aus den Entwicklern, die sich um die praktischen Aspekte des Projekts kümmern. Während des Sprintplanungsmeetings ist es die Aufgabe des Teams, abzuschätzen und zu argumentieren, was während eines einzelnen Sprints übernommen werden kann und sollte. Das Scrum-Team verpflichtet sich dann, die Sprintziele zu erreichen, am Projekt zu arbeiten und eine neue Iteration zu liefern, die den Anforderungen entspricht, die während der Sprintplanung festgelegt wurden.
Der Scrum Master ist Vermittler, Ansprechpartner und Coach für das Scrum-Team. In der Regel handelt es sich dabei um ältere, erfahrene Entwickler, die wissen, wie sich die Arbeit des Teams in übergreifende strategische Ziele, langfristige Ziele und Kundenbeziehungen eingliedert. Der Scrum Master verwaltet die externen Beziehungen des Teams (einschließlich der Beziehung zum Product Owner) und stellt sicher, dass das Team die Prinzipien der Agile-Entwicklung befolgt. Bei der Sprintplanungssitzung führt der Scrum Master das Scrum-Team an, um für jeden Sprint geeignete Ziele zu setzen, und fungiert als Vermittler zwischen Entwicklern und dem Product Owner.
Laurens Bonnema, a Scrum Consultant with Xebia, says the Scrum master’s role is crucial to making sure the team acts as “value-driven problem solvers.” Says Bonnema, “An experienced Scrum master will help the team recognize the importance of a sprint goal and work with it to craft one at the start of the sprint planning. Usually, just asking the question, ‘So, what shall we focus on next sprint?’ will help a team select and slice the work.”
Der Product Owner ist der wichtigste Stakeholder des Projekts, also die Person oder Partei, für die das Projekt entwickelt wird. Das Ausmaß, in dem der Produktverantwortliche in die Sprintplanung einbezogen wird, variiert, aber in der Regel hält er sich bei der Planung von Aufgaben auf unterer Ebene zurück. Stattdessen behält er sich die Autorität vor, das Sprintziel festzulegen, Elemente im Sprint-Backlog auszuwählen und zu priorisieren und die Akzeptanzanforderungen für jedes Element zu definieren.
Was ist das Ziel des Sprint Review-Meetings?
Die Sprintplanung beginnt ironischerweise mit dem Abschluss des vorherigen Sprints. Am Ende jedes Sprints halten Sie ein Review-Meeting ab, in dem das Scrum-Team das Geleistete noch einmal durchgeht und erläutert, wie neue Eigenschaften und Funktionen genutzt werden.
In der Regel nehmen das Scrum-Team, der Product Owner, der Scrum Master, andere Entwickler in der Organisation, das Management und andere Stakeholder am Sprint Review (Sprintüberprüfung) teil. Sorgen Sie für eine ungezwungene Atmosphäre und einen guten Gesprächsfluss.
In dieser Sitzung bewerten Sie die Arbeit des Teams anhand des Sprintziels, das im Sprintplanungsmeeting festgelegt wurde. Hat das Team jedes Sprint-Backlog-Element erreicht? Haben Sie das übergeordnete Sprintziel erfüllt? Welche Lehren lassen sich für den nächsten Sprint ziehen?
Vorbereitung auf ein Sprintplanungsmeeting
Bevor Sie zu einem Sprintmeeting gehen, ist es eine gute Idee, sich die Produkt-Roadmap anzusehen. In diesem strategischen Dokument wird beschrieben, wie sich ein Produkt über eine lange Reihe von Sprints und Iterationen entwickeln wird. Elemente, die schließlich im Sprint-Backlog erscheinen, müssen mit der Produkt-Roadmap in Einklang gebracht werden, weshalb es sich auszahlt, die Roadmap im Kopf zu haben. Wenn Sprint-Backlog-Elemente nicht mit der Produkt-Roadmap übereinstimmen, besteht die Gefahr, dass das Produkt in eine unerwünschte Richtung geht.
Sie sollten auch ein Vorplanungsmeeting mit Vertretern des Scrum-Teams, dem Scrum Master und dem Projektverantwortlichen abhalten. Dieses Meeting, das einige Tage vor dem eigentlichen Sprintplanungsmeeting stattfindet, gibt allen die Möglichkeit, das Backlog zu pflegen. Backlog Grooming (Backlog-Pflege) ist der Prozess der Priorisierung, Schätzung, Beschreibung und Festlegung der Akzeptanzkriterien für Backlog-Elemente. Es beschleunigt die Planungssitzung und ermöglicht eine höhere Produktivität während eines Sprints, indem der Arbeitsaufwand und die verfügbaren Kapazitäten besser aufeinander abgestimmt werden.
“One of the biggest mistakes that I see related to sprint planning is an overall lack of preparation and solid understanding of the stories prior to the meeting. This [problem] can cause a myriad of issues. Teams need to fully understand a story before they can commit to the work, and, most often, a single one-to-four-hour meeting just isn’t going to cut it,” says Jennifer Guilbert, a Scrum Master with Capstone Consulting.
„Ich empfehle, in der Mitte des Sprints einen Prüfpunkt oder eine Grooming-Aktivität einzufügen, um das Team mit dem Product Owner zusammenzubringen. So können die zum nächsten Sprint-Backlog hinzugefügten Storys überprüft, Fragen gestellt und rechtzeitig vor dem nächsten Sprintplanungsmeeting geklärt werden. Dies macht Ihre Sprintplanung viel effizienter und kann die erforderliche Zeit sogar halbieren“, sagt sie.
Produkt-Backlog-Vorlage herunterladen – Excel
Sprint-Backlog-Vorlage herunterladen – Excel
Andere wichtige Stakeholder können von der Teilnahme an einem Vorplanungsmeeting profitieren, da sie allen die Möglichkeit gibt, sicherzustellen, dass sie mit der Priorisierung der Elemente im Backlog einverstanden sind. Dies ist auch ein guter Zeitpunkt, um den UX-Designer ins Boot zu holen, damit er sich Gedanken über Designänderungen machen kann, die für abgeschlossene Backlog-Elemente erforderlich sind.
Wenn es darum geht, Techniken zur Ermittlung der Prioritäten von Backlog-Elementen zu verwenden, stehen die Behebung von Fehlern und Störungen in der Regel an erster Stelle des Sprint-Backlogs. Eine weitere gängige Praxis ist die Verwendung der geschäftlichen Priorisierung, bei der Sie fragen, welche Elemente des Backlogs dem Unternehmen am meisten nützen, und ihnen daher die höchste Priorität zuweisen. Dabei gibt es einige mögliche Faktoren zu berücksichtigen, z. B. das Risiko, das mit einem Backlog-Element verbunden ist oder durch dieses gemindert wird, und die Höhe des Geschäftswerts, den ein Element voraussichtlich generieren wird. Wo diese Messzahlen fehlen, kann die MoSCoW-Priorisierungsmethode eine hilfreiche Technik sein: Jedes Element wird eingestuft als Must Have (Muss), Should Have (Soll), Could Have (Kann) oder Would Like To Have (Gewünscht). Und natürlich sollten Sie sich die Erfahrung des Scrum Masters bei der Priorisierung von Backlogs zunutze machen; schließlich ist er als Berater für das Team da.
Ein solches Vorplanungsmeeting hilft dem Product Owner auch dabei, sicherzustellen, dass die Elemente im Backlog der Definition des Teams bezüglich der Bereitschaft entsprechen, d. h. sofort umsetzbar sind. Da Sprints nicht viel Raum für Zeitverschwendung lassen, haben Entwicklungsteams eine Reihe von Kriterien für Backlog-Elemente, die zeigen, ob die Elemente bereit sind, bearbeitet zu werden.
In der Regel bereiten Sie die Backlog-Elemente mit den größten Werten für die Bereitschaft zuerst vor. Für ein typisches Team, das an typischen Aufgaben arbeitet, kann die Definition von „bereit“ einige oder alle der folgenden Punkte umfassen: Zuweisung von Story-Punktwerten, Beseitigung von Abhängigkeiten, Erstellung testbarer Beispiele und Definition von Akzeptanzkriterien. Eine einfache Abkürzung zur Erklärung einer soliden Definition von „bereit“ ist INVEST – unabhängig, verhandelbar, nützlich, schätzbar, klein, überprüfbar (Independent, Negotiable, Valuable, Estimable, Small, Testable). Mit INVEST validierte Storys sind bereit, in das Sprint-Backlog übernommen zu werden.
In ähnlicher Weise kann der Product Owner während des Planungsmeetings einige Zeit sparen, indem er Akzeptanzkriterien für Backlog-Elemente festlegt. Eine einfache, objektive Beschreibung dessen, was die Implementierung eines Backlog-Elements erreichen muss, sollte und könnte, beschleunigt die Diskussionen über Akzeptanzkriterien während des gesamten Planungsmeetings.
“The most common mistakes I see in sprint planning are stories that don’t have an acceptance criteria and product owners not showing up. Another mistake I see on the part of Scrum masters is trying to assign all stories to a specific team member,” says Aleksandr Kofman, a Scrum Master at information provider Elsevier.
Die Schritte eines Sprintplanungsmeetings
Hier sehen Sie, wie ein typisches Sprintplanungsmeeting abläuft:
-
Das Gesamtkonzept skizzieren: Vor dem Meeting verdeutlicht der Scrum Master dem Team, welche Ergebnisse es im Großen und Ganzen anstrebt und wie diese in die strategischen Ziele oder die Roadmap für ein Produkt passen. Es ist auch hilfreich, wenn der Product Owner auf die Besprechung von Elementen für zwei Sprints vorbereitet ist, um die mittelfristige Zielsetzung des Produkts in einen Kontext zu stellen.
-
Alle auf den neuesten Stand bringen: Das ist der richtige Zeitpunkt, um sämtliche Informationen über den bevorstehenden Sprint auszutauschen, die alle Beteiligten wissen sollten. Aktuelle Ergänzungen des Backlogs, Änderungen an der Verfügbarkeit von Teammitgliedern oder neue Beiträge der Stakeholder können an dieser Stelle mitgeteilt werden.
-
Die Zielgeschwindigkeit für den anstehenden Sprint vorstellen: Die Geschwindigkeit ist die Gesamtzahl der während eines Sprints abgeschlossenen User Storys. In der Regel wird diese Zahl vom letzten abgeschlossenen Sprint (nach dem Yesterday’s Weather-Prinzip) abgeleitet. Wenn sich die Zusammensetzung – nicht die Größe – des Scrum-Teams seither geändert hat, verwenden Sie die durchschnittliche Geschwindigkeit der letzten drei Sprints. Wenn dies der erste Sprint Ihres Teams ist, sind acht Story-Punkte pro Entwickler und Sprint ein guter Richtwert; Sie können dies später immer noch anpassen.
-
Teamkapazität bestätigen: Die Teamkapazität setzt sich aus der Gesamtzahl der Arbeitsstunden zusammen, die der Sprint in Anspruch nehmen wird. Wenn also ein 10-köpfiges Scrum-Team 10 Stunden pro Tag an einem 10-Tage-Projekt arbeitet, beträgt die Kapazität 1.000 Stunden. Teams ziehen jedoch in der Regel 20 % bis 40 % von der maximalen Kapazität ab, um eine realistischere Zahl zu verwenden, die Ausfallzeiten, Betriebsaufwand und verlorene Arbeitszeiten berücksichtigt. Angesichts unvermeidbarer Abhängigkeiten zwischen Backlog-Elementen kann die praktische Kapazität außerdem durch eine Art Dominoeffekt weiter reduziert werden, bei dem verspätete Aufgaben die nachfolgenden weiter verschieben. Sollten sich bestimmte Faktoren auf die Sprintgeschwindigkeit oder die Teamkapazität auswirken, erfassen Sie sie in diesem Stadium.
-
Die Definition von „Erledigt“ prüfen: Die Definition der Fertigstellung ist eine Momentaufnahme davon, wie die resultierende Iteration am Ende des Sprints aussehen wird. Es ist wichtig, dass sich diejenigen, die die Arbeit ausführen, und diejenigen, die sie überprüfen, vor Beginn des Sprints auf eine Definition von „Erledigt“ einigen.
-
Entscheiden, welche Produkt-Backlog-Elemente in das Sprint Backlog aufgenommen werden sollen: In dieser Phase entscheidet das Scrum-Team auch, ob die Backlog-Elemente zu groß sind, um in einem einzigen Sprint abgeschlossen zu werden, und deshalb verschoben werden müssen.
-
Den Ressourcenbedarf ermitteln, festlegen, wer was tun wird, und den Arbeitsaufwand abschätzen: Wenn es zu viel Arbeit gibt, die das Scrum-Team vernünftig bewältigen kann, wird der Scrum Master das an dieser Stelle erkennen. Weisen Sie die Arbeit zu und stellen Sie sicher, dass die Aufgaben der Einzelnen mit ihrer Kapazität übereinstimmen.
-
Akzeptanzkriterien definieren: Die Akzeptanzkriterien sind messbare Standards dafür, ob ein Backlog-Element erfolgreich abgeschlossen wurde. Die Festlegung dieser Kriterien ist das Vorrecht des Projektinhabers, auch wenn das Scrum-Team über den Scrum Master einen gewissen Verhandlungsspielraum hat.
-
Alle Annahmen, neuen Probleme oder Abhängigkeiten, die während der Planung identifiziert wurden, bestätigen und aufzeichnen: Diese Informationen sollten in das Produkt-Backlog integriert werden.
-
Konsens einfordern: Dies ist das Vorrecht des Scrum Masters. Etwa zur gleichen Zeit geben das Scrum-Team und der Product Owner an, ob sie dies für den bestmöglichen Plan für den Sprint halten.
-
Die involvierten Aufgaben ausarbeiten: Wenn das Scrum-Team mehr Informationen benötigt, insbesondere über die Besonderheiten der Elemente im Sprint-Backlog, stellen Sie an dieser Stelle alle weiteren notwendigen Fragen, damit Sie die User Storys in detaillierte Aufgaben umwandeln können.
So organisieren und führen Sie ein Sprintplanungsmeeting durch
Vielleicht führen Sie Ihr erstes Sprintplanungsmeeting durch oder möchten Ihre Meetings produktiver gestalten. Es ist wichtig zu wissen, was besprochen werden muss, aber Sie sollten auch sicherstellen, dass Sie die Logistik im Griff haben und die Materialien bereitstellen.
Für einen einmonatigen Sprint müssen Sie etwa vier Stunden Zeit einplanen – eine Stunde Meetingzeit für jede Woche Sprintzeit. Idealerweise treffen Sie sich persönlich, aber wenn Sie Teammitglieder an verschiedenen Standorten haben, sorgen Sie dafür, dass Ihre Konferenztechnik gut funktioniert.
Wenn Sie sich persönlich treffen, benötigen Sie einen Arbeitsbereich, der groß genug ist, um alle unterzubringen. Verwenden Sie ein visuelles System wie Haftnotizen, ein Whiteboard oder ein elektronisches Hilfsmittel. (Holen Sie sich einige verschiedenfarbige Haftnotizen, um Backlog-Elemente darzustellen.) Und da das Team eine Weile dort sein wird, brauchen Sie Snacks und Kaffee, um die Teilnehmer bei Laune zu halten.
Agenda für Sprintplanungsmeetings herunterladen
Hängen Sie vor Beginn des Meetings das Sprintziel und die Geschwindigkeit im Meetingraum aus, damit sie für jeden klar sind.
“Sprint planning should be highly interactive,” says Certified Scrum Trainer Adam Weisbart, who has worked with Oracle, Symantec, Hewlett Packard, and Pfizer. “If you use a software tool to wrangle Scrum artifacts, print out your product backlog items and tape them to the wall instead for this meeting. Have people close their laptops and shut off their phones, and have face-to-face conversations around these physical items. You'll be amazed at how much more life this brings to your meeting and your product,” he adds.
Verwenden Sie Ihre Haftnotizen, um Backlog-Elemente zu dokumentieren: Jede Elementart kommt auf einen andersfarbigen Notizzettel. Sie benötigen mindestens drei Farben: eine für User Storys, eine für Aufgaben und eine für Fehler. Die Haftnotizen werden dann in der Reihenfolge ihrer Priorität an der Wand oder Tafel angebracht. Sie sollten dieses visuelle Backlog für alle Remote-Teammitglieder nachbilden.
Eröffnen Sie das Meeting mit einer kurzen Lobrede auf das, was das Team im letzten Sprint erreicht hat, um einen guten Start hinzulegen. Als Nächstes stellt der Scrum Master oder Product Owner die möglichen Storys für das Sprint-Backlog vor, einschließlich derer, die noch vom letzten Sprint übrig sind. Sollte dies nicht in der Vorplanung geschehen sein, müssen die Storys in ihrer Größe angepasst werden – dafür gibt es mehrere Möglichkeiten. Einige Teams verwenden T-Shirt-Größen (XS, S, M, M+, L, XL, XXL, XXXL), während andere Story-Punkte mithilfe der Fibonacci-Sequenz zuweisen (1, 2, 3, 5, 8, 13, 21).
Unabhängig davon, welches Größensystem Sie verwenden, sind relative Werte wichtiger als Rohwerte. Beginnen Sie mit zwei Storys, entscheiden Sie, welche größer ist, und setzen Sie sie dann in die entsprechende Reihenfolge. Nehmen Sie als Nächstes eine dritte Story und entscheiden Sie, wie groß sie im Vergleich zu den anderen beiden ist, fügen Sie sie der Rangfolge hinzu, und so weiter. Die Summe der Story-Punkte sollte geringer sein als die Geschwindigkeit des Teams. Alle Produkt-Backlog-Elemente, die in das Sprint-Backlog aufgenommen werden, müssen ebenfalls als arbeitsbereit eingestuft werden.
Die Analyse jeder einzelnen User Story kann für das Scrum-Team sehr viel Zeit in Anspruch nehmen und es gibt einige Schritte zu beachten. Entspricht diese Story dem aktuellen Stand oder hat sich ihre Definition geändert? Gibt es neue Informationen zu berücksichtigen? Sind die Schätzungen für die Story noch gültig?
Scrum Master Andrey Grubin of gaming company PlasmaNet says stories should be evaluated in the context of the sprint goal. “Try to determine from capacity, past velocity, and an overall comfort level within the team whether the proposed stories are achievable within the sprint. Don’t hesitate to consult the product owner if there are any questions or concerns around the proposed stories,” he recommends.
Sobald die Definition der Story festgelegt ist, muss sie in Aufgaben unterteilt werden. (Einige dieser Aufgaben werden zu eigenständigen User Storys.) Das Team entscheidet, ob und welche Fachkenntnisse für diese Aufgaben erforderlich sind und fragt auch, wie die Story getestet werden soll.
Genau wie bei Story-Punkten und der Geschwindigkeit sollte die geschätzte Dauer der Aufgaben geringer sein als die Kapazität des Teams für den Sprint. Aufgaben und User Storys, die in das Sprint-Backlog verschoben werden, werden Fälligkeitstermine zugewiesen, wobei die Anzahl der Arbeitstage berücksichtigt wird sowie die Tatsache, dass einige Teammitglieder Urlaub nehmen oder in Teilzeit im Scrum-Team arbeiten werden.
Denken Sie daran, dass nicht nur User Storys und die dazugehörigen Aufgaben Platz im Backlog erhalten, sondern auch Fehlerbehebungen, die einen Teil der Kapazität des Scrum-Teams in Anspruch nehmen. Aber wie entscheidet man, wie viel Platz jedes Backlog-Element bekommt? Eine Möglichkeit besteht darin, einen festen Anteil der Kapazität – zum Beispiel 20 % – für Fehlerbehebungen zuzuweisen. Alternativ können Fehlerbehebungen mit User Storys verknüpft und dann wie User Storys dimensioniert und nach Prioritäten geordnet werden.
Schließlich erstellen das Scrum-Team, der Scrum Master und der Product Owner eine Definition von „Erledigt“, einschließlich einer Art von Testmesszahl, um die Qualität der neuen Iteration sicherzustellen.
Im Idealfall endet die Sprintplanungssitzung damit, dass einige Zielergebnisse erreicht wurden. Dazu gehören folgende Punkte: Das Scrum-Team hat ein gutes Gefühl bei der Festlegung des Ziels und das Ziel muss mit der strategischen Vision und der Roadmap für ein Produkt übereinstimmen; eine angemessene Dokumentation des Sprintplans; die Erstellung eines Burndown-Charts (ein Diagramm, in dem die noch zu erledigende Arbeit und die verbleibende Zeit verglichen werden), um den geplanten Arbeitsfortschritt anzuzeigen; und jeder Entwickler im Scrum-Team sollte genau wissen, woran er arbeiten wird, sobald der Sprint beginnt.
Ist das Sprint-Backlog in der richtigen Reihenfolge und das Sprintziel im Blick, kann der Sprint beginnen.
Sprintplanung für agiles Marketing
Softwareentwickler sind zwar der Inbegriff von Agile-Experten, aber sie sind nicht die einzigen. Viele Marketingteams sind ebenfalls begeistert von Agile.
Natürlich müssen die Marketingspezialisten keine festen Software-Iterationen veröffentlichen. Vielmehr sind es laufende (oft langfristige) Projekte, die eine Vielzahl von Aktivitäten umfassen. Sie müssen kontinuierlich mit kurz- und mittelfristigen Prioritäten jonglieren, nicht selten mit einem klaren Ziel vor Augen für jede neue Reihe von Aufgaben.
Für Marketingfachleute ist der Einsatz agiler Methoden also eine Möglichkeit, koordiniert auf sich ändernde Marktbedingungen zu reagieren und gleichzeitig die Effizienz zu maximieren und ein klar definiertes Ziel zu erreichen.
Sprints und Sprintplanung für die Softwareentwicklung und das Marketing sind im Großen und Ganzen sehr ähnlich. Es gibt jedoch einige bedeutende Unterschiede.
Zum einen ist die Länge von Marketing-Sprints in der Regel kürzer als die von Sprints in der Softwareentwicklung. Der typische Marketingsprint dauert nicht länger als zwei Wochen, während Sprints in der Softwareentwicklung von einem oder zwei Monaten keine Seltenheit sind.
Zweitens sind Änderungen am Sprint-Backlog im Laufe des Sprints im Marketing häufiger als in der Softwareentwicklung. Dieser Unterschied bezieht sich auf die starreren Einschränkungen durch die technischen Aufgaben, die mit der Softwareentwicklung verbunden sind, während im Marketing ein größerer Spielraum besteht.
Drittens dürfte es in einem Scrum-Team für Marketing eine größere Bandbreite an Spezialisierungen geben als in einem Scrum-Team für Softwareentwicklung, da ersteres mehr Disziplinen umfasst.
Bewährte Vorgehensweisen für die Sprintplanung
Experten empfehlen einige bewährte Vorgehensweisen, um das Beste aus Ihrem Sprintplanungsmeeting herauszuholen.
Wenn Sie die Einladung zum Meeting versenden, fügen Sie die Agenda hinzu. Sie sollten auch einen Link zu den möglichen User Storys aus dem Produkt-Backlog hinzufügen, damit die Entwickler vor dem Sprint-Meeting etwas Zeit haben, sie durchzulesen.
Wenn der Product Owner eine Liste mit möglichen User Storys aus dem Produkt-Backlog erstellt, sollte er Storys auswählen, die die Kapazität des Scrum-Teams übersteigen. Der Grund dafür ist, dass der Scrum Master und das Scrum-Team wahrscheinlich einige User Storys ablehnen oder auf einen späteren Sprint verschieben werden. Wenn der Product Owner Storys ausgewählt hat, die weniger als die volle Kapazität des Teams in Anspruch nehmen, führen abgelehnte Storys während des Sprints zu einer Verschwendung von Kapazitäten.
Bedenken Sie, dass während des Sprintplanungsmeetings der Scrum Master und nicht der Product Owner die Leitung übernimmt. Wie das Scrum-Team ist auch der Product Owner eher ein Mitwirkender im Meeting: Product Owner beantworten alle Fragen der Entwickler, erläutern User Storys und verhandeln unter Vermittlung des Scrum Masters die Akzeptanzkriterien.
Auch ist es hilfreich, alle daran zu erinnern, wie sie sich am effektivsten einbringen können und was sie von anderen Teilnehmern erwarten können und was nicht. Der Product Owner übernimmt beispielsweise die Führung bei der Erstellung des Sprintziels und ist für die Definition des Sprintumfangs, die ausführliche Beschreibung jeder User Story – einschließlich einer Definition von „Erledigt“ – und die Priorisierung des Produkt-Backlogs verantwortlich.
Der Scrum Master kümmert sich um die Logistik des Meetings und verhandelt über wichtige Messzahlen wie Sprintgeschwindigkeit und praktische Teamkapazität. Sie übernehmen auch die Führung bei der Fertigstellung des Sprint-Backlogs und moderieren die Verhandlungen zwischen dem Product Owner und dem Scrum-Team.
“The most common mistake made during sprint planning is not having a clear idea about the team's capacity and, hence, ending up with inconsistent velocity, which, again, induces errors on estimated commitments to be made by the team,” says Parashuram Bellikatti, a specialist in Agile transformations and Director of the Global Agile Centre for Excellence in Bangalore.
Das Scrum-Team sammelt alle Informationen, die es für den kommenden Sprint benötigt, und verpflichtet sich zu einem Sprint-Backlog, dessen Erreichen es für realistisch hält. Es ist auch die Pflicht des Teams, den Scrum Master zu informieren, wenn es während des Sprints zu irgendeinem Zeitpunkt nicht verfügbar ist.
Eine häufige Ursache für Störungen bei der Sprintplanung, sagt Agile-Coach Kevin Brunner, ist die Person, die für das Backlog zuständig ist. Wenn sie sich nicht auf das Meeting vorbereitet hat oder dem Team nicht zutraut, selbst Entscheidungen zu treffen, entsteht im Team eine Abwehrhaltung statt Verbindlichkeit. Insbesondere die Entwickler könnten sich darüber beschweren, dass das Meeting Zeitverschwendung ist, weil die User Storys nicht ausgearbeitet wurden oder weil ihre Anwesenheit nicht erforderlich ist, da ihr Scrum Master oder Product Owner sowieso alle Entscheidungen alleine trifft.
Um eine gesunde Teamdynamik zu fördern, kann der Scrum Master laut Brunner folgende drei Prinzipien befolgen:
-
Visualisieren: Mit einer erfolgreich abgeschlossenen Iteration springen Sie zum Ende eines Sprints und arbeiten von dort aus rückwärts, um Akzeptanzkriterien auszuhandeln und die Informationen zu extrahieren, die für die Lieferung der abgeschlossenen Iteration erforderlich sind. Durch die Visualisierung erhält das Team ein konkretes Endprodukt, auf das sich die Bemühungen konzentrieren werden.
-
Kultivieren: Die Gepflogenheit, Entscheidungen im Team im Konsens zu treffen und die Beiträge der Teammitglieder anzuhören und zu respektieren. Die Kultivierung gibt dem Team auch die Zeit, die es benötigt, um Entscheidungen zu treffen, und stellt sicher, dass wichtige Aspekte des Sprints wie Umfang und Zeitschätzungen berücksichtigt werden.
-
Reflektieren: Die Gepflogenheit, auf einen Sprint zurückzublicken, sobald er vorbei ist, um herauszufinden, was gut gelaufen ist, was nicht, und wie die Dinge verbessert werden können.
Eine gesunde Teamdynamik, so Agile-Coach Tony Solomita, wird durch drei Gewohnheiten definiert: die Vorbereitung des Backlogs vor dem Planungsmeeting, das Zuhören bei der Erstellung von Schätzungen und der Fertigstellung des Sprint-Backlogs sowie der Respekt vor der Autorität des Product Owners bei der Frage, warum eine bestimmte Funktion benötigt wird, und der Autorität der Entwickler darüber, wie diese Funktion geliefert wird.
Häufig gestellte Fragen zur Sprintplanung
Hier sind die am häufigsten gestellten Fragen zur Sprintplanung:
Wie werden Abhängigkeiten zwischen Aufgaben am besten gehandhabt? Es gibt mehrere Möglichkeiten, den potenziellen Zeitverlust durch Aufgabenabhängigkeiten zu mindern. Erstens kann die Aufgabenplanung während des Sprintplanungsmeetings komplexe Abhängigkeiten aktiv minimieren oder eliminieren, indem Sie User Storys in Aufgaben unterteilen. Zweitens können Sie, wenn möglich, Pufferzeit zwischen abhängigen Aufgaben einbauen. Drittens kann die Verwendung von lose gekoppelten, anpassungsfähigen Designs und Entwicklungstechniken, wie Mock-Objekte, Entwicklern helfen, mit den Auswirkungen von Abhängigkeiten umzugehen. Und viertens können Entwickler, die in unmittelbarer Nähe zueinander arbeiten, abhängigkeitsbedingten Problemen vorbeugen, da die Kommunikation erleichtert wird.
Für wie viel sollte sich jedes Teammitglied eintragen? Nach dem Yesterday's Weather-Prinzip sollte sich jedes Teammitglied dazu verpflichten, höchstens so viele Story-Punkte zu übernehmen, wie es im letzten Sprint geschafft hat.
Wie werden Iterationen geplant, wenn die Teamgrößen variieren? Wiederkehrende Änderungen der Teamgröße sind zwar nicht ideal, aber manchmal unvermeidbar. Wenn sich die Größe eines Teams ändert, berechnen Sie die durchschnittliche Anzahl der Story-Punkte, die pro Entwickler im letzten Sprint in Angriff genommen wurden. Dann multiplizieren Sie sie mit der Anzahl der Entwickler, die am kommenden Sprint teilnehmen, um einen groben Richtwert für die Sprintgeschwindigkeit zu erhalten. Möglicherweise müssen Sie diese Zahl weiter anpassen, je nachdem, wer genau das Team verlässt und wer neu hinzukommt.
Wie wird der Mehraufwand, z. B. für Meetings oder das Schreiben von E-Mails, berücksichtigt? Es gibt keine Faustregel für die Berechnung des Overheads, da er von Team zu Team unterschiedlich ist. Die meisten Teams gehen einfach davon aus, dass in jedem Sprint gleich viel Zeit für den Overhead aufgewendet wird und dass die Sprintgeschwindigkeit früherer Sprints genau die für den Overhead aufgewendete Zeit widerspiegelt.
Wie sollten Fehlerbehebungen berücksichtigt werden? Es gibt mehrere Möglichkeiten, dies anzugehen. Eine besteht darin, Fehler als User-Storys zu behandeln und den Arbeitsaufwand wie für andere Elemente im Sprint-Backlog zu schätzen. Ein anderer, riskanterer Ansatz besteht darin, Fehlern keine Story-Punkte zuzuweisen, was die Arbeitsgeschwindigkeit des Teams senkt. Das Risiko dieses Ansatzes besteht darin, dass er nur funktioniert, wenn Sie in jeder Iteration den gleichen Arbeitsaufwand für die Fehlerbehebung leisten. Wenn der Arbeitsaufwand für die Fehlerbehebung variiert, wird sich die Geschwindigkeit von Sprint zu Sprint drastisch ändern, was die Planung für zukünftige Sprints viel schwieriger macht.
Warum sollten Iterationen immer die gleiche Länge haben? Kurz gesagt, die Antwort lautet: Rhythmus und Konsistenz. Die Abfolge eines Sprints verläuft viel reibungsloser, wenn er einem regelmäßigen, leicht vorhersehbaren Zyklus folgt, was die Sprintplanung erheblich vereinfacht.
Wie wird der Zeitaufwand für Tests und Dokumentationen berücksichtigt? Am einfachsten ist es, die für Tests und Dokumentationen aufgewendete Zeit als separate Aufgabe für jede User Story zu einzurechnen. Eine Alternative besteht darin, ein separates Element für das Sprint-Backlog für Tests und Dokumentationen zu erstellen.
Sollten Funktionsschätzungen während der Iterationsplanung überarbeitet werden? Nur wenn die ursprüngliche Schätzung sehr ungenau ist.
Sollten Aufgabenschätzungen während einer Iteration überarbeitet werden? Nein. Nachdem Sie die Iterationsplanung abgeschlossen haben, belassen Sie die Aufgabenschätzungen so, wie sie sind. Wahrscheinlich wird sich der Scrum Master jedoch notieren, warum das Team eine Aufgabe geändert hat, damit diese Information in der zukünftigen Sprintplanung wieder aufgegriffen werden kann.
Sollten alle Teams nach demselben Iterationszeitplan arbeiten? Dies hängt von der Anzahl der parallel arbeitenden Scrum-Teams und der Verfügbarkeit von unterstützenden Mitarbeitern ab. Wenn es keine Einschränkungen für die Arbeit mehrerer Teams an Iterationen gäbe, die gleichzeitig beginnen und enden, wäre die daraus resultierende Synchronisierung für das Management von großem Nutzen. Dies würde das Risiko verringern, dass die Arbeit eines Teams Änderungen im Sprint-Backlog eines anderen erzwingt, da sich die Teams bei ihrer Sprintplanung miteinander abstimmen würden. In der Praxis arbeiten Scrum-Teams jedoch nicht getrennt voneinander und es gibt eine begrenzte Anzahl von Personen, die unterstützende Rollen in mehreren Scrum-Teams ausfüllen und Iterationen mit gestaffelten Start- und Enddaten schätzen.
Typische Fehler und Warnzeichen bei der Sprintplanung
Der erfahrene Scrum Master kennt die Warnsignale, die auf eine fehlerhafte Sprintplanung hindeuten. Im Folgenden finden Sie die wichtigsten Anzeichen.
Wenn ein Team wiederholt sein Sprint-Backlog nicht abschließen kann – d. h. die User Storys werden immer wieder in den nächsten Sprint verschoben –, so zeigt dies, dass die Gruppe ihre eigene Geschwindigkeit überschätzt und sich selbst überfordert. Damit die Planung korrekt (und tatsächlich nützlich) ist, muss der Scrum Master die Geschwindigkeit des Scrum-Teams nach unten korrigieren.
Wenn jedoch die gleichen Funktionen immer wieder in den nächsten Sprint geschoben werden, vermeidet das Team vermutlich absichtlich, bestimmte User Storys oder Fehlerbehebungen in Angriff zu nehmen. In dieser Situation sollte untersucht werden, ob es Probleme mit diesen User Storys oder Fehlern gibt, die während der Sprintplanung nicht angesprochen werden.
Die Nichtfertigstellung des Sprint-Backlogs könnte auch auf eine Überplanung hinweisen, also darauf, dass die Entwickler bei ihrer Arbeit über das Ziel hinausschießen und mehr tun, als notwendig ist. Dies würde zu einer Überprüfung der Anforderungen für die angeforderten Funktionen führen, um sicherzustellen, dass das Team keinen unnötigen Aufwand auf sich nimmt.
Was Sie nicht tun sollten: Typische Fehler bei der Sprintplanung
Eine Sprintplanungssitzung kann durch einige gängige Fallstricke sabotiert werden:
-
Der Product Owner erstellt das Sprint-Backlog selbst, ohne die Entwickler einzubeziehen: Dadurch wird das Scrum-Team auf ein Backlog festgelegt, bei dessen Erstellung es kein Mitspracherecht hatte. Damit sinkt sowohl ihr Engagement im Planungsprozess als auch die Wahrscheinlichkeit, dass das Sprintziel erreicht wird.
-
Der Scrum Master zeigt den Entwicklern die möglichen User Storys im Sprintplanungsmeeting zum ersten Mal: Dies ist unnötige Zeitverschwendung und führt dazu, dass sich Planungsmeetings viel länger hinziehen als sie sollten. Sofern Sie das Backlog gepflegt haben, ist es ganz einfach, die möglichen User Storys in die Agenda des Meetings aufzunehmen. User Storys, die nicht den INVEST-Kriterien entsprechen, führen zu ähnlichen Problemen.
-
Das Team legt sich nicht auf eine Definition von „Erledigt“ fest: Wenn dies passiert, liefert das Team ein Produkt, das am Ende der Iteration unvollständig ist. Ein Zeichen dafür, dass sich dieses Problem abzeichnet, ist, dass nicht alle Elemente des Sprint-Backlogs in eine Reihe von überschaubaren Aufgaben aufgeteilt wurden.
-
Teilaufgaben werden nicht gründlich abgeschätzt: Sie können dieses Problem erkennen, wenn Aufgaben anscheinend nicht genau im Verhältnis zueinander geschätzt werden. (Eine sehr komplexe Aufgabe ist nicht ein ausreichend großes Vielfaches einer einfachen Aufgabe).
-
Der Scrum Master braucht zu lange, um das Sprint-Backlog in einem elektronischen Tool zusammenzustellen: Dies kann dazu führen, dass das Scrum-Team in den ersten Tagen des Sprints blind arbeitet und den tatsächlichen Fortschritt nicht erkennen kann.
-
Die möglichen User Storys werden vor dem Hinzufügen in das Sprint-Backlog nicht mit anderen Stakeholdern besprochen: Auch diese Art von Fehler lädt unzufriedene Stakeholder dazu ein, nach dem Start des Sprints eine Änderung des Backlogs zu verlangen. Einige Product Owner können dies auch tun, selbst nachdem sie das ursprüngliche Sprint-Backlog unterzeichnet haben – dies kann sehr frustrierend sein. Für manche Scrum-Teams ist ein gewisses Maß an Änderungen am Backlog praktisch unvermeidlich. In diesen Fällen gibt es eine Reihe von möglichen Abhilfemaßnahmen. Eine davon ist, die Länge des Sprints zu erhöhen oder die Kapazität des Sprints absichtlich zu unterschätzen, sodass im Falle von zusätzlichen Aufgaben mehr Spielraum besteht. Für Teams, deren Arbeit häufig unterbrochen wird, kann die beste Lösung darin bestehen, die Zeit, die für die Sprintplanung aufgewendet wird, zu reduzieren, da diese Tätigkeit nicht ihrem eigentlichen Zweck dienen kann.
-
Das Scrum-Team präzisiert die Aufgaben und Teilaufgaben nicht ausreichend: Dies ist in der Regel ein Zeichen dafür, dass das Team durch die Planung gelangweilt ist und einfach loslegen will. Unzureichende Detaillierung birgt die Gefahr, dass Schätzungen aus dem Gleichgewicht geraten, wenn Entwickler feststellen, dass Aufgaben zeitaufwändiger waren als erwartet.
-
Die Mitglieder des Teams zögern, Schritte zu besprechen: Dadurch wird dem Rest des Teams die Möglichkeit genommen, dazuzulernen.
-
Das Team hat keinen Scrum Master, der die Planung übernimmt: Ohne einen Scrum Master, der das Tempo der Planungssitzung kontrolliert, versuchen alle, so schnell wie möglich fertig zu werden – das kann zu einer äußerst ineffektiven Planungssitzung oder dem Überspringen wichtiger Details führen.
Verbessern Sie die Sprintplanung mit Smartsheet für das Projektmanagement
Von einfacher Aufgabenverwaltung und Projektplanung bis zu komplexem Ressourcen- und Portfoliomanagement hilft Ihnen Smartsheet, die Zusammenarbeit zu verbessern und das Arbeitstempo zu erhöhen – und befähigt Sie, mehr zu schaffen. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.