Sprint Planungssitzung

In der Sprint Planungssitzung stellt das Team ein realistisches Sprint Backlog, das alle Anforderungen enthält, die bis zum Ende des Sprint umgesetzt werden.

Die Aufgaben in dieser Sitzung sind wie folgt verteilt:

  • Product Owner plant und stellt das Sprint-Ziel und eine Vorauswahl der umzusetzenden Anforderungen vor
  • Team identifiziert die für die Anforderungen notwendigen Aufgaben und ihren Aufwand und legt fest, welche Anforderungen im nächsten Sprint umgesetzt werden
  • Scrum Master moderiert die Sitzung und wahrt die Selbstorganisation des Teams

Der Termin ist für alle Teilnehmer verpflichtend. Für die Sitzung stehen zwei Vorgehen zu Verfügung: Klassisch und Iterativ.

In [Scrum – Agiles Projektmanagement erfolgreich einsetzen; Pichler, Roman; dpunkt.verlag 2008] wird das iterative Vorgehen empfohlen, welches hier beschrieben wird:

  • Product Owner und Team verständigen sich auf das Sprint Ziel (hier ist wichtig, dass jeder das Ziel verstanden hat, um ein fokussiertes Arbeiten zu ermöglichen)
  • Team iteriert durch die vorbereiteten Anforderungen beginnend mit der höchstprioren und schätzt die Aktivitäten und ihren Aufwand
  • Verfügt das Team über das nötige Wissen für die Anforderung, dann wird sich in das Sprint Backlog aufgenommen (wichtig ist hier festzulegen, wie die Erreichung der Anforderung überprüft werden kann)

Vorbereitung durch den Product Owner:

  • Sprint Ziel vor-formulieren
  • Mögliche Anforderungen für den nächsten Sprint auswählen
Sprint Planungssitzung
Sprint Planungssitzung

Ende der Sprint Planungssitzung

  • Anberaumte Zeit ist mit Aktivitäten ausgefüllt
  • Realistisches Sprint Ziel vereinbart
  • Realistisches Sprint Backlog zu dem sich das Team verpflichtet hat bestehend aus (Anforderungen und ihren mit Aufwand abgeschätzten Aktivitäten)
  • Zusammenfassung der Ergebnisse – evtl. Verbesserungsvorschläge in die nächste Sitzung aufnehmen

Ermitteln der Aktivitäten

Aktivitäten für die Erfüllung einer Anforderung enthalten typischerweise:

  • Designaufgaben
  • Implementierungsaufgaben
  • Testaufgaben
  • Dokumentationsaufgaben

Weiterhin sollte geklärt sein, ob im Team paarweise gearbeitet wird, Codereviews durchgeführt werden oder spezielle Integrationstests notwendig sind.

Das Team entscheidet selbst, welche Aufgaben es wann im Sprint durchführt. Dies wird nicht in der Sprint Planungssitzung festgelegt. Auch die Festlegung wer die Aufgabe übernimmt trifft das Team selbstständig. Hierbei gilt stets: Aktivitäten der höchstprioren Anforderung werden als erstes angepackt.

Typische Fehler

Teams brauchen oft ein wenig Zeit, um den Planungsprozess effektiv anwenden zu können (2-3 Sprint Planungssitzungen). Hierbei soll der Scrum Master unterstützen, indem er die Vorgehensweise erklärt, ohne die Selbstorganisation des Teams zu gefährden.

  • Der Scrum Master plant
    • Für Teams ist es ungewohnt Projektmanagementaufgaben zu übernehmen und sich der Verantwortung zu stellen
    • Manche Scrum Master führen zu viele Planungsaktivitäten aus und planen für das Team. Es soll aber selbstorganisierend lernen Verantwortung zu übernehmen
  • Ein Teammitglied dominiert
    • Manche Teammitglieder übernehmen die fehlenden Projektmanagerrolle, hier muss entsprechend gegengesteuert werden und auch stillere Mitglieder müssen beachtet und gefördert werden
  • Zu viel Designdiskussionen
    • Es kann vorkommen, dass Anforderungsbesprechungen zu einem „Designworkschop“ ausarten. Hier liegt dann oft Explorationsbedarf vor – wie setze ich die Anforderung um. Dies kann dann als Aufgabe formuliert werden und die Planungssitzung kann weiter gehen. Hierauf muss der Scrum Master achten.
  • Teammitglieder wählen Aktivitäten in der Planungssitzung aus
    • Dies wird durch eine ungleiche Wissensverteilung ausgelöst und das Team kann keine gemeinsame Verantwortung übernehmen. Hier könnten paarweise Arbeiten oder Weiterbildungen Abhilfe schaffen
  • Product Owner identifiziert Aktivitäten
    • Hier muss der Scrum Master auf die Spielregeln von Scrum achten. Das Team selbst identifiziert die Aktivitäten (außer der Project Owner übernimmt selbst Aktivitäten)
  • Product Owner nimmt nicht an der Planungssitzung teil
    • Kann der Project Owner nicht an der Sitzung teilnehmen sollte sie verschoben werden.
  • Aktivitäten zu vage oder zu groß
    • Der Scum Master sollte helfen zu große und vage Aktivitäten zu identifizieren und darauf hinzuweisen. Aktivitäten sollten nicht länger als ein Netto-Tag sein
  • Sprint Planungssitzung nicht adäquat vorbereitet
    • Schlecht vorbereitete Sitzungen demotivieren das Team, es ist nicht gewillt seine Zeit in anstrengenden Sitzungen zu verbringen
Veröffentlicht in SCRUM

Schreibe einen Kommentar