Die meisten Sprint-Planning-Checklisten sind Listen der mechanischen Schritte des Events (Ziel setzen, Elemente auswählen, Kapazität schätzen), was den Scrum Guide wiederholt, statt etwas Nützliches hinzuzufügen. Eine nützlichere Checkliste fängt die konkreten Dinge ab, die selbst dann schiefgehen, wenn die mechanischen Schritte korrekt befolgt werden.

Vor dem Meeting:

  • Wurde der Product Backlog tatsächlich kürzlich verfeinert, oder plant das Team gleich gegen veraltete, unterspezifizierte Elemente? Planung gegen unverfeinerte Elemente ist die Quelle eines Großteils der Überraschungen mitten im Sprint.
  • Hat die Product-Owner-Person ein echtes Gespür für die Priorität dieses Sprints, oder ist die Backlog-Reihenfolge selbst unklar oder umstritten? Planung sollte nicht der erste Moment sein, in dem Priorität diskutiert wird.
  • Ist die tatsächliche verfügbare Kapazität des Teams bekannt (unter Berücksichtigung geplanter Abwesenheit, bekannter Unterbrechungen oder unfertiger Übertragsarbeit), statt volle nominelle Kapazität anzunehmen?

Während des Meetings:

  • Wird das Sprint Goal vereinbart, bevor die Elementliste feststeht, oder wird es danach als Zusammenfassung dessen geschrieben, was bereits ausgewählt wurde? Das Ziel sollte die Auswahl prägen, nicht sie im Nachhinein beschreiben.
  • Hat für jedes aufgenommene Element jede Person im Raum dasselbe Verständnis davon, was "fertig" dafür bedeutet, oder wird diese Annahme nie laut geprüft?
  • Hat jemand gefragt, was bei den unsichereren Elementen realistisch schiefgehen könnte, oder baut der Plan ausschließlich auf dem optimistischen Fall auf?
  • Gibt es eine echte Diskussion darüber, wie die komplexeren Elemente angegangen werden, oder endet das Meeting, sobald das Was feststeht, und der technische Ansatz wird mitten im Sprint geklärt?

Vor Ende des Meetings:

  • Kann jedes Teammitglied das Sprint Goal in eigenen Worten formulieren? Wenn nicht, ist es nicht wirklich angekommen, egal was auf dem Board steht.
  • Gibt es ein geteiltes Verständnis davon, was diesen Sprint zu einem echten Erfolg machen würde, gegenüber einem technischen Durchgang (formal alles geliefert, das Ziel aber nicht wirklich erreicht)?
  • Wurde etwas still angenommen statt explizit besprochen (eine Abhängigkeit von einem anderen Team, eine Umgebung, die verfügbar sein muss, Information, die von einer Stakeholder-Person erwartet wird), das den Sprint still gefährden könnte, falls es nicht eintritt?

Der Wert einer solchen Checkliste liegt nicht darin, jeden Punkt jeden einzelnen Sprint abzuhaken: Manche Punkte passen nicht, und die gesamte Liste durch eine unkomplizierte Planungssitzung zu erzwingen, fügt Reibung ohne Nutzen hinzu. Er liegt darin, sie verfügbar zu haben, um die konkreten Fehlermuster abzufangen, vor denen ein rein mechanisches Durchgehen der Standardschritte nicht schützt.