Während im Sprint-Planning 1 das WAS im Vordergrund stand, steht im Sprint-Planning 2 (SP2) das WIE im Vordergrund. Allerdings gibt es dabei unterschiedliche Auffassungen, was das WIE beinhaltet.

Dabei ist die erste Gruppe der Meinung, man müsse so viel wie Möglich planen und als Tasks definieren. Eine spätere Identifizierung von weiteren Tasks stellt dabei schon fast ein Vergehen dar, man hätte das ja beim SP2 schon sehen müssen! – Meine Meinung dazu: Wasserfall! Hier steckt das Wasserfallmodell noch sehr stark in den Köpfen, man ist der Meinung, dass man zu Beginn des Sprints alles schon haargenau planen muss. An dieser Stelle sollte der ScrumMaster einschreiten und erklären, dass dies immer vorkommen kann und auch notwendig ist, um auf kurzfristige Änderungen reagieren zu können. Ferner ist es durcaus möglich, dass man den Tasks zu umfangreich gefasst hat und man ihn aufteilen muss.

Die zweite Gruppe verbringt das SP2 mit Architektur und Design, plant die Userstory in Bezug auf Architektur und Design bis ins Letzte und schreibt rudimentäre Tasks für den ersten Entwicklungstag. Hier fängt man meiner Meinung nach an, Wasserfall und Scrum zu kombinieren – eine Planung von Architektur und Design gemäß Wasserfall, Umsetzung gemäß Scrum. Allerdings fehlt mir dabei die Transparenz. Die Tasks am Scrumboard spiegeln nicht ansatzweise die noch zu erledigenden Aufgaben dar. Bei konsequenter Anwendung und sequenzieller Abarbeitung der Userstories würden hier gegebenenfalls nur ein paar Tasks für die erste Userstory hängen – das ist nicht transparent! Idealerweise sollte das Team auf die mangelnde Transparenz hingewiesen werden und die noch fehlenden Tasks schnellstmöglich identifizieren.

Die dritte Gruppe entwirft im SP2 einen Lösungsansatz (Architektur- und Design-Ansatz) und identifiziert die zur Umsetzung nötigen Tasks. An den Stellen, an denen Unsicherheit herrscht, werden Analyse-Tasks eingefügt, deren Resultate dann im Folgenden zu weiteren Tasks führen können. Meiner Meinung nach der agilste Ansatz, da hier iterativ die Umsetzung er- und überarbeitet wird.

Dabei ist es natürlich von vielen Faktoren abhängig, wie detailliert ein solcher Design- oder Architektur-Ansatz sein sollte, das SP2 sollte jedoch nicht in eines der Extreme verfallen.