In Kürze: 20 Sprint Planning Anti-Patterns
Das Sprint Planning ist ein zentrales Scrum-Ereignis, welches entscheidet, wie sich das Leben Ihrer Kunden mit dem nächsten Inkrement verbessern wird. Erfahren Sie mehr darüber, wie Sie Ihren Kunden durch die Vermeidung von 20 gängigen Sprint Planning Anti-Patterns helfen können.
🗳 Update: Join the poll and its lively discussion on LinkedIn.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 35.000 Abonnenten anschließen.
🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!
📅 Nehmen Sie am 30. Mai 2022 teil—wir sind bereits 210 Teilnehmer: HoA #42: The Skinny on Lean Roadmapping and OKRs w/ Janna Bastow.
Der Zweck des Sprint Plannings
Der Zweck des Sprint Plannings besteht darin, Übereinstimmung zwischen den Entwicklern und dem Product Owner über das, was als nächstes gebaut werden soll, herzustellen und den Kunden den höchstmöglichen Wert zu liefern. Der Product Owner stellt das Geschäftsziel vor, das der bevorstehende Sprint erreichen soll, das Scrum-Team erstellt gemeinsam ein Sprint-Ziel, und das Entwicklungsteam prognostiziert die zur Zielerreichung erforderliche Arbeit, indem es die entsprechenden Einträge aus dem Product Backlog auswählt und in das Sprint-Backlog überträgt. Außerdem müssen die Entwickler einen Plan ausarbeiten, wie sie Ihre Prognose erfüllen können.
Seit der Ausgabe des Scrum Guide von 2020 ist es nicht mehr zwingend erforderlich, dass das Scrum-Team sich verpflichtet, mindestens ein dringliches Verbesserungsvorhaben aus der vorherigen Sprint-Retrospektive in Angriff zu nehmen.
Der Zweck des Sprint Plannings laut Scrum Guide ist wie folgt:
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.
Laut dem Scrum Guide beantwortet das Sprint Planning drei Fragen:
- Why is this Sprint valuable? (The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.)
- What can be Done this Sprint? (Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence. Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
- How will the chosen work get done? (For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value. The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.)
Source: Scrum Guide 2020.
Wenn das Scrum-Team die Verfeinerung des Product Backlogs in der Vergangenheit erfolgreich genutzt hat, um ein brauchbares Artefakt zu erstellen und zu pflegen, dann benötigt das Sprint Planning viel weniger Zeit als die acht Stunden, die der Scrum-Guide für einen Sprint von einem Monat Dauer als maximale Zeitspanne angibt. Im Grunde genommen passen die Entwickler und der Product Owner den zuvor besprochenen Umfang des bevorstehenden Sprints an die verfügbare Kapazität an.
Sollte eine wertvolle neue Aufgabe quasi über Nacht auftauchen und der Product Owner anstreben, dass diese Aufgabe auch Teil des nächsten Sprints wird, muss die Vorplanung dieses Sprints angepasst werden. Folglich können einige zuvor in Betracht gezogene Product Backlog-Einträge nicht in das Sprint Backlog aufgenommen werden. Ein gutes Team kann dies in zehn bis 30 Minuten bewältigen, bevor die Entwickler damit beginnen, die Arbeit des kommenden Sprints genauer zu planen und Arbeitsaufgaben in kleinere Jobs zu zerlegen.
Sprint Planning Anti-Patterns
Es gibt im Wesentlichen drei Kategorien von Sprint Planning Anti-Patterns. Sie betreffen die Entwickler, den Product Owner und das Scrum-Team:
Sprint Planning Anti-Muster der Entwickler
- Kapazität? Die Entwickler überschätzen ihre Kapazität und übernehmen zu viele Aufgaben. (Die Entwickler sollte stattdessen alles in Betracht ziehen, was ihre Leistungsfähigkeit beeinträchtigen könnte. Die Liste dieser Gründe ist lang: Feiertage, neue Teammitglieder und solche, die sich im Urlaub befinden, ausscheidende Teammitglieder, kranke Teammitglieder, Firmen-Overhead, Scrum-Events und Praktiken wie die Verfeinerung des Product Backlogs und andere Meetings, um nur einige zu nennen).
- Ignorieren technischer Schulden: Die Entwickler verlangt keine ausreichende Kapazität, um technische Schulden und Fehler während des Sprints zu beseitigen. (Als Faustregel gilt, dass etwa 20 % der Kapazität in jedem Sprint gut eingesetzt ist, um Bugs zu eliminieren und die Codebasis zu überarbeiten. Wenn der Product Owner die Notwendigkeit dieser Arbeit ignoriert und die Entwickler diese Einstellung akzeptieren, wird sich das Scrum-Team über kurz oder lang in einer Abwärtsspirale wiederfinden und sich langsam aber stetig in eine auf den Output fokussierte Feature-Fabrik verwandeln. Seine zukünftige Fähigkeit, neue wertvolle Produkte zu liefern, wird abnehmen, denn technische Exzellenz ist die Voraussetzung für jegliche From von Business-Agilität. Erfahren Sie mehr über technische Schulden und Scrum.)
- 100 % Auslastung: Das Entwicklungsteam verlangt vom Product Owner keine 20 % Slack Time. (Wenn die Auslastung eines Teams immer am Anschlag verharrt, wird seine Leistung mit der Zeit abnehmen. Dies wird besonders in einer Organisation mit einem volatilen Tagesgeschäft passieren. Als Folge davon wird sich jeder darauf konzentrieren, seine Aufgaben zu erledigen. Es wird weniger Zeit zur Verfügung stehen, um beispielsweise Teamkollegen zu unterstützen oder Pair Programming durchzuführen. Das Team wird kleinere oder dringende Probleme nicht mehr zeitnah angehen. Einzelne Teammitglieder werden zu Engpässen werden, die den Arbeitsfluss innerhalb des Teams ernsthaft behindern können. Und schließlich wird die „Ich bin beschäftigt“-Haltung die Entstehung eines gemeinsamen Verständnisses über das Warum, Was und Wie unter allen Teammitgliedern verringern. Eine Überlastung wird das einzelne Teammitglied in eine immer weniger kooperative Haltung drängen und den Grad an Selbstorganisation vermindern. Auf der anderen Seite wird Slack Time dem Scrum-Team erlauben, gemeinschaftlich zu handeln und sich auf das Ergebnis, das Inkrement und dessen Wert für die Kunden zu konzentrieren.
- Zu detaillierte Planung: Während des Sprint-Planung planen die Entwickler jede einzelne Aufgabe des bevorstehenden Sprints im Voraus. (Man plane nicht zu kleinteilig. Es reicht, wenn etwa ein Viertel der Aufgaben zu Beginn geplant wird, um nicht nur mit dem Sprint zu beginnen, sondern auch den Lernprozess einzuleiten. Das Sprint Backlog ist immer im Entstehen begriffen, und zu viel Planung im Vorfeld könnte zu Verschwendung führen, wenn diese im Laufe des Sprints wieder korrigiert werden muss).
- Zu viele Schätzungen: Die Entwickler schätzt selbst die Teilaufgaben. (Das sieht für mich nach Buchhaltung um der Buchhaltung willen aus. Verschwenden Sie also nicht Ihre Zeit damit. Denken Sie daran: Der Zweck der Schätzung besteht darin, eine abweichende Einschätzung der Entwickler in Bezug auf das Was und Wie der Einträge im Product oder Sprint Backlog zu ermitteln. Mehr erfahren: Schätzungen sind nützlich, lassen Sie einfach die Zahlen weg.)
- Zu wenig Planung: Die Entwickler lassen die Sprint-Planung ganz ausfallen. (Das Überspringen der Planung ist bedauerlich, denn es ist auch eine hervorragende Gelegenheit, darüber zu sprechen, wie das Wissen unter den Entwicklern besser verteilt werden kann, wie die Architektur künftig aussehen soll oder ob die Tools angemessen sind. Das Team könnte zum Beispiel auch darüber nachdenken, wer mit wem für welche Aufgabe zusammenarbeiten wird. Der Planungsteil der Entwickler eignet sich auch hervorragend, um zu überlegen, wie technische Schulden reduziert werden können, siehe oben).
- Teamleiter? Die Entwickler erstellen keinen gemeinsamen Plan, um ihre Prognose zu erfüllen. Stattdessen übernimmt ein „Teamleiter“ die Planungsarbeit und weist ggf. sogar einzelnen Teammitgliedern Aufgaben zu. (Ich weiß, dass älteren Entwicklern die Idee nicht gefällt, aber es gibt keinen „Teamleiter“ in einem Scrum-Team. Erfahren Sie mehr zum Thema: Why Engineers Despise Agile.)
Sprint Planning Anti-Patterns des Product Owners
- Wofür arbeiten wir? Der Product Owner kann das Geschäftsziel des bevorstehenden Sprints nicht mit der allgemeinen Produktvision bzw. dem Produktziel in Einklang bringen. (Ein ernstzunehmendes Geschäftsziel beantwortet die Frage „Wofür arbeiten wir?“ Bis zu einem gewissen Grad ist dies in Folge auch eine Verhandlung zwischen dem Product Owner und den Entwicklern. Das Geschäftsziel sollte daher fokussiert und messbar sein, da das Sprint-Ziel, welches auf dem Geschäftsziel basiert, und die Prognose der Entwickler Hand in Hand gehen.)
- Kein Geschäftsziel, kein Sprint-Ziel, nur eine Ticketliste: Der Product Owner schlägt Product Backlog-Einträge vor, die eher einer zufälligen Zusammenstellung von Aufgaben ähneln und daher auch keinen Bezug zueinander haben. Folglich erstellt das Scrum-Team kein Sprint-Ziel. (Wenn dies die normale Art und Weise ist, wie Sie Ihr Sprint Planning abzuschließen, dann haben Sie unter Umständen die Nützlichkeit von Scrum als Produktentwicklungs-Framework bereits überlebt. Je nach dem Reifegrad Ihres Produkts könnte sich Kanban als bessere Lösung erweisen. Andernfalls kann die Zufälligkeit einen schwachen Product Owner signalisieren, der zu sehr auf die Stakeholder hört, anstatt das Product Backlog aus Sicht der Nützlichkeit für die Kunden entsprechend zu bestücken und zu ordnen.)
- Unvollendete Geschäfte: Unvollendete Aufgaben aus dem letzten Sprint werden ohne Diskussion in den neuen Sprint übernommen. (Es kann gute Gründe dafür geben, z. B. weil sich der Wert einer Aufgabe nicht geändert hat. Es sollte jedoch kein Automatismus sein, denken Sie an den Sunk Cost-Trugschluss.)
- Änderungen in letzter Minute: Der Product Owner versucht, in letzter Minute unfertige Product Backlog-Einträge im Sprint unterzubringen. (Im Prinzip ist es das Vorrecht des Product Owners, solche Änderungen vorzunehmen, um sicherzustellen, dass die Entwickler zu jedem Zeitpunkt an den wertvollsten Aufgaben aus Kundenperspektive arbeitet. Wenn das Scrum-Team jedoch ansonsten regelmäßig Verfeinerungen des Product Backlogs durchführt, sollten solche Vorkommnisse eine seltene Ausnahme sein. Wenn diese häufiger vorkommen, deutet dies darauf hin, dass der Product Owner Hilfe bei der Erstellung des Product Backlogs und in der Teamkommunikation benötigt. Oder der Product Owner braucht Unterstützung im Umgang mit hartnäckigen Stakeholdern.)
- Output-Fokussierung: Der Product Owner drängt die Entwickler, mehr Aufgaben zu übernehmen, als sie realistischerweise bewältigen können. Wahrscheinlich beziehen sich Product Owner dabei auf frühere Teammetriken wie die Velocity, um ihren Wunsch zu unterstützen. (Dies ist auch ein sicherer Weg, um eine Feature Factory zu werden, und verdient die Aufmerksamkeit des Scrum Masters: Es ist eine Verletzung des Vorrechts der Entwickler, die Product Backlog-Einträge für das Sprint Backlog auszuwählen und missachtet Scrum-Werte).
- Fehlende Vorbereitung: Der Product Owner bereitet das Product Backlog für eine Auswahl nützlicher Product Backlog-Einträge durch die Entwickler nicht vor. (Das Product Backlog muss zu jedem Zeitpunkt die bestmögliche Nutzung der Arbeit der Entwickler aus der Perspektive des Kundennutzens darstellen. Mit anderen Worten, das Product Backlog Ihres Scrum-Teams muss rund um die Uhr „actionable“ sein. Nach meinen Maßstäben bedeutet dies, dass Sie jederzeit in der Lage sein müssen, ein sinnvolles Sprint Planning durchzuführen. Es reicht als Product Owner daher nicht aus, eine Stunde vor Beginn des Sprint Plannings kurz mal eben einige Product Backlog-Einträge vorzubereiten. Diese Qualität erreicht ein Produktbacklog nur durch regelmäßige Verfeinerung in Zusammenarbeit mit den Entwicklern.)
Sprint Planning Anti-Patterns des Scrum Teams
- Unregelmäßige Sprintlängen: Das Scrum-Team hat variable Sprintlängen. Beispielsweise werden Aufgaben nicht so dimensioniert, dass sie in die reguläre Sprintlänge passen. Stattdessen wird die Sprint-Länge an die Größe der Aufgaben oder an das jeweilige Sprint-Ziel angepasst. (Die Sprint-Länge ist nicht statisch, sondern variabel, um dem Scrum-Team ein optimales Gleichgewicht zwischen dem Verständnis der Kundenbedürfnisse durch häufige Lieferungen und ausreichender, ungestörter Zeit für sinnvolle Arbeit zu bieten. Wenn die Lernkurve steil ist, sind die Sprints kurz. Sobald das Scrum-Team besser mit der Materie vertraut ist, können die Sprints länger werden. Außerdem ist es z. B. durchaus üblich, die Sprintlänge am Ende des Jahres zu verlängern, wenn die meisten Teammitglieder in Urlaub sind. Die flexible Änderung der Sprintlänge nach „Bedarf“ ist jedoch ein typisches Fehlverhalten. Anstatt die Länge des Sprints zu ändern, um dem Sprint-Ziel gerecht zu werden, sollte das Scrum-Team mehr Aufwand in die richtige Dimensionierung der Product Backlog-Einträge investieren.)
- Zuviel des Guten: Das Scrum-Team übernimmt regelmäßig viel zu viele Aufgaben und verschiebt unvollendete Arbeiten direkt in den nächsten Sprint. (Wenn zwei oder drei Aufgaben in den nächsten Sprint verschoben werden, während die Entwickler dennoch das Sprint-Ziel erreichen, dann ist das prinzipiell in Ordnung. Wenn regelmäßig 30 bis 40 Prozent der ursprünglich geplanten Arbeiten während des Sprints nicht erfüllt werden, hat das Scrum-Team möglicherweise eine Art „zeitgesteuertes Kanban“ eingeführt. Vielleicht ist dies der richtige Moment, das Scrum-Team zu fragen, ob Kanban ggf. eine Alternative sein könnte. Wenn das Team Scrum immer noch als seine Wahl betrachtet, würde ich empfehlen, mehr Energie in die Verfeinerung des Product Backlogs zu stecken und sinnvolle Sprint-Ziele zu schaffen.)
- Stage-Gate® durch eine „Definition of Ready“: Das Scrum-Team beschließt, dass eine „Definition of Ready“ vorteilhaft ist, geht aber dogmatisch mit dieser um und schafft so einen Stage-Gate®-ähnlichen Genehmigungsprozess. (Das ist ein interessantes Thema für eine Diskussion unter den Teammitgliedern. Sollte zum Beispiel eine wertvolle User Story auf einen späteren Sprint verschoben werden, nur weil die Frontend-Designs erst in zwei Arbeitstagen verfügbar sind? Mein Vorschlag: Lassen Sie das Team entscheiden. Wenn das Team mit den Umständen einverstanden ist und den entsprechenden Product Backlog-Eintrag in den Sprint übernimmt, ist das in Ordnung. Wenn jedoch die „Definition of Ready“ wie eine Checkliste verwendet wird, aufgrund derer alles abgelehnt wird, was nicht zu 100 Prozent durch sie abgedeckt ist, dann führt man die Wasserfallmethode durch die Hintertür wieder ein, nur dass es diesmal die Entwickler sind, die dies tun. Erfahren Sie mehr: The Dangers of a Definition of Ready.)
- Kein Standard für die Einstufung von Product Backlog-Elementen als ‚fertig‘: Das Scrum-Team hat kein gemeinsames Verständnis davon, was ein „sprintfertiges“ Product-Backlog-Element erfordert. (Dies ist die Kehrseite der dogmatischen Anwendung einer „Definition of Ready“. Die Entwickler wählen nun also ungeeignete Arbeitsaufgaben in den Sprint aus, die unnötige Störungen während des Sprints verursachen und möglicherweise sogar das Erreichen des Sprint-Ziels gefährden können. Laissez-faire hilft hier ebenfalls nicht.)
- Prognose seitens Dritter: Die Sprintprognose über die vermutlich bewältigbare Arbeit ist keine teambasierte Entscheidung. Oder sie ist nicht frei von äußeren Einflüssen. (Es gibt hier mehrere Anti-Patterns. Zum Beispiel dominiert ein durchsetzungsstarker Product Owner die Entwickler, indem er den Umfang der Prognose definiert. Oder ein Interessenvertreter weist auf die frühere Velocity des Teams hin und fordert, mehr Aufgaben in den Sprint zu übernehmen — „Wir müssen die verfügbare Kapazität auslasten“ — oder der ‚technische Leiter‘ unter den Entwicklern erstellt eine Prognose im Namen aller Entwickler.)
- Ignorieren des Sprint Plannings: Das Entwicklungsteam nimmt nicht gemeinsam an der Sprintplanung teil. Stattdessen vertreten zwei Teammitglieder, zum Beispiel der „Technische Leiter“ und der „UX-Leiter“, das Team. (Was die Idee von einem oder zwei „führenden“ Teammitgliedern in einem Scrum-Team betrifft, so gibt es keine, siehe oben. Und wenn Sie nicht Nexus oder LeSS verwenden, wo die verschiedenen Scrum Teams im übergeordneten Sprint Planning durch einzelne Teammitglieder vertreten sind, dann muss das gesamte Scrum-Team am Sprint Planning teilnehmen. Dieses ist eine Teamleistung, und daher muss die Stimme jedes Einzelnen gehört werden. Andernfalls leidet die Transparenz und es könnten fehlerhafte Entscheidungen getroffen werden, was die Wertschöpfung verringert und das Risiko der Erreichung des Sprint-Ziels erhöht.)
Sprint Planning Anti-Patterns des Scrum Masters
Der Product Owner ist verantwortlich für das Geschäftsziel des bevorstehenden Sprints und damit für die Bereitstellung eines entsprechend vorbereiteten Product Backlogs. Gleichzeitig sind die Entwickler für die Auswahl der notwendigen Product Backlog-Einträge verantwortlich, um das gemeinsam erarbeitete Sprint-Ziel zu erreichen. Was sind also die Sprint Planning Anti-Patterns des Scrum Masters, werden Sie sich fragen?
Abgesehen davon, dass Scrum Master an den oben skizzierten Sprint Planning Anti-Patterns mitschuldig sind, weil sie sich nicht mit ihnen befassen, fällt mir ein Fehlverhalten ein, das direkt in die Verantwortung des Scrum Masters fällt. Trotz der Änderungen am Scrum Guide im Jahr 2020 ist die Beschäftigung mit einem wichtigen Verbesserungspunkt aus der vorherigen Sprint-Retrospektive in jedem Sprint immer noch ein wichtiger Schritt, der dem Scrum-Team hilft, sich kontinuierlich zu verbessern. Wenn Scrum Master das Scrum-Team in dieser Angelegenheit nicht unterstützen, stellt dies in meinen Augen ein Fehlverhalten des Scrum Masters in der Sprintplanung dar.
Schlussfolgerung
Das Sprint Planning ist ein zentrales Scrum-Ereignis, das definiert, wie sich das Leben Ihrer Kunden mit dem nächsten Produkt-Inkrement verbessern wird und folglich nicht auf die leichte Schulter genommen werden sollte. Glücklicherweise sind die meisten der oben genannten Sprint Planning Anti-Patterns einfach zu vermeiden. Machen Sie das Sprint Planning zur Teamsache, respektieren Sie die Scrum-Werte, Selbstorganisation und die Scrum-eigenen Checks & Balances.
Welche Sprint Planning Anti-Patterns haben Sie beobachtet? Bitte teilen Sie uns dies in den Kommentaren mit.
Weitere Artikel
Liberating Structures for Scrum (2): The Sprint Planning
Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team
21 Sprint Retrospektive Anti-Patterns
27 Product Backlog Anti-Patterns
Alle Artikel über Scrum Anti-Patterns
Download the Scrum Anti-Patterns Guide for free
📺 Das Webinars Sprint Planning Anti-Patterns
Das Video des Webinars „Sprint Planning Anti-Patterns“ ist auf Youtube verfügbar:
Anmerkung: Wenn der Browser das Video nicht automatisch startet, klicken Sie hier, um das Video Sprint Planning Anti-Patterns direkt auf Youtube anzusehen.
✋ Nicht versäumen: Werden Sie Mitglied im 11.000-köpfigen „Hands-on Agile“ Slack Team und lernen Sie mehr über Sprint Planning Anti-Patterns
Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.
Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.
Der Artikel Wenn die Sprint-Planung schief geht: 20 vermeidbare Fehler erschien zunächst auf Berlin-Product-People.com.