Der Mehrwert von einem Planungstool bei Scrum.
Bei der Entwicklung von Software ist Scrum nicht mehr weg zu denken. Es ist eine erfolgreiche Methode, die auf fundamental andere Weise Projekte organisiert. Die Methode unterscheidet sich maßgeblich von allen anderen traditionellen Methoden und Techniken bei dem Veranschlagen, Planen und Bericht erstatten von Projekten. Bietet ein Planungstool dann keinen Mehrwert bei Scrum Projekten? Das werden wir in diesem Blog näher betrachten.
Planung bei einem Scrum Projekt scheint überflüssig. Du planst nämlich einsatzbereite Personen (Vollzeit) zu Projekten ein. Außerdem werden alle Verantwortlichkeiten so wenig wie möglich dem Projektteam auferlegt und es wird nur ein Minimum an Messinstrumenten und berichten eingesetzt. Die Masse an Informationen wird ‘analog’ während Besprechungen (stand ups) ausgetauscht und auf physischen Tafeln mitgeschrieben.
Hat ein Planungstool dann etwa nichts zu bieten? Doch, sicherlich! Am Anfang eines Projektes wird schließlich immer eine Veranschlagung gemachte und ein Plan, wie auch bei Scrum. Außerdem kann ein Planungstool gerade auch helfen, bei einer integralen Kapazitätsplanung, die sich auf alle Projekte und Aktivitäten bezieht. Zu guter letzt kann ein Planungstool auch ausgezeichnet die Leistung messen und vergleichen mit anderen Projekten, um daraus zu lernen.
1. Scrum plant schon viel, aber anders
Das veranschlagen von User Stories
In Scrum werden User Stories in Story Points anstelle der Stundenzahl bemessen. In Scrum werden User Stories in Story Points anstelle der Stundenzahl bemessen. Die Basis eines Story Points ist allerdings noch immer die Stundenanzahl. Alle Benutzerstories werden im Vergleich zueinander eingestuft. Dies wird mit Hilfe der Technik von Planungs-Poker gemacht. Schlussendlich resultiert dies dann in eine große Ansammlung (Produkt Backlog) von User Stories, die alle einen Wert zugewiesen bekommen haben.
Das bestimmen des Turnaround auf der Basis von Sprints
Im nächsten Schritt werden dann Sprints geplant. Ein Sprint ist eine Periode einer bestimmten Anzahl an Wochen, zum Beispiel 3 Wochen. Die Länge eines Sprints und die Anzahl der Sprints wird stark davon abhängen, welchen Umfang die Benutzer Geschichten in User Points (Stunden) haben und von der verfügbaren Kapazität des Projektteams. Wenn die User Stories durchschnittlich viele Story Points umfassen, dann wird man schnellere und längere Sprints benötigen.
Das Zusammenstellen eines Teams (die Kapazität)
Ein Scrum Team besteht aus 5 bis 9 Mitarbeitern. Ein Scrum Team besteht aus 5 bis 9 Mitarbeitern. Man stellt das Team je nach Wissen und Fähigkeit zusammen, aber auch die notwendige Kapazität und die Deadline spielen eine Rolle. Steht die Deadline fest? Dann kannst man anhand der Basis der Anzahl der User Points genau die notwendigen Kapazitäten pro Woche/Sprint ausrechnen. Das bestimmt wie viele Mitarbeiter man in seinem Team braucht.
Wird nicht mehr mit einer festen Deadline für das Projekt gearbeitet? Dann bestimmt man die ideale Größe für das Team und damit wird die Deadline automatisch bestimmt, durch die Anzahl der Sprints, die das Projektteam benötigt, um die User Stories ab zu arbeiten.
2. Ressourcenplanung beleibt entscheidend
Einsatz planen mit Scrum ist einfach
Ressourcenplanung ist immer die Achillissehne der Projektplanung. Wenn das Projekt endlich bis ins Detail geplant ist, muss schon wieder etwas verschoben werden. Das kann schon seine Folgen haben, und andere Projekte setzen dann auch noch Ihre Mitarbeiter ein. Die Ressourcenplanung fällt dann wie ein Kartenhaus ineinander.
Was das betrifft, ist Scrum ein Segen, denn Scrum propagiert vollen Einsatz (Vollzeit) der Mitarbeiter des jeweiligen Projektteams. Das macht es ein Stück einfacher zu planen, da Sie die Mitarbeiter direkt für einige Monate für ein Projekt einsetzen können. Das gibt Ihnen Ruhe bei der Planung, und weniger Anpassungen. Dennoch sind zwei Punkte zu beachten: Arbeit für andere Projekte und andere Abwesenheiten.
Arbeit an anderen Projekten
Vollzeit Verfügbarkeit ist wünschenswert, aber nicht immer möglich. In der Praxis, kann es sein, dass ein Mitarbeiter nun einmal einen Tag in der Woche an einem (nicht-Scrum) Projekt arbeiten muss oder operative Tätigkeiten durchführen muss. Das muss geplant werden, sonst können Sie es nicht angemessen berücksichtigen.
Gegen Ende des Projekts werden Mitarbeiter dann auch wieder für andere Projekte eingeplant. Auch dies muss frühzeitig berücksichtigt werden, so dass Sie rechtzeitig Anpassungen vornehmen können, wenn zum Beispiel doch zusätzliche Arbeit anfällt. Es wäre sehr ärgerlich, wenn Sie dem Kunden Versprechungen gemacht haben, die sie nicht einhalten können, weil ihr Projekt unerwartet mehr Zeit in Anspruch nimmt.
Andere Abwesenheiten
Projekt oder kein Projekt, Mitarbeiter gehen in den Urlaub, werden krank und nehmen auch Mal an einer Weiterbildung teil. Das kann erhebliche Auswirkungen haben auf einen Sprint. Sie können nicht davon ausgehen, dass Ihr Team in jedem Sprint die gleiche Anzahl von User Points abarbeiten kann. Mit einem Verständnis für die Kapazitätsplanung, können Sie die anderen Abwesenheiten bei der Planung eines Sprints berücksichtigen. Sie wählen einfach eine kleinere Anzahl an User Points oder Sie sorgen für Ersatz, so dass Sie dennoch mit vollem Einsatz weiterarbeiten können.
3. Leistung messen: der Schlüssel zum lernen
Scrum schaut nur nach vorne
Um den Fortschritt zu messen und an zu passen, arbeitet Scrum mit einem Burndown-Diagramm. Damit wird in grafischer Form die Anzahl der Stunden/Story Points im zeitlichen (idealen) Verlauf, linear dargestellt. Im nächsten Schritt wird der tatsächliche Fortschritt festgehalten, anhand der noch ausstehenden Stunden/Story Points. Bei der Messung des Fortschritts im Moment X, wird lediglich geschaut, was von dem Moment an, bis zum Ende des Sprints, noch umgesetzt werden muss. Ist die Vergangenheit etwa nicht relevant?
Zeiterfassung ist tot, es lebe die Zeiterfassung!
Auf das Erfassen der Zeiten, wird bei Scrum nicht viel wert gelegt. Das bedeutet, zurück zu schauen und davon lassen Sie die Finger. Sie finden, dass es nur eine falsche Haltung bei den Mitarbeitern bewirkt, bei der Sie ständig das Gefühl haben, „sich verantworten zu müssen“. Das führe angeblich zu falschen Verhaltensmustern. Ein Argument, was sicherlich Wahrheit beinhaltet.
Allerdings können Sie durch die Registrierung der Stunden, die Sie für die User Story benötigt haben, einen genauen Vergleich machen mit der Einschätzung der User Story. Damit kann man sehen, wie realistisch die Veranschlagung war und das ist sehr hilfreich, da man für das nächste Mal etwas daraus lernen kann. Messen ist Wissen und damit kann man die nächsten Projekte und User Stories wieder besser einschätzen.
Berichterstattung zu Projekten
Schlussendlich kann ein Planungstool gute Einsichten geben in das gesamte Portfolio von Projekten. Welche Projekte laufen gut und welche laufen weniger gut? Das gibt dem Management einen Hinweis, welche Projekte mehr beobachtet werden müssen.
Was die Leistung des Scrum Teams betrifft: Bei Scrum wird ein gut funktionierendes Team für nachfolgende Projekte beibehalten. In den Zahlen soll das dann auch widergespiegelt werden. Wird die Leistung eines Teams besser? Oder in Scrum-Terminologie: Nimmt die Geschwindigkeit vom Projektteam zu? Weil ein Planungstool den Verlauf registriert, kann es diese Information gut vorhersagen.
Schlussfolgerung
Wenn Sie nur ein Team leiten, dass mit Scrum geplant wird, dann macht ein Planungstool nicht so viel Sinn. Schließlich ist es dann nur ein Team, welches Schritt für Schritt Projekte abarbeitet. Natürlich ist es interessant die Leistung zu messen, aber ein Planungstool ist hier nicht dringend notwendig.
Aber wenn mehrere Scrum Teams eingesetzt werden, die auch noch an anderen (traditionellen) Projekten und Aktivitäten arbeiten, dann hat Planungstool auf jeden Fall einen Mehrwert. Sie haben dann schließlich eine Vielzahl an Mitarbeitern, die konstant bei neuen Projekten eingeteilt werden. Die Übersicht über die Kapazitäten ist dann entscheidend, da sonst die Umsetzung von Projekten gefährdet wird.
Für Timewax haben wir ausgearbeitet, wie die Scrum Methode in Timewax ausgeführt werden kann. Hier finden Sie den Artikel. Hier wird sehr konkret, Schritt-für-Schritt aufgezeigt, wie Sie mit der Vorbereitung, der Veranschlagung, der Planung und der Berichterstattung bei Scrum Projekten, umgehen müssen.
