Was ist das Sprint Planning? 

Das Sprint Planning ist wichtiger Bestandteil jedes Sprints nach Scrum. Im Sprint Planning wird der jeweils nächste Sprint in einem sehr hohen Detailgrad geplant.

Das Entwicklungsteam bespricht gemeinsam mit dem Product Owner, was in diesem Sprint im Sinne der „Definition of Done“ umzusetzen ist.

Das Sprint Planning ist für einen einmonatigen Sprint auf maximal 8 Stunden befristet. Bei kürzeren Sprints wendet man normalerweise weniger Zeit auf - im Schnitt 4 Stunden. Der Scrum Master sorgt dafür, dass das Ereignis stattfindet und die Teilnehmer dessen Zweck verstehen. 

Das Sprint Planning beantwortet die folgenden Fragen: 

•  Was ist in dem Produktinkrement des kommenden Sprints enthalten? 
•  Wie wird die für die Lieferung des Produktinkrements erforderliche Arbeit erledigt? 
  

Wer nimmt am Sprint Planning teil?

• Entwicklungsteam
• Product Owner 
• Scrum Master
  

Wie läuft das Sprint Planning ab? 

Der Product Owner stellt das Geschäftsziel vor, das im bevorstehende Sprint erreichen soll. Das Scrum-Team erstellt dann gemeinsam ein Sprint-Ziel und das Entwicklerinnen-Team wählt die entsprechenden Einträge aus dem Product Backlog, die zur Erreichung des Sprint-Ziels beitragen, in dem es diese in den Sprint Backlog überträgt.

Zunächst wird festgelegt, welche Anforderungen in diesem Sprint umgesetzt werden können, also wie das Software Inkrement aussehen soll. Dazu müssen die am höchsten priorisierten Elemente des Product Backlogs einen relativ hohen Detailgrad aufweisen und von allen Parteien nicht nur gut verstanden werden, sondern auch klar und frei von Interpretationsspielraum sein.

Diesen Zustand eines einzelnen Elements des Product Backlogs nennen wir „Ready for Sprint“ (kurz „Ready“).

Dazu wählen sie gemeinsam entlang der Priorisierung aus, welche Elemente in den Sprintplan aufgenommen werden. Das Team plant zunächst „was“ umzusetzen ist sowie welches Ziel mit dem Sprint erreicht werden soll. Dann im zweiten Schritt, „wie“ das Ziel umgesetzt werden soll.

Über die Anzahl der umzusetzenden Items entscheidet ausschließlich das Umsetzungsteam in Scrum - es entsteht das Sprint Ziel.  Im Anschluss wird vom Entwicklungsteam ein Plan zur Erreichung des Sprint Ziels erstellt. Dazu werden die dafür nötigen Schritte diskutiert und dokumentiert - in der Regel auf einem physischen Taskboard. Am Ende des Meetings entsteht so ein detaillierter Plan für den Sprint. 

‍

5 Punkte, die Sie beim Sprint Planning unbedingt beachten sollten!

‍

1. Unrealistische Kapazitätseinschätzung im Entwicklerinnen-Team

Was im Sprint umgesetzt werden kann, hängt wesentliche von der verfügbaren Kapazität des Entwicklerinnen-Teams ab. Häufig übernehmen die Entwicklerinnen zu viele Aufgaben im Sprint und beachten nicht ausreichend jene Aspekte, die ihre Kapazität für die Umsetzung im Sprint, wie beispielsweise Urlaub, Feiertage, Krankheit, Unterstützung anderer oder auch neuer Teammitglieder, Refactoring, Backlog Refinement und andere Meetings beeinträchtigen. 

Stellen Sie daher sicher, dass eine realistische Kapazitätsplanung erfolgt.

‍

2. Mangelndes Qualitätsbewusstsein bzw. das Ignorieren technischer Schulden

Wenn das Entwicklerinnen-Team dazu angehalten wird, sich ausschließlich auf die Entwicklung neuer Features zu konzentrieren und nicht ausreichend Kapazität verlangt, um die innere Qualität des Produktes durch laufenden Refactoring zu verbessern führt das zu Problemen. Häufig werden dann technische Schulden und Fehler, die während des Sprints auftreten, nicht zeitnahe beseitigt. 

Wenn die Notwendigkeit dieser Arbeiten von Product Ownern oder Stakeholdern nicht gesehen wird und sich das Entwicklerinnen-Team an der Stelle nicht durchsetzt, wird die Qualität und somit die Lebensfähigkeit des zu entwickelnden Produktes zunehmend leiden. Technische Excellenz bzw. die Entwicklung eines wertvollen Produktes, das den Geschäftswert für die Anwender maximiert, sind somit außer Reichweite.

Stellen Sie sicher, dass die Bereinigung technischer Schulden und die laufende Verbesserung der Codebasis auch durch beispielsweise Code Reviews oder Pair Programming Priorität genießt. Als Faustregel gilt, dass etwa 20 % der Kapazität in jedem Sprint eingesetzt werden soll um die Codebasis laufend zu verbessern.

‍

3. Zu viel oder zu wenig Planung

Während des Sprint-Planning planen die EntwicklerInnen jede einzelne Aufgabe des bevorstehenden Sprints im Detail voraus und schätzen selbst Teilaufgaben. Das ist natürlich nicht im Sinne einer agilen Umsetzung und einer Etablierung eines kontinuierlichen Lernprozesses. Eine zu kleinteilige Planung führt in der Regel zu einem unverhältnismäßigen Aufwand und somit zu Verschwendung, wenn diese im Laufe des Sprints wieder angepasst wird. Es reicht in der Regel aus, wenn seitens des Entwicklerinnen-Teams ca. ein Viertel der Aufgaben im Zuge des Sprint-Planning geplant werden, um mit der Umsetzung starten zu können.

Der Zweck des Sprint Planning ist es, dass das Entwicklerinnen-Team ausreichend gut versteht, was in Form von User Stories und deren Akzeptanzkriterien umzusetzen ist. Dies entspricht Teil 1 des Sprint Planning. Im Teil 2 des Sprint Plannings wird sich über die zu erledigenden Aufgaben zur Erreichung des Sprint-Ziels verständigt und die Aufgaben festgehalten. Eine Verteilung der Aufgaben erfolgt nicht. Die Teammitglieder nehmen sich jeweils eine neue Aufgabe während des Sprints, wann immer sie mit einer Aufgabe im Sinne der Definition of Done fertig sind.

Auch eine agile Schätzung von Teilaufgaben ist nicht zweckmäßig. Der Zweck der Schätzung ist vielmehr, eine etwaige abweichende Einschätzung der Entwicklerinnen in Bezug auf das Was und Wie der Einträge im Product oder Sprint Backlog zu ermitteln. Eine grobe Schätzung auf Ebene von User Storys (z. B.: via Story Points) ist völlig ausreichend.

Ein zu geringe Planung ist aber ebenso nicht zielführend. Das Weglassen des Sprint Planning Teil 2 nimmt dem EntwicklerInnen-Team die Möglichkeit einen gemeinsamen Entwurf (Architektur, Design) zu bestimmen, sich darüber zu verständigen, welche technischen Schulden abzubauen sind oder wer mit wem für welche Aufgabe z.B.: im Zuge einer Pair Programming Session zusammenarbeiten.

Achten Sie darauf, dass es genau so viel Planung gibt als es dem Ziel dient. Das Entwicklerinnen-Team soll gut verstehen, was umzusetzen ist und wie die Umsetzung erfolgen soll, um das Sprint-Ziel zu erreichen und ein werthaltiges Softwareinkrement zu liefern.

‍

4. Teamleiter, Stellvertreter oder sonstiges Rollen Wirrwarr

Scrum setzt darauf, die kollektive Intelligenz eines Teams zu nutzen. Die Rollen sind dabei klar verteilt und definiert. Der Product Owner verantwortet das Was der Umsetzung, das Entwicklungsteam das technische Wie im Rahmen der technologischen Rahmenbedingungen des jeweiligen Projektes bzw. des Unternehmens. Der Scrum Master unterstützt beim Umsetzen des Sprint Planning und räumt organisatorische Hindernisse aus dem Weg. Alle 3 Rollen arbeiten auf Augenhöhe und keiner ist der Team-Lead oder Vorgesetzte der anderen Rollen.

Auch innerhalb des EntwicklerInnen-Teams gibt es keinen Team-Lead, der etwaige Planungsarbeiten übernimmt oder einzelnen Teammitgliedern Aufgaben zuweist. 

Es gibt auch kein Stellvertretersystem, in dem beispielsweise nur bestimmt Personen aus dem EntwicklerInnen-Team am Sprint Planning teilnehmen. Das gesamt Scrum Team ist beim Sprint Planning anwesend und bringen sich aktiv ein. Andernfalls leidet die Transparenz, das Teamgefüge und es kommt möglicherweise zu “Übertragungsfehlern”.

Ausnahme: Sie arbeiten mit Skalierungs-Frameworks wie Nexus oder LeSS, wo die verschiedenen Scrum Teams in einem übergeordneten Sprint Planning durch einzelne Teammitglieder vertreten sind.

Selbstverständlich sind im Zuge der Umsetzung unternehmensweite, Vorgaben und Standards im Kontext Architektur, Design, Datenschutz, Informationssicherheit, etc. vom Scrum Team zu berücksichtigen. Die entsprechenden Rollen haben aber im Zuge der Scrum Umsetzung und damit auch beim Sprint Planning keine definierten Aufgaben. Gleichwohl sollen diese für etwaige Klärung von Fragen für das Scrum bzw. Entwicklerinnen-Team im Zuge der Umsetzung zeitnahe erreichbar sein. 

Achten Sie darauf, dass das EntwicklerInnen-Team autonom, ohne Team-Lead Rollen, arbeiten kann und dass es das Ziel verfolgt den Outcome für Anwender mit jedem gelieferten Softwareinkrement zu maximieren. 

‍

5. Prognosen von Dritten und der Sprint Backlog Bazar

Eines der am häufigsten auftretenden Anti-Pattern in der Praxis ist, dass das EntwicklerInnen-Team nicht als Expertenteam wahrgenommen wird, das autonom hinsichtlich des Wie der Umsetzung entscheidet. Man traut dem Team keine valide Prognose, was im Sprint umgesetzt werden kann, zu.

Die Sprint-Prognose über die vermutlich bewältigbare Arbeit ist ausschließlich eine teambasierte Entscheidung des EntwicklerInnen-Teams. Stattdessen ist in der Praxis stellenweise zu beobachten, dass Produkt Owner, Stakeholder oder auch anderen in Scrum nicht vorgesehen Rollen, Prognosen erstellen oder nach Prognose durch das Entwicklerinnen-Team ein “Da geht doch noch sicher mehr” Bazar startet. 

Das ist ein Verhalten, das in jedem Fall zu vermeiden ist, denn es führt zu einer Vielzahl von negativen Konsequenzen. Beispielsweise übernimmt EntwicklerInnen-Team nicht mehr die Verantwortung für die Erreichung des Sprint-Ziels, es entsteht Überlastung und Frustration des Teams bis hin zu Personalabwanderungen.

Vertrauen Sie darauf, dass das EntwickerInnen Team aus Experten besteht, die gute Entscheidungen hinsichtlich der Prognose, welche Aufgaben umsetzbar sind, treffen.

‍

‍

Wissen Sie was Ihre User wirklich wollen?

Mit User Story Mapping können Sie das in 4 einfachen Schritten herausfinden! 

‍