Agiles Plot-Management, Sprint 3: Die Übersicht behalten

In Sprint 1 wurde beleuchtet, wie man den Plot einer Veranstaltung in Zeitabschnitte einteilt. Pro Zeitabschnitt wurden Aufgabenkarten an das Board geklebt.

Sprint 2 zeigte, wie sich NSC und Helfer über diese Zettelwand koordinieren lassen, und wie Probleme kommuniziert werden können.

Der aktuelle Sprint zeigt, welche Informationen der Plot Owner aus dem Board ziehen kann, und wie er auf Probleme reagieren kann.

Welche Informationen stehen zur Verfügung?

Der Plot Owner wird wahrscheinlich den Fortgang der Veranstaltung im Auge behalten und das grobe Geschehen live mitverfolgen. Dies ist im agilen Ansatz genauso möglich, wie im traditionellen.

Der agile Ansatz ermöglicht es ihm aber, jederzeit zusätzliche Informationen abzurufen, ohne sich erst zu jemandem durchfragen oder durchfunken zu müssen, um eine Antwort zu bekommen.

Dreh- und Angelpunkt für diese Informationen ist das in den letzten Sprints aufgebaute Board. Hier kann der Plot Owner sich jederzeit informieren, welche Aufgaben bereits erledigt sind, welche gerade durchgeführt werden und welche noch in auf ihre Ausführung warten.

Die Summe aller Schätzungen, die das Team pro Sprint bewältigt bekommt, nennt sich „Velocity“. Da wir für den LARP-Ansatz nicht mit Story-Points arbeiten, sondern direkt über die Zeit schätzen, ist die Velocity also gleichbedeutend mit der Anzahl der parallel abgearbeiteten Personenstunden, die in den Stories am Board stecken.

Ein Beispiel hierzu: Wenn ein Team von 18 NSC und 2 Technikern zwei Stunden durcharbeitet, käme es auf 20 * 2 = 40 Personenstunden. Aber die Leute müssen sich auch umziehen, Pause machen, Probleme lösen und anderes machen, deshalb wird die Schätzung sich wahrscheinlich bei ca. 30 Stunden pro Sprint einpendeln. Die Velocity ist dann also 30.

Fragen wie „Wurde den Händlern schon der Met untergeschoben?“ lassen sich also mit einem Blick auf das Board beantworten, ohne erst den NSC finden zu müssen, der die Aktion durchgeführt hat. Im schlechtesten Fall würde man übrigens alle NSC fragen müssen, um herauszufinden, dass die Aktion noch von niemandem durchgeführt wurde.

Ebenfalls zur Verfügung stehen Informationen darüber, welche Aufgaben derzeit aus irgendwelchen Gründen nicht durchgeführt werden können (Blocker).

Was kann man daraus ablesen

Neben der offensichtlichen Information zum aktuellen Status der verteilten Aufgaben bekommt der Plot Owner die wichtigste Information überhaupt: ob die Veranstaltung grob im Zeitplan liegt oder nicht.

Er kann direkt vom Board ablesen, für welche Story-Karten bereits welche Aufgaben erfüllt wurden. Stories, deren Aufgaben komplett erfüllt wurden, sind abgeschlossen. Je weiter der Sprint fortschreitet, desto mehr Stories sollten abgeschlossen werden.

Wenn es irgendwo hapert, kann er sofort abschätzen, wie viele Stories noch in der verbleibenden Zeit spielbar sind, und wie viele Stories wahrscheinlich zum Ende des Sprints unbespielt übrig bleiben.

Wir erinnern uns: Ein Sprint ist eine festgelegte Timebox, dessen zeitliche Grenzen unter keinen Umständen erweitert werden, wenn nicht alle Aufgaben in der Zeit erledigt werden konnten. Stattdessen werden die unerledigten Aufgaben ins Plot-Backlog zurückgegeben und müssen für den nächsten Sprint eingeplant werden.

Den nächsten Sprint vorbereiten

Basierend auf diesen Informationen kann der Plot Owner bereits den nächsten Sprint vorplanen. Dafür sortiert er zunächst gegebenenfalls das Plot-Backlog um: Aufgaben, die unbedingt im nächsten Sprint erledigt werden müssen, wandern an den Anfang des Plot-Backlog.

Danach überlegt er sich, welche Aufgaben aus dem Plot-Backlog im nächsten Sprint schaffbar sein könnten. Hierbei benutzt er zwei Werte, die ihm bekannt sind: die Velocity des Teams, und die Schätzungen auf den Story-Karten.

Das bedingt, dass er für einen neuen Sprint auf keinen Fall Stories einplanen darf, die noch keine Schätzung auf der Karte stehen haben. Dies ist ein wichtiger Punkt. Wenn also eine Story unbedingt in den nächsten Sprint soll, muss er dafür sorgen, dass in der nächsten Grooming-Sitzung eine Schätzung für diese Story-Karte ermittelt wird.

Zusätzlich muss er aber auch den aktuellen Sprint im Auge behalten: Wird das Team fertig? Wenn nein, warum nicht? Werden die Stories nur durch Blocker aufgehalten, oder ziehen sich die Stories im allgemeinen länger, als geschätzt?

Aus den erledigten Stories wird am Ende des Sprints die Velocity des Teams „offiziell“ neu berechnet. „Offiziell“ heißt in diesem Zusammenhang: Natürlich darf der Plot Owner auch im Sprint schon schätzen, wie die neue Velocity aussehen könnte.

Mit diesen Informationen kann er seinen Wunsch-Sprint zusammenstellen, also die Stories heraussuchen, die er im nächsten Sprint erledigt sehen möchte. Dabei beachtet er auch, dass Stories aus dem aktuellen Sprint, die wahrscheinlich nicht mehr erledigt werden können, in den nächsten Sprint übernommen werden sollten, wenn sie wichtig für den Gesamtplot sind.

Wichtig ist, dass eine unerledigte Story nicht automatisch in den nächsten Sprint übergeht. Sie kann auch vorerst oder ganz fallengelassen werden, wenn andere Dinge wichtiger sind.

Beispielsweise kann eine Nebenhandlung, die dazu genutzt werden soll, den Plot einer anderen Veranstaltung anzuteasern, vorerst fallengelassen werden, wenn der Hauptplot zu viele Ressourcen braucht. Andererseits könnte eine Story, die nur zur weiteren Belustigung der Spieler stattgefunden hätte, auch ganz entfallen, wenn die Spieler genug zu tun haben.

Den Plot anpassen

Der Plot Owner denkt dabei durchaus schon mehrere Sprints voraus. Welche Aufgaben müssen auf jeden Fall erledigt werden, um den Hauptplot zu Ende zu bringen? Ist das bei der aktuellen Velocity überhaupt möglich?

Wenn er feststellt, dass sein Team langsamer ist als erwartet, kann er ganze Stories aus der Handlung entfernen, um damit den verbliebenen (wichtigeren) Stories mehr Zeit zu verschaffen. Er kann auch komplette Nebenhandlungen aus der Story nehmen, wenn er merkt, dass die Spieler zu viel Zeit für die Haupthandlung brauchen.

Anpassungen an die Velocity

Stellt er fest, dass das Team schneller ist, als erwartet, kann er ebenfalls reagieren, beispielsweise Nebenhandlungen einfügen oder Handlungen mehr Zeit oder Personen einräumen.

Wenn er beispielsweise merkt, dass ein Strang der Handlung wahrscheinlich im nächsten Sprint abgeschlossen werden kann, kann er die für diese Handlung eingesetzten Personen anderweitig einplanen, beispielsweise, um ein Scharmützel mit einer Räuberbande zu vergrößern.

Anpassungen an die Spielstärke

Wichtig kann auch sein, die Stories an die Spielstärke der Spieler anzupassen. Wenn die Spieler schwächer oder langsamer sind, als erwartet wurde, können Story-Elemente verschoben oder weggelassen werden, um eine Lösung des Plots zum Ende der Veranstaltung nicht zu unwahrscheinlich werden zu lassen. Andererseits: wenn die Spieler stärker oder schneller sind als erwartet, kann er auch hier mit weiteren Nebenhandlungen oder größeren Kampf-Herausforderungen reagieren, damit alle auf ihre Kosten kommen und sich niemand langweilen muss.

Ein Beispiel: Es wurde mit einer durchschnittlichen Anzahl an durchschnittlichen Kämpfer-Charakteren gerechnet. Im Verlauf der Veranstaltung stellt sich heraus, dass sich in den Reihen der Spieler ein kampfstarker Söldnerhaufen befindet. Zusätzlich hören weitere Kämpfer-Charaktere auf die Kommandos der Söldner-Anführer. Dadurch kommt es zu auf der Spielerseite überraschend koordinierten Schlachten, bei denen die NSC entweder in schnellen Wellen respawnen müssen, oder aber gnadenlos untergehen.

Auch hier sollte der Plot Owner seine Stories neu schätzen lassen: Nehmen wir an, den NSC zuliebe wurde festgelegt, dass jeder Schlacht-NSC nur an einer Schlacht pro Sprint beteiligt wird, um den NSC Erholung zu ermöglichen. Alle Kampf-Stories brauchen jetzt aber bedeutend mehr NSC, damit sie für die Spieler, aber auch für die NSC, mehr Spaß bringen. Denn Hand aufs Herz: in einem größeren Scharmützel mit mehr NSC gleichzeitig zu kämpfen, macht einfach mehr Spaß, als in Wellen zu respawnen und mit acht Leuten immer und immer wieder gegen die gleichen 15 Spieler anzurennen. Und den Spielern macht das auch mehr Spaß, als ständig gegen die gleichen acht NSC zu kämpfen.

Das zusammen wiederum kann bedeuten, dass von zwei Schlachten, die in einem Sprint geschlagen werden sollten, vielleicht nur eine in diesem Sprint stattfinden kann. Die zweite Schlacht muss dann auf einen anderen Sprint verschoben werden, was eventuell wieder Teile der Story aufhält.

Wunsch-Sprints und Sprintplanung

Natürlich kann der Plot Owner auf diese Weise nur seinen (oder seine) nächsten Wunsch-Sprint(s) zusammenstellen. Diese Wunsch-Sprints sind aber eine wichtige Basis, um die Sprintplanung des nächsten Sprints enorm zu beschleunigen.

Hat sich der Plot Owner schon vor der Sprintplanung Gedanken darüber gemacht, was in den nächsten Sprint passen kann und was nicht, so muss in dem Treffen nicht mehr groß hin- und hergerechnet werden, um die verfügbaren NSC, Techniker, Helfer und anderen Personen, sowie die verfügbaren Ressourcen optimal auszulasten.

In der Sprintplanung selbst können aber noch einmal Veränderungen an den Wunsch-Sprints passieren, beispielsweise wenn sich in der Sprint-Retrospektive ergeben hat, dass NSC für einzelne Aufgaben generell mehr Zeit benötigen, oder dass längere Ruhepausen nach bestimmten Einsätzen notwendig sind.

Umsortieren des Plot-Backlogs

Zur Vorbereitung der Sprintplanungs-Treffen sollte der Plot Owner jedes mal, wenn er seine(n) Wunsch-Sprint(s) anpasst, das Plot Backlog umsortieren: Die Reihenfolge der ersten Stories sollte der Reihenfolge in seinem Wunsch-Sprint entsprechen. Bei mehreren Wunsch-Sprints sollten im Plot Backlog also zunächst die Stories des ersten Wunsch-Sprints in Reihenfolge zu finden sein, dann die des zweiten in Reihenfolge und so weiter.

Wenn er auf diese Weise Wunsch-Sprint für Wunsch-Sprint vorgeht, ist das Plot Backlog sowohl für die Sprintplanung, als auch für mögliche Pull Ins vorbereitet.

Werden wir fertig?

Jedes mal, wenn das Plot Backlog angepasst wird, sollte grob überschlagen werden, ob die Anzahl der Stories pro Sprint, multipliziert mit der Anzahl der verbleibenden Sprints, grob ausreicht, um alle Stories im Plot Backlog zu bespielen.

Kleinere Ungenauigkeiten bei dieser Rechnung entstehen durch die unterschiedlichen Schätzungen innerhalb der Stories, darum sind kleinere Abweichungen selten ein Problem. Wenn aber die Zahl der bespielbaren eklatant von der Zahl der zu bespielenden Stories abweicht, sollte der Plot Owner reagieren, indem er versucht, Stories einzusparen.

Beispielsweise kann er Nebenhandlungen vereinfachen. Er kann andere Wege finden, den Charakteren Informationen zuzuspielen, die sie sich sonst hätten erarbeiten müssen. Und er kann natürlich auch Teile der Handlung komplett streichen, beispielsweise den Spielern ermöglichen, einen Dämon einfach auf bewährte Weise in die Niederhöllen zurückzuprügeln, statt sie erst ein aufwändiges Bannritual vorbereiten zu lassen.

Hier ist allerdings Fingerspitzengefühl gefragt, denn die Streichungen müssen natürlich zur versammelten Spielerschaft (und zum Team!) passen. Wenn viele Krieger und Kampf-NSC versammelt sind, ergibt es beispielsweise wenig Sinn, ausgerechnet die Schlachten zu streichen. Sind viele Magier und Wissenssammler vor Ort, ergibt es wiederum keinen Sinn, die Informationsbeschaffung und -auswertung einzukürzen.

Wenn sich im anderen Fall allerdings herausstellt, dass die Stories auszugehen drohen, bevor der letzte Sprint der Veranstaltung erreicht ist, kann der Plot Owner auch hier kreativ werden und gegensteuern. Er könnte den Charakteren zusätzliche Steine in den Weg legen, das Erlangen von Plotgegenständen von weiteren Nebenhandlungen abhängig machen. Oder aber, er gibt Plotgegenstände einer Gruppe Gegner in die Hände, die zunächst besiegt werden muss. Auch hier ist Fingerspitzengefühl und ein Gespür für die aktuelle Veranstaltung nötig.

Um den Spielern etwas zu tun zu geben, während alle NSC ausgelastet sind, könnte er Texte mit IT-Informationen zusätzlich verschlüsseln, so dass diese erst entschlüsselt werden müssen, ehe der Inhalt ins Spiel eingehen kann.

Ausblick

Dieser Artikel hat das System aus der Sicht des Plot Owners beleuchtet und gezeigt, wie er die gegebenen Informationen zur Vorausplanung nutzen kann.

Im nächsten Artikel wird es um spezielle Situationen und Probleme innerhalb eines Sprints gehen und wie der Plot Owner darauf reagieren kann.

Artikelbild: Kristina Schlemmer