Sprint Planning Ablaufplan erklärt
Die Checkliste für das Sprint Planning besteht aus folgenden Komponenten: Ziel, Häufigkeit, Teilnehmer, Vorbereitung, Aktivitäten während des Meetings und Ergebnis des Meetings. Die Checkliste ist selbsterklärend und wird in diesem Abschnitt nicht näher beschrieben.
Wie wende ich die Checkliste an?
Im Allgemeinen können Sie die Checkliste auf zwei Arten anwenden. Als Scrum Master verwenden Sie die Liste in erster Linie, um sicherzustellen, dass jeder die Aufgaben und Verantwortlichkeiten ausführt, die zu seiner Rolle gehören. Besonders Scrum Master-Neulinge finden dies sehr nützlich.
Einige Teams haben diese Checkliste auch ausgedruckt und im Scrum-Raum ausgehängt. Auf diese Weise weiß das gesamte Team, was für ein gutes Sprint Planning vorbereitet werden muss, wie die Besprechung ablaufen sollte und was das Ergebnis der Besprechung sein sollte.
Die Checkliste kann auch während der Retrospektive als Hilfsmittel verwendet werden. Lassen Sie jedes Teammitglied eine Punktzahl für jeden Punkt der Checkliste vergeben. Besprechen Sie dann, was gut läuft und was verbessert werden kann. Vereinbaren Sie auch, wer für die Umsetzung der Verbesserungsmaßnahmen auf kurzem Wege verantwortlich ist.
Das Sprint Planning ist vielleicht die größte Herausforderung für Scrum Teams. Für ein erfolgreiches Sprint Planning muss jeder seine Rolle spielen. Ein gutes Sprint Planning ist daher eine echte Teamleistung. Die folgende Übersicht zeigt die häufigsten Fallstricke für Scrum Teams bei dem Sprint Planning.
- Nicht alle sind anwesend: Vor allem in Scrum Teams die noch am Anfang stehen, kann es eine Herausforderung sein, alle an einen Tisch zu bekommen, während das Team im Sprint Planning die Arbeit für den kommenden Sprint festlegt und ausarbeitet. Es ist die perfekte Gelegenheit, dem Product Owner Fragen zu den User Stories zu stellen. Die Abwesenden verpassen diese Gelegenheit und haben in der Regel ein unvollständiges Verständnis davon, was das Team im Sprint leistet. Im Sprint Planning arbeitet das Entwicklungsteam die User Stories in kleineren Aufgaben aus. Ein abwesendes Teammitglied verfügt vielleicht gerade über das für diese Ausarbeitung erforderliche Fachwissen, sodass das gesamte Team nicht weiterkommt. Abwesenheit bei Scrum-Meetings ist eine der größten Sünden überhaupt, aber leider kommt sie häufig vor.
- User Stories sind nicht wirklich fertig: Für die meisten Product Owner ist es einfach, grob anzugeben, was das Entwicklungsteam liefern soll. Die Herausforderung liegt jedoch in der richtigen Ausarbeitung einer User Story. Denken Sie zum Beispiel an klare Akzeptanzkriterien. Um sicherzustellen, dass dies reibungslos abläuft, erstellen viele Scrum Teams eine „Definition of Done“. Hier werden die Anforderungen aufgeführt, die eine User Story erfüllen muss, bevor das Entwicklungsteam die Arbeit aufnimmt.
- Mehr Arbeit auswählen als realistisch ist: Es liegt in der Natur der Sache, dass der Arbeitsaufwand für komplexe Aufgaben unterschätzt wird. Unsere natürliche Tendenz besteht daher darin, mehr User Stories auszuwählen und in das Sprint Backlog aufzunehmen, als wir bewältigen können. Als Scrum Master können Sie das Team davor warnen, aber noch effektiver ist es, wenn Sie das Team einmal einen Fehler machen lassen. Nutzen Sie die Geschwindigkeit des Scrum Teams, um zu bestimmen, was ein realistisches Arbeitspensum im Sprint Planning ist. Es ist besser, etwas weniger Arbeit auszuwählen, die gut und pünktlich erledigt wird, als zu viel auszuwählen und am Ende des Sprints nichts zu haben.
- Der Product Owner entlastet: Als Ansprechpartner für alle Stakeholder hat der Product Owner eine wichtige Pufferfunktion. Der Product Owner muss sicherstellen, dass sich das Team auf die Aufgaben im Sprint Backlog konzentrieren kann und die Stakeholder vom Entwicklungsteam fernhält. Dies ist jedoch nicht immer der Fall. Wenn Stakeholder Druck auf den Product Owner ausüben, neigen manche Product Owner dazu, diesen Druck an das Entwicklungsteam weiterzugeben. In diesem Fall wird der Product Owner während des Sprint Planning anordnen, dass das Team mehr Arbeit in das Sprint Backlog aufnehmen muss. Der Scrum Master muss sich davor hüten und den Product Owner zur Rechenschaft ziehen, wenn es dazu kommt.
- Nur individuelle Arbeit im Sprint einplanen: Bei Scrum geht es darum, zusammenzuarbeiten und gemeinsam mehr zu erreichen als jedes Teammitglied einzeln. Scrum Teams neigen jedoch oft dazu, die User Stories so weit wie möglich aufzuteilen, sodass nur eine minimale Zusammenarbeit erforderlich ist. Dies kommt letztlich der Qualität nicht zugute.
- Ungleiche Arbeitsverteilung: In jeder Organisation gibt es einige unentbehrliche Mitarbeiter mit außergewöhnlichem Fachwissen. Das kann dazu führen, dass jemand mit außergewöhnlichen Fachkenntnissen eine Menge Arbeit übernimmt, denn schließlich kann die Person mit den meisten Fachkenntnissen die Arbeit am besten erledigen. Wenn Sie kurzfristig denken, ist das richtig, aber langfristig bleiben Sie von dieser Person abhängig. Es ist also viel besser, daran zu arbeiten, wie diese Person ihr Fachwissen an die anderen Teammitglieder weitergeben kann. Die Gesamtproduktivität eines Teams steigt, wenn mehr Personen die Arbeit der knappsten Ressource übernehmen können. Dies ist ein gutes Argument für T-shaped Mitarbeiter.
- Länger als die Timebox: In Scrum ist die Dauer eines Meetings festgelegt, und das aus gutem Grund. Das Sprint Planning ist die Besprechung, die am häufigsten zu spät kommt. Dies kann verschiedene Ursachen haben. User Stories werden in der Regel nicht detailliert genug ausgearbeitet, was dazu führt, dass das Entwicklungsteam eine Menge Fragen darüber stellt, was sie liefern müssen. Es kann auch zu Meinungsverschiedenheiten über die Prioritäten kommen, sodass sich die Sitzung verzögert. Es ist dann wichtig, dass das Entwicklungsteam die Priorisierung des Product Owners akzeptiert.
