Planungsworkshops

Ziel

Der Planungsworkshop bestimmt, welcher Wert in einem vereinbarten Zeitraum geliefert werden kann, und holt die Verpflichtung des Teams auf diesen Inhalt ein. Die Agile Extension zum BABOK Guide schreibt ihm zwei weitere Wirkungen zu: die Zusammenarbeit mit dem Kunden in jedem Zeitraum und die Überarbeitung des Plans anhand dessen, was die Rückmeldungen aus der Praxis zutage fördern.

Das Ergebnis der Sitzung ist eine datierte Verpflichtung: ein Ziel für den Zeitraum, die Liste der Items, die es erreichen sollen, und der Arbeitsplan, den sich das Team gibt. Die Agile Extension unterscheidet zwei Ebenen der Sitzung. Die erste findet vor den Iterationen statt und deckt das laufende Release ab, also alle Funktionalitäten, die zum selben Termin geliefert werden. Die zweite betrifft eine einzelne Iteration oder einen bezeichneten Ausschnitt des Backlogs.

Das Backlog-Refinement, eine Tätigkeit des Backlog-Managements, geht der Sitzung in der Regel voraus: Grösse, Umfang und Komplexität der Items werden dort erarbeitet. Die Planung setzt diese Arbeit als erledigt voraus.

Platz in der Familie der Workshops

Der Workshop, wie ihn der BABOK Guide definiert, ist die allgemeine Form der moderierten Sitzung: eine repräsentative Gruppe von Stakeholdern, ein definiertes Ziel, interaktive und gemeinsame Arbeit, ein definiertes Arbeitsergebnis und eine moderierende Person. In dieser Form dient er dem Scoping, der Modellierung, der Elizitation oder der Validierung von Anforderungen. Während der allgemeine Workshop das Ziel erhält, das ihm der Raum zuweist, hat der Planungsworkshop immer dasselbe: entscheiden, was in einem Zeitraum geliefert wird, und sich darauf verpflichten. Jede Planungssitzung ist deshalb ein Workshop im allgemeinen Sinn; umgekehrt gilt das nicht.

Anwendung

Wann anwenden

• Eröffnung einer Iteration: das Ziel des Zeitraums festlegen und die Items auswählen, auf deren Fertigstellung sich das Team verpflichtet.
• Start eines Releases: die Funktionalitäten über das gesamte Release hinweg sequenzieren, bevor die erste Iteration beginnt.
• Abwägung zwischen Initiativen: diejenigen auswählen, die den Zielen der Organisation dienen, und die Ressourcen auf sie verteilen.
• Mehrere Teams an einem Produkt: die Abhängigkeiten zwischen den Items sichtbar machen, bevor eine Verpflichtung eingegangen wird.
• Wechselnde Prioritäten: die Rückmeldungen aus dem abgelaufenen Zeitraum lenken den Inhalt des nächsten um.

Wann nicht anwenden

• Backlog weder geschätzt noch geordnet: Die Sitzung kippt ins Refinement; vorbereiten lässt sie sich mit Backlog-Management und Schätzung.
• Entscheidung ohne Lieferverpflichtung: Scoping oder die Validierung von Anforderungen führt man als Workshop im allgemeinen Sinn durch.

Beschreibung

Die zwei Teile der Sitzung

Die Agile Extension teilt die Sitzung in zwei Teile. Im ersten, dem Was, legt der Produktverantwortliche das Ziel, das erwartete Ergebnis, den angestrebten Termin und die höchstpriorisierten Backlog-Items dar; anschliessend klärt er die Details, nach denen das Team fragt, und prüft die Ausrichtung auf die verfolgten Ziele. Im zweiten, dem Wie, bespricht das Team, wie jedes Item fertiggestellt werden kann und was es dafür braucht.

In der Praxis plant ein Team, das mit dem Wie beginnt, einen Inhalt, den noch niemand festgelegt hat, und der Produktverantwortliche findet sich dabei wieder, mitten in einer technischen Diskussion einen Geschäftswert abzuwägen. Zeigt das Wie Kosten, die das Was nicht vorhergesehen hatte, wird die Auswahl während der Sitzung wieder geöffnet.

Die fünf Elemente

Das geschätzte und geordnete Backlog ist die wichtigste Eingabe. Die Agile Extension überträgt das Schätzen und das Ordnen der Items den Praktikern der Business-Analyse. Eine Sitzung, die eine ungeordnete Liste erhält, verbringt ihr Zeitfenster damit, sie zu ordnen, statt zu planen.

Die Velocity des Teams, der in den vorangegangenen Zeiträumen festgestellte Durchsatz, macht die Ordnung realistisch: Sie begrenzt, was angenommen werden kann. In Kanban übernehmen die WIP-Limiten diese Begrenzung, und die Sitzung dient dann dem Wissensaustausch statt der Verpflichtung auf eine Iteration.

Das Iterationsziel oder das Bündel von Funktionalitäten ist eine Teilmenge des Release-Ziels oder der Roadmap. Ein Item, das diesem Ziel nicht dient, wartet auf den nächsten Zeitraum, auch wenn es bereit ist.

Die Auswahl der Items liegt beim Produktverantwortlichen, der das Ziel und die höchstpriorisierten Items aus dem Release-Plan übernimmt und dabei den Wert gegen die verfügbare Velocity abwägt. Die Agile Extension ordnet dieser Auswahl auch Arbeiten zu, die keine Funktionalität hervorbringen: Fehler, Einrichtung von Umgebungen, Forschungsarbeiten, Verwaltungsarbeiten. Wer sie aus dem Plan lässt, plant eine Kapazität, die das Team nicht hat.

Die Aufgabenplanung zerlegt jedes ausgewählte Item in Arbeiten, die den Teammitgliedern zugewiesen werden können. Diese Zerlegung macht aus einer Liste von Items einen Plan, auf den sich ein Team verpflichten kann.

Die drei Horizonte

Die Technik lässt sich auf jedem Planungshorizont anwenden, mit einem Zweck und einem Detaillierungsgrad, die dem Horizont folgen. Die Agile Extension führt sie nach Horizont aus: Auf dem Horizont Strategie schafft die Sitzung ein gemeinsames Verständnis dafür, warum es eine neue Initiative gibt; auf dem Horizont Initiative dafür, wie die Lösung gebaut wird.

Auf dem Horizont Delivery findet die Sitzung zu Beginn jeder Iteration statt, in einem Zeitfenster, das sich das Team selbst setzt, um das nächste Bündel von Items durchzugehen. Die Agile Extension verlangt, dass das Team die Ziele der Iteration versteht und sich daran hält, samt dem Wert der angestrebten minimal vermarktbaren Funktionalität (minimal marketable feature), den geschäftlichen Anliegen und der Aufteilung der Stories.

Die Agile Extension legt für keinen dieser drei Horizonte eine Dauer fest. Die einzige bezifferte Obergrenze stammt aus Scrum und gilt allein für den Horizont Delivery. Eine Portfolio- oder Release-Sitzung bemisst sich deshalb an ihrer Traktandenliste und an der Verfügbarkeit derer, die entscheiden.

Der Horizont Delivery: das Sprint Planning

In Scrum ist der Planungsworkshop des Horizonts Delivery das Sprint Planning. Das Event eröffnet den Sprint, indem es die zu leistende Arbeit darlegt, und der daraus entstehende Plan wird vom gesamten Scrum Team erstellt. Der Product Owner stellt sicher, dass die Teilnehmenden bereit sind, die wichtigsten Product-Backlog-Items zu besprechen und zu klären, wie sie sich auf das Produkt-Ziel beziehen. Weitere Personen können eingeladen werden, um Rat zu geben.

Der Guide knüpft das Vertrauen der Entwickler in ihre Prognosen an drei Dinge, die sie kennen: ihre bisherige Leistung, ihre bevorstehende Kapazität und ihre Definition of Done. Das Sprint-Ziel, die ausgewählten Product-Backlog-Items und der Plan zu ihrer Lieferung bilden zusammen das Sprint Backlog.

Der Guide begrenzt die Dauer auf acht Stunden für einen einmonatigen Sprint; bei kürzeren Sprints fällt das Event in der Regel kürzer aus. Der Scrum Master sorgt dafür, dass die Events stattfinden, dass sie positiv und produktiv sind und dass sie ihr Zeitfenster einhalten. Der Guide verwendet das Wort Moderator nicht, und er beschreibt weder eine protokollführende noch eine zeitnehmende Rolle: Die Führung der Sitzung liegt beim Team.

Was die Sitzung scheitern lässt

Das unvollständige Team

Die Technik verlangt, dass alle Teammitglieder anwesend sind. Eine Abwesenheit wird zweimal bezahlt: Die Sitzung wird unterbrochen, um die fehlende Information zu beschaffen, und der Plan wird noch einmal gemacht, wenn die abwesende Person mit einer Einschränkung zurückkommt, die niemand gesehen hatte. Die Agile Extension weist darauf hin, dass sich das Problem bei verteilten Teams verschärft und ebenso bei Teams, deren Mitglieder in mehreren Teams arbeiten. Wo ein gemeinsamer Termin unmöglich ist, ist die einzige praktikable Abhilfe die Vorbereitung: Die Einschränkung der abwesenden Person wird vor der Sitzung erhoben und von einem anwesenden Mitglied in die Sitzung getragen, das dafür einsteht.

Das missverstandene Backlog

Die Agile Extension zählt das unzureichende Verständnis des Backlogs zu den Grenzen der Technik, weil es zu einem schwachen Plan führt. Der Raum verbringt die erste Stunde damit, zu beschreiben, was ein Item tut, statt zu entscheiden, ob es hineinkommt. Die Sitzung wird damit zum Refinement, einer nützlichen Arbeit, die anderswo ihren Platz hat und hier die Zeit der Entscheidung verbraucht.

Die zu knappe Zeit

Ein zu knappes Zeitfenster verschiebt die Klärung von Ziel und Inhalt auf die folgenden Tage, ausserhalb der Sitzung und ohne den Produktverantwortlichen.

Das offen gelassene Ziel

Auf dem Horizont Delivery verlangt der Scrum Guide, dass das Sprint-Ziel vor dem Ende des Sprint Plannings festgelegt wird. Ein Team, das die Sitzung mit einer Liste von Items und ohne Ziel verlässt, hat das Element verloren, mit dem es ein unvorhergesehenes Ereignis gegen die Absicht des Sprints abwägen kann. Es wird jeden Zwischenfall als Verhandlung über den Umfang behandeln.

KI-Überlegungen

Vor der Sitzung arbeitet ein Sprachmodell auf dem bereits geordneten Backlog. Es findet die Items, deren Beschreibung nicht ausreicht, um die Arbeit daran zu planen, jene, die sich überschneiden, und jene, die von einem nicht ausgewählten Item abhängen. Aus den obersten Items schlägt es Formulierungen für das Iterationsziel vor, die der Raum umschreibt. Nach der Sitzung bringt es den Aufgabenplan in Form und prüft, ob sich jedes ausgewählte Item auf das genannte Ziel bezieht.

Was das Modell nicht weiss, entscheidet über die Sitzung. Die Kapazität des kommenden Zeitraums hängt von Abwesenheiten, vom Pikettdienst und von Unterbrechungen ab, die nur das Team kennt. Zur Bezifferung gedrängt, liefert ein Modell eine plausible Zahl, die aus keiner Erhebung stammt, und der Plan erbt eine Genauigkeit, die er nicht hat. Die Verpflichtung gehört den Personen, welche die Arbeit leisten werden: Eine fertig angelieferte Auswahl streicht die Diskussion über das Wie, welche die Hälfte der Sitzung ausmacht. Ein Backlog trägt Kundensegmente, Beträge und regulatorische Auflagen, die das Unternehmen nicht verlassen sollen, und sie werden vor jeder Übermittlung an ein öffentliches Modell entfernt.

Beispiele

Die Division Digital Banking einer Westschweizer Retailbank, die der Aufsicht der FINMA untersteht, plant die Inbetriebnahme der Sofortüberweisung zwischen Privatpersonen in ihrer Mobile-App. Dieselbe Technik wird auf allen drei Horizonten angewandt, und das Ergebnis jeder Sitzung wird zur Eingabe der nächsten.

Keine Sitzung entscheidet anstelle der nächsten: Die Budgetverteilung sagt nichts über die Lieferreihenfolge, und der Release-Plan sagt nichts darüber, welche Aufgaben in den beginnenden Sprint passen.

Die Sitzung des Horizonts Delivery dauert zwei Stunden, eine Dauer, die sich das Team unter der Obergrenze des Scrum Guides selbst gesetzt hat.

Visualisierungen

Die dreistufige Kaskade ist die Zeichnung, welche die Technik trägt. Ein Panel je Horizont, jedes mit seiner Sitzung und dem Ergebnis, das sie hinterlässt, verbunden durch eine Kette von Pfeilen, in der die ausgewählte Initiative den Release-Plan speist und der Release-Plan das Sprint Backlog. Das Panel des Horizonts Delivery nennt das Sprint Planning mit seinen drei Themen, und seine zwei Ergebnisse setzen sich in den startenden Sprint fort.

Kosten

Werkzeuge

Backlog-Management-Werkzeuge (Jira, Azure DevOps, GitLab und ihre Entsprechungen) tragen die Eingabe und das Ergebnis der Sitzung: vorher das geordnete und geschätzte Backlog, nachher die ausgewählten Items und ihre Aufgaben. Sie liefern auch die Erhebung des in den vorangegangenen Zeiträumen gelieferten Durchsatzes, die Quelle der Velocity, mit der die Auswahl begrenzt wird.

Kollaborative Whiteboards (Miro, Mural, FigJam und ihre Entsprechungen) dienen dem Horizont Initiative: Funktionalitäten über mehrere Releases hinweg zu sequenzieren, geschieht durch das Verschieben von Karten, ein Vorgang, den die Listenansicht eines Backlog-Werkzeugs mühsam macht.

Wand und Karten bleiben für ein Team am gleichen Standort auf dem Horizont Delivery die schnellste Einrichtung, sofern der Plan danach in das Backlog-Werkzeug zurückwandert, den einzigen Ort, an dem er die Woche überdauert.

Die Tabellenkalkulation genügt auf dem Horizont Strategie, wo die Sitzung ein Dutzend Zeilen bewegt: Kandidateninitiativen, Budget in CHF, zugeteilte Kapazität, angestrebte Metrik. Jede Zeile an eine bestehende Metrik zu knüpfen, unterscheidet eine Verteilung von einem Wunsch.

Die Videokonferenz mit geteiltem Board ist das, worauf ein verteiltes Team zurückgreift. Sie trägt die Sitzung, ohne die Abwesenheit eines Mitglieds auszugleichen.

Quellen

• IIBA, Agile Extension to the BABOK Guide, §7.8 Planning Workshops: der Zweck der Technik, die Verpflichtung auf einen vereinbarten Zeitraum, die zwei Ebenen der Sitzung und die Aufteilung in zwei Teile, die fünf Elemente, darunter das geschätzte und geordnete Backlog, die Velocity und die Aufgabenplanung, die Anwendung auf den drei Planungshorizonten, der Fall Kanban und die genannten Grenzen, unvollständiges Team, zu knappe Zeit und missverstandenes Backlog.
• IIBA, Agile Extension to the BABOK Guide, §4.7.1 und §5.7.1, die Techniken nach Planungshorizont: die Verteilung der Ressourcen auf die Initiativen und der Grund, warum es eine neue Initiative gibt, auf dem Horizont Strategie, das gemeinsame Verständnis davon, wie die Lösung gebaut wird, auf dem Horizont Initiative.
• Ken Schwaber und Jeff Sutherland, The Scrum Guide (November 2020), Abschnitt "Sprint Planning": die Ausprägung des Horizonts Delivery, ihre drei Themen, das vor dem Ende des Events festgelegte Sprint-Ziel, das Sprint Backlog, die Obergrenze von acht Stunden für einen einmonatigen Sprint und die Rolle des Scrum Masters bei der Durchführung des Events.
• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.50 Workshops: die allgemeine Definition des moderierten Workshops, zitiert, um den Planungsworkshop als spezialisiertes Mitglied dieser Familie zu verorten.