.st0{fill:#FFFFFF;}

Scrum Einführung

Planung in Scrum: diese 3 Varianten kommen vor (mit Vergleich)

 Mai 11, 2021

von  Sebastian

Um die Planung in Scrum gibt es immer wieder Diskussionen. Ich zeige dir in diesem Artikel 3 Möglichkeiten, deine Arbeit in Scrum zu gestalten. Dazu stelle ich dir drei typische Varianten vor, die in Teams oft zu sehen wird. Dabei werfen wir genau den Blick auf die Varianten der Sprint Planung und diskutieren wir Vor- und Nachteile

Planung in Scrum

Wenn wir von Planung in Scrum sprechen, dann hat jeder der Scrum kennt wahrscheinlich die Sprint Planung 1 und Sprint Planung 2 vor Augen. Wer das letzte Update von Scrum Guide schon lebt, der hat sogar schon die Sprint Planung 3. Egal, wie genau du nun danach arbeitest, ich möchte dir in diesem Artikel drei konkrete Ansätze vorstellen, die häufig verwendet werden.

Lass uns zudem jetzt mal alle Details sowie Vorlieben für oder gegen eine bestimmte Art noch etwas zurückstellen und uns diese dann erst am Ende noch mal reflektieren.

Variante 1: Die einfachste Art der Planung

Variante 1

Vielleicht kennst du diese Menschen auch (oder bist selbst einer davon), die einfach unheimlich ungerne planen. "Das kann man eh alles nicht genau sagen", "das ist viel zu viel Arbeit" und ähnliche Aussagen, kennst du vielleicht bereits, wenn es darum geht den nächsten Sprint zu planen. Oder aber du hast noch recht wenig Erfahrungen und stehst bei deiner Scrum Einführung - auch dann scheint diese Variante der Planung und die Aussagen von oben erstmal recht logisch. 

Ich bringe hier gerne noch den Aspekt der (nicht wertenden) Reife des Teams bei der Planung in Scrum mit ins Spiel. Ist diese nicht hoch, auch dann findet sich diese Variante 1 oft in der Planung. Grundsätzlich unterschiede ich die zwei folgenden Dinge in dieser Situation.

Genaue Planung wird gebraucht, aber nicht gesehen

Es gibt Teams, die sich strikt weigern, genauere Planungen zu erstellen. Haben wir User Stories, dann wird partout keine einzige Aufgabe dazu genauer überlegt. Wenn du genauer in diese Teams und das Arbeitsverhalten schaust, stellst du aber schnell fest, dass Planungen nicht funktionieren, es wird sich verschätzt und oft etwas ganz anderes verstanden, als tatsächlich gemeint war. Manche Teams haben das Bewusstsein drüber und ändern trotzdem nichts, anderen fehlt dieses Bewusstsein tatsächlich noch.

Genaue Planung wird nicht gebraucht und nicht getan

Je nachdem was für ein Produkt erstellt wird, kann es durchaus sein, dass sich eine gröbere Planung als eine "User Story Ebene" nicht benötigt wird. Diese Teams planen dann auch nicht genauer. Das kann zum Beispiel sein, da die Arbeit auf der Ebene schon granular genug ist und der Sprint so kurz, dass diese Arbeit schon absolut so vorliegt, dass Teams damit arbeiten können. Bei solchen Teams stellst du meistens fest, dass sie die geplante Arbeit sehr gut schaffen und sich wenig verschätzen. Die Qualität leidet auch nicht.

Die einfachste Planung, die du in Scrum haben kannst ist die, dass du recht grob auf Basis des Sprints planst und das Team lediglich sagt "wir schaffen diese 12 Product Backlog Items im Sprint". Dagegen ist erstmal auch absolut nichts zu sagen. Eine weitere Verfeinerung wird dabei erstmal nicht durchgeführt. Ob das für den Kontext ausreichend ist, muss im Einzelfall analysiert werden.

Variante 2: Die typische Art der Planung

Variante 2

Wenn ich von typischer Planung spreche, dann meine ich damit, dass sich ein Team zuerst überlegt, was es in einem Sprint schaffen möchte und in einem zweiten Schritt wie es das genau umsetzen möchte.

Dabei kannst du bei der einfachen Art der Planung starten. Sie wird dann lediglich um einen zweiten Schritt erweitert. Das bedeutet, dass du - wie eben beschrieben - nach der Auswahl was du in dem Sprint machen möchtest, nun dir überlegst, wie du das konkret umsetzen kannst. Dafür legt sich das Team in der Regel weitere Aufgaben an, die das Product Backlog Item in kleinere Teile zerschneidet und so übersichtlicher macht.

Wenn du so möchtest, dann ist das der typische Weg, den Teams in Scrum gehen und entsprechend vollziehen. Diese Art der Planung in Scrum ist wirklich sehr gut im Aufwand / Nutzenverhältnis.

Variante 3: Die erweiterte Art der Planung

Variante 3

Es gibt Teams, die schaffen sich durch weitere Mechanismen neue Möglichkeiten den eigenen Prozess ständig zu verbessern. In einem anderen Artikel habe ich das Flow Board bereits angesprochen. So etwas kannst du in deinem Sprint benutzen. Also du bist damit noch genauer in deiner Planung, schaffst dir zusätzliche Möglichkeiten.

Andere erweitern das Sprint Backlog auf andere Weise und ergänzen Dinge, die durch Retrospektiven erarbeitet werden und sich nach und nach mehr an das Bedürfnis der Teams anpassen. Dieser Weg ist ein sehr individueller und kann sich sowohl unterstützend, wie auch ausbremsend wirken - je nach dem in welche Richtung er sich entwickelt.

Negative Verbesserung

Nehmen wir an du hast ein Sprint Backlog und hast drei Spalten. Du erweiterst das Sprint Backlog nun um Anforderung, Analyse, Design, Implementierung, Test und Auslieferung, dann ist das mit Sicherheit ein Anti-Pattern für Scrum. Du bildest dann ein sehr sequentielles Vorgehen in einem inkrementellen Vorgehen ab, was zu Konfliktpunkten führt.

Zusammenfassung

Abschließend möchte ich mir dir die drei Varianten einmal kurz reflektieren und gegenüberstellen. Wie so oft ist es nicht richtig oder falsch, sondern kommt sehr auf den Kontext an. 

Gute oder schlecht?

Früher war ich immer sehr versucht, selbst schnell zu urteilen. "Du machst das nicht so, wie es im Scrum Guide steht" - gut, dass der Scrum Guide mittlerweile ja auch deutlich "abstrakter" geworden ist und einige Aussagen konkrete Fragen / Aussagen entfernt wurden (eine Übersicht findest du dazu immer hier). 

Mittlerweile versuche ich deutlich mehr zu verstehen, warum Menschen das eine oder das andere machen. Und auch wenn ich sehr den Aufbau von dem "was und wie" bin, so durfte ich auch Situationen erleben, in denen so etwas gar nicht zwingend nötig war. Insofern soll dieser Artikel auch kein Plädoyer für eine bestimmte Variante der Planung in Scrum sein, sondern aufzeigen, was existieren könnte.

Der Vergleich

Die drei Varianten im Vergleich gehen wir hier noch mal für die Planung in Scrum durch. Ich habe dazu versucht einige Themen aus der Praxis mit einzuarbeiten, so dass du auch für deine Planung in Scrum reflektieren kannst.

Variante 1

  • Sehr einfach umzusetzen und einzuführen
  • Gut bei kleinen Aufgaben und kurzen Sprints
  • Fehlende Transparenz und Einsichten bei größeren / komplizierten Augaben
  • Fortschritt bei mehreren Menschen im Team schlecht zu erkennen
  • Braucht in der Regel wenig Argumentation, um umgesetzt zu werden

Variante 2

  • Der Klassiker: gutes Mittel Zwischen Aufwand und Nutzen
  • Je mehr Menschen an Aufgaben arbeiten, desto bessere Sichtbarkeit über Abstimmung und Fortschritt
  • Gute Reflexion, ob die Aufgaben richtig verstanden wurden
  • Erhöhter Aufwand zur Variante 1, der sich in der Regel immer positiv in der Planung auswirkt

Variante 3

  • Eignet sich für reife und erfahrene Teams
  • Sollte nicht die erste Aktion eines neuen Teams sein
  • Findet sich meistens immer aus Retrospektiven oder ähnlichen Anlässen der Verbesserungen
  • Richtig durchgeführt lohnt sich der erhöhte Aufwand meistens im Team

Wie gestaltest du deine Planung in Scrum?

Wie ich schon erwähnt habe, ist die Planung in Scrum nicht immer gleich. Wie sieht deine Planung aus, welche Variante (vielleicht sogar eine neue Variante?) nutzt du bei dir im Team? Bin auf deine Erfahrungen gespannt, schreib mir gerne in den Kommentaren!

Sebastian

Ein paar Worte über den Autor

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

Sebastian Schneider CSP-PO
Sebastian Schneider CSP
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

>