Praxis: Sprints vorausplanen

Posted on by Oliver

Warum planen?
Es wäre großartig, wenn wir die Zukunft vorhersagen oder planen könnten, um nicht überrascht zu werden. Aber die Realität sieht anders aus. Überraschungen zwingen uns, unvorbereitet zu reagieren, was anstrengend und fehleranfällig ist. Deshalb ist es wichtig, sich vorzubereiten und abzusichern.


Plan vs. Realität
Aber wie können wir uns auf die Zukunft vorbereiten, wenn wir nicht wissen, was passieren wird? Wie der Scrum Guide sagt: “In komplexen Umgebungen ist unbekannt, was passieren wird.”. Der Wunsch nach einem Plan wird von der Unvorhersagbarkeit der Zukunft torpediert. Je mehr Zeit wir der Realität geben desto mehr Möglichkeiten kann sie nutzen, sich von unserem Plan zu entfernen.
Es ist wie bei einem Kapitän, der eine Reise plant: Er weiß, dass er auf unvorhersehbare Ereignisse wie Stürme, Strömungen und andere Schiffe stoßen kann, die ihn zwingen, seinen Kurs zu ändern. Je länger die Reise dauert, desto wahrscheinlicher ist es, dass er seinen Plan ändern muss, um sein Ziel zu erreichen. Aber selbst wenn der Kapitän seinen Plan ändern muss, bleibt sein Ziel dasselbe.


Lösung: Kurze Zeiträume
Um die Menge möglicher Veränderungen klein zu halten, kann es helfen, den Zeitrahmen klein zu halten. Im Bild unseres Kapitäns gesprochen würde dies bedeuten, nur den Weg bis zur ersten Etappe zu planen. Passend dazu steht im Scrum Guide: “Es [die Sprints, Anm. des Autors] sind Events mit fester Länge von einem Monat oder weniger, […].”. Meint: Plane in überschaubar kurzen Zeiträumen.


Was bedeutet das für die Planung von Sprints?
Es besteht die Gefahr, dass wir den kurzen Zeitraum eines Monats überschreiten. Aber sollten wir uns deshalb immer nur auf einen Sprint vorausdenken? Grundsätzlich ist das möglich und manchmal sinnvoll. Zum Beispiel in zeitlich befristeten Projekten mit wenigen Beteiligten und daher geringem Koordinationsbedarf.
Bei einer größeren Software mit vielen Beteiligten ist es hingegen oft sinnvoll, langfristigere Überlegungen anzustellen. Zum Beispiel, um Bereiche des Unternehmens abzustimmen. So sollte das Marketing die Chance bekommen, sich frühzeitig mit neuen Features auseinanderzusetzen, um den Markt vorzubereiten. Auch Consulting, Vertrieb und Support sollten vor den Kunden wissen, was auf sie zukommt.
Manchmal müssen wir also einen Zeitraum größer als einen Sprint betrachten.


Lösung: Ziele statt Aufgaben
Um dennoch die Menge möglicher Veränderungen klein zu halten, hilft es, das Abstraktionslevel zu erhöhen: Man plant weniger detailliert, deutlich gröber, dennoch zielgerichtet.

Wenn das Marketing beispielsweise weiß, dass in einigen Monaten das sperrige Menü der Anwendung durch eine schicke Navigationsstruktur ersetzt wird und welche 2-3 wesentlichen Merkmale diese hat, genügt dies oft bereits. Ob sich die Menüpunkte auch nach Länge ihres Namens sortieren lassen, ist weniger relevant.
Der Plan ist also deutlich gröber bzw. abstrakter als auf Ebene eines Sprints. Mike Cohn spricht hier im Bild der Überschriften einer Story Map von “Titles”, Skalierungs-Frameworks nennen es “Features” oder “Epics”. Man kann auch im OKR-Gedanken von Zielen sprechen. Im Bild unseres Kapitäns wäre dies bspw. das Ziel seiner Reise. In jedem Fall handelt es sich nicht um etwas kleinteiliges wie User Stories oder andere Inhalte eines Sprints.

Weitere Fragen aus der Praxis:

  • Kann es mehr als ein Sprint Backlog geben, wenn dies ein für den Sprint gewähltes Set von Product Backlog Items ist (“Das Sprint Backlog besteht aus […] den für den Sprint ausgewählten Product Backlog-Einträgen […].”), neue Sprints aber immer erst nach Abschluss des vorherigen starten (“Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.”)?
  • Wie verhält sich die Prio der Stories in allen Sprint-Backlogs zum Product-Backlog? Ist die Prio in Sprint-Backlogs gezogener Items höher, weil schon im Sprint-Backlog,
    oder niedriger weil Items für neue Sprints im Planning nur aus dem Product Backlog gezogen werden?
  • Wie vermeiden wir beim Planen von Zeiträumen größer ein Sprint uns zeitlich zu verschätzen (Planungsfehlschluss)?
  • Wie wahren wir die Verantwortung der Entwickler für die Sprint-Inhalte (“Das Sprint Backlog ist ein Plan von und für die Developer:innen.”), wenn nicht das Team sondern allein der Product Owner Sprints (vor)plant?

Fazit
“Plans are nothing; planning is everything.” (Dwight D. Eisenhower): Planen ist sinnvoll, um sich einen Überblick zu schaffen oder ein Ziel zu verfolgen.
Auf Sprint-Ebene detailliert die Zukunft zu planen ist bestenfalls Zeitverschwendung und schädigt im schlechtesten Fall zusätzlich das Verständnis von Scrum, die Prioritäten und das Verantwortungbewußtsein im Team.

Feedback
Wenn ihr Anmerkungen, Ideen, Vorschläge oder anderes Feedback zu diesem Artikel habt schreibt mir gern eine Mail an Feedback[at]scrummastersmind.com

Quelle: