Sofern nach SCRUM gearbeitet wird, wird alle zwei Wochen ein neuer Sprint geplant. Dieser kurze Plannungszyklus soll die Qualität der Planung ersetzen. Tools, wie MS Projekt sind vermeintlich out und bringen der Planung gar nichts. Dabei wird eine Sache gerne übersehen: Im klassischen Wasserfallmodell wurden die Planungen häufig stundenbasiert berechnet und man wusste, dass man am 01.04. um 13:37 live gehen konnte. Natürlich ist jeden bewusst, dass diese Schätzung so nicht eintreten wird.
Trotzdem benötigen die Stakeholder einen ungefähren Zeitplan und ein klares Ziel, wann eine Software zu erwarten ist. In der Praxis gibt es nun zwei Varianten: Die langfristige Schätzung wird nicht gemacht oder die Schätzung wird von jemanden anderes gemacht. In beiden Varianten gibt es häufig für das Projektteam unangenehme Überraschungen, wenn die Deadline nah ist oder bereits überschritten ist. Daher ist es gut und wichtig diese Informationen und Planungen proaktiv zu kommunizieren und transparent zu aktualisieren.
Eine Aktualisierung sollte nach jedem Sprintplanning erfolgen. Der vergangene Sprint ist abgeschlossen und durch neue Informationen wissen wir, ob wir noch im Plan sind oder wie der Plan nach vorne oder nach hinten verschoben werden kann. Eine kleine Verschiebung nach hinten kann zwar aufgeholt werden, aber auch hier ist frühe Kommunikation wichtig, wo man steht. Sofern die Kommunikation nach außen kritisch ist, sollte aber zumindest das Projektteam dieses wissen. Um herauszufinden, ob man im Plan ist, ist es am einfachsten einfach alle Todos auf einen Zeitstrahl zu legen und sofern es dort Abweichungen gibt, ist man nicht mehr im Zeitplan. Dabei ist es auch weiterhin sehr agil möglich Funktionalitäten neu hinzuzunehmen oder zu entfernen. Aber nur mit dieser visuellen Darstellung ist es möglich, dies klar zu erkennen und mit Optionen zu diskutieren. Feature A hinzunehmen bei Thema B, dafür wird aber Thema C um x Wochen später fertig.
Im Sprintplanning ist es hier wichtig gut und realistisch zu planen. Eine sehr gute Vorgehensweise ist es mit einem leeren Sprint anzufangen und Stories nach und nach hinzuzufügen. Sofern das Team das Gefühl hat, das der Sprint zu voll ist, wird das Hinzufügen gestoppt. Dabei helfen kann ein Bauchgefühl, eine gemessene Velocity oder aber auch eine visuelle Verteilung auf Mitarbeiter. Gerade die visuelle Verteilung sieht man viel zu selten. Im klassischen Projektmanagement gab es Begriffe wie kritischer Pfad, welche besonders behandelt wurden. Dieses Handwerk wird häufig vergessen, auch wenn dieser Pfad trotzdem vorhanden ist.
Es gibt unterschiedliche Herangehensweisen an einem Planning, welche auch je nach Projektstatus variieren kann. Möchte ich pessimistisch planen, sodass alle Ziele auf jeden Fall erreicht werden können und man genaue Zahlen hat, oder möchte man optimistisch planen, um einen gewissen Projektverzug wieder ausgleichen zu können? Beide Varianten sind valide. Wichtig ist jedoch, dass es dem Projektteam klar ist, welche Strategie aktuell gefahren wird. Im Bestfall kann dies das Team selbst einschätzen, häufig sollte dies aber ein Call vom product owner sein.
Nun kann es immer sein, dass man in einen crunch mode gelangt ist und eine freie Planung nicht möglich ist und der product owner mit einem vorgefertigten Sprint ins Planning geht. Dies kann und sollte vom Team nur abgenickt werden. Dieser Modus ist definitv valide, auch wenn der Zeitraum begrenzt sein muss. In dieser Phase sollte man sich aber fragen, ob dieses Meeting wirklich nötig ist. Ein guter Indikator ist, dass das Projektteam dieses Meeting als Zeitverschwendung ansieht. In diesem Fall sollte das Meeting mit einem definierten Zeitpunkt pausiert werden. An diesem definierten Zeitpunkt sollte man wieder ruhigeres Fahrwasser erreicht haben. Wichtig ist, aber das Forecasting weiterhin transparent zu aktualisieren, damit man immer weiß, wo man im Projekt ist.
Häufig wird das Forecasting basierend auf einer Velocity gemessen. Dafür wären Schätzungen nötig, welche in diesem Zeitraum auch als Zeitverschwendung angesehen werden. Eine gute Übung ist es einfach Stories oder Epics zu zählen. Da Schätzungen sehr selten korrekt sind, kann man auch davon ausgehen das Epics oder Stories im Durchschnitt gleich groß sind. Gute Erfahrungen, hat Biga damit gemacht alles mit eins zu belegen, um dann ein gutes Ergebnis am Ende zu prognostizieren.
Mit diesen kleinen Änderungen kann ein Planning nicht nur für die nächsten zwei Wochen relevant sein, sondern so kann auch das große und Ganze gut im Blick gehalten werden. Die Planungen werden besser und realistischer, sodass das Projektteam mehr Interesse daran hat die Sprintziele zu erreichen. Damit sollte es keine bösen Überraschungen geben und das Softwareprojekt wird kein Reinfall, sondern ein großer Erfolg.
