Sprintplanung

Artikel
06/10/2015

Von Mitch Lacey. Besitzer von Mitch Lacey & Associates, Inc, einem auf Agile- und Scrum-Umsetzungen und -Optimierungen spezialisierten Beratungsunternehmen.

Januar 2012.

Sprintplanung muss nicht schwierig sein. Sie kann Spaß machen und hilft dem Scrumteam, Teamgeist zu entwickeln, indem gemeinsam die Frage beantwortet wird "Wozu können wir uns verpflichten?" In diesem Artikel stellen die Autoren Beispiele und Strategien für eine fokussierte und effektive Sprintplanung vor und erläutern mögliche Lösungen für Probleme, mit denen sich Teams häufig bei der Sprintplanung konfrontiert sehen.

Betrifft

Application Lifecycle Management; Team Foundation Server

In diesem Artikel:

Einführung
Prognose oder Verpflichtung?
Was genau ist die Sprintplanung?
Wie gehen wir dabei vor?
Häufige Probleme
- Szenario: Das Team kann sich nicht auf alle vom Produktbesitzer gewünschten Storys festlegen.
- Szenario: Der Produktbesitzer hat sich nicht vorbereitet.
- Szenario: Teil 1 überschreitet den Zeitrahmen.
- Szenario: Teil 2 überschreitet den Zeitrahmen.
- Szenario: Der Produktbesitzer ist nicht verfügbar.
- Szenario: Das Team verfügt nicht über die erforderlichen Akzeptanzkriterien.
- Szenario: Der Produktbesitzer weiß nicht, was "abgeschlossen" genau bedeutet.
- Szenario: Der ScrumMaster oder der Produktbesitzer nimmt die Schätzung vor bzw. beeinflusst die Schätzungen/Arbeit des Teams.

Wir planen nicht. Wir setzen auf Scrum und agieren.

Das höre ich immer wieder. Viele Leute verbinden mit den Begriffen "Scrum" und "agil" keine Planung, keine Schätzung, keine Besprechungen, kein gar nichts! Das entspricht jedoch in keinster Weise den Tatsachen. Bei einem agilen Projekt gibt es Pläne auf vielerlei Ebenen: den Tagesplan oder die tägliche Besprechung, die wöchentlichen Pläne (Sprint, Iteration, Rückstand), den Veröffentlichungsplan (Produktrückstand) und möglicherweise noch weitere.

Schauen wir uns die Springplanung einmal näher an.

Prognose oder Verpflichtung?

Im Sommer 2011 haben Ken Schwaber und Jeff Sutherland ihr Scrum-Handbuch überarbeitet. Dabei haben sie ein langjähriges, mit Scrum verbundenes Verhaltensmuster ausgesondert, und zwar die Verpflichtung, die das Team gegenüber dem Produktbesitzer und den Kunden eingeht. Verpflichtung wurde durch Prognose ersetzt. Es wird argumentiert, dass Teams ihre Arbeit prognostizieren, sich jedoch nicht darauf festlegen können.

Ich verstehe diese Logik zwar, ziehe jedoch eine Verpflichtung aus den folgenden Gründen vor:

Wenn sich das Team zu etwas verpflichtet, ergibt sich dadurch eine andere Einstellung oder Denkweise als bei einer reinen Prognose. Eine Prognose impliziert, dass es akzeptabel ist, wenn nicht alle zugesagten Leistungen erbracht werden. Zwar lernen Teams möglicherweise aus ihren Prognosen, sodass es letztendlich zu geringeren Abweichungen bei ihren Schätzungen kommt, aber meiner Meinung nach dauert die Reduktion der Abweichungen bei Teams, die prognostizieren, länger als bei Teams, die sich verpflichten.
Eine Prognose oder Schätzung ist für den Produktrückstand geeignet. Wenn Teams jedoch Storys aus dem Produktrückstand in den Sprintrückstand verschieben und diese analysieren, fügen sie eine weitere Detailtiefe hinzu. Sie bringen kleine Details in Erfahrung und stellen sich die Frage: "Können wir uns dazu verpflichten?" Das Erstellen von Prognosen birgt das Risiko, wieder in Trägheit zu verfallen und zu sagen "Wir müssen ja nur eine Prognose abgeben, es ist OK, wenn wir etwas auslassen, wir können das alles später regeln".

Etwas humorvoller ausgedrückt, stellen Sie sich doch einmal vor, Sie würden zu Ihrem Ehepartner oder Lebensgefährten sagen: "Ich denke, dass wir zehn Jahre zusammen bleiben". Das käme im Vergleich zu "Ich verspreche dir Treue" wohl nicht so gut an.

Letztendlich hat Scrum mit gesundem Menschenverstand zu tun. Ich schlage vor, dass Sie beide Ansätze – Verpflichtung und Prognose – ausprobieren. Fazit ist: Es geht ums Lernen und nicht um den Begriff. Also seien Sie schlau, experimentieren Sie mit beiden Ansätzen und verwenden Sie den, der für Sie, Ihr Team und Ihr Unternehmen am besten geeignet ist.

Was genau ist die Sprintplanung?

Wir halten eine Sprintplanungsbesprechung ab, um zu planen, was das Team im kommenden Sprint realisiert und wie dies realisiert wird. Zwar sprechen wir von einer Sprintplanungsbesprechung, aber in Wirklichkeit besteht diese Besprechung aus zwei sehr unterschiedlichen Teilen. Im ersten Teil geht es darum, was das Team realisieren soll, und es nehmen sowohl der Produktbesitzer als auch das Team teil. Im zweiten Teils geht es darum, wie das Team plant, die gewünschte Funktionalität zu realisieren. Während das gesamte Team an Teil 2 mitwirken muss, ist die Teilnahme des Produktbesitzers optional. Wenn der Produktbesitzer aus irgendeinem Grund nicht an Teil 2 teilnimmt, sollte er trotzdem für Fragen zur Verfügung stehen.

Im ersten Teil der Sprintplanungsbesprechung erhält der Produktbesitzer die Möglichkeit, dem Team einen gewünschten Satz von Storys zu beschreiben. Hier geht es um die Details des Was-Aspekts in Bezug auf die Storys. Der Produktbesitzer stellt die Storys vor, zeigt, wie verschiedene Elemente miteinander interagieren, und führt die Teilnehmer Schritt für Schritt durch die Schnittstelle. Darüber hinaus werden möglicherweise auch Infrastruktur- oder Architekturelemente erläutert. Ziel ist, den Teammitgliedern kollektiv genügend Informationen zu geben, sodass sie sich überlegen können, wie die Funktionalität realisiert werden kann. Das Team stellt zahlreiche Fragen, um Informationen für den Wie-Aspekt der Besprechung zu sammeln, zum Beispiel:

"Was sind die Akzeptanzkriterien für diese Storys?"
"Welche Datenquellen werden wir Ihrer Meinung nach verwenden?"
"Wie sollte die Schnittstelle für diese Komponente aussehen?"

Im zweiten Teil der Sprintplanungsbesprechung richtet das Team seine Aufmerksamkeit auf das Erstellen des Sprint-Rückstands – der Liste von Storys und Aufgaben, die während des Sprints abgeschlossen werden müssen. Um den Rückstand zu erstellen, analysiert das Team jede vom Produktbesitzer angeforderte Story auf der Aufgabenebene. Jeder Aufgabe wird eine geschätzte Dauer in Stunden zugewiesen. Am Ende von Teil 2 entscheidet das Team, welche Storys es im Rahmen des Sprints verbindlich abschließen kann.

Die beiden Teile der Sprintplanungsbesprechung können insgesamt zwischen zwei und acht Stunden dauern. Im Allgemeinen verwende ich die Faustregel, dass jeder Teil eine Stunde pro Woche Sprintlänge dauern soll. Bei einwöchigen Sprints dauert die Besprechung also insgesamt zwei Stunden (eine Stunde für Teil 1 und eine Stunde für Teil 2). Und bei einer Sprintdauer von vier Wochen dauert die Besprechung insgesamt acht Stunden (vier Stunden für Teil 1 und vier Stunden für Teil 2). Das bedeutet, dass bei einwöchigen Sprints die Besprechung insgesamt zwei Stunden dauert (eine Stunde für Teil 1 und eine Stunde für Teil 2).

Wie gehen wir dabei vor?

Solange sich das Team am Ende der Sprintplanungsbesprechung auf eine Liste von Storys festgelegt hat, wurde der Zweck der Sprintplanung erfüllt. Allerdings bedarf es einem gewissen Grad an Vorplanung und Hilfestellung, um das Team an den Punkt zu bringen, an dem jedes Teammitglied zu dieser Verpflichtung bereit ist.

Der Produktbesitzer hat eine Aufgabe bei der Sprintplanung: Er muss in der Lage sein, bei der Besprechung einen Satz von gewünschten Storys zu beschreiben. Das Team hat das Ziel, die Storys aus Sicht des Produktbesitzers zu verstehen und die Vision des Produktbesitzers zu teilen. Der ScrumMaster sollte sicherstellen, dass das Team genug Fragen stellt und alle resultierenden Daten aufzeichnet, einschließlich Akzeptanzkriterien, Skizzen und Annahmen. Der ScrumMaster sollte außerdem den Produktbesitzer darüber informieren, dass das Team noch weitere Fragen haben kann, wenn es anfängt, Fragen in einzelne Aufgaben zu unterteilen. Zwar präsentiert der Produktbesitzer Storys, deren Punkte insgesamt ungefähr der historischen Geschwindigkeit des Teams entsprechen, aber letztlich entscheidet das Team basierend auf den Erkenntnissen aus Teil 1 und Teil 2 der Sprintplanungsbesprechung, ob es tatsächlich alle Storys in einem Sprint übernehmen kann.

Nachdem das Team alle Informationen vom Produktbesitzer erhalten hat, muss es die Storys in Aufgaben aufgliedern und einen Sprintrückstand erstellen, der alle Storys, Hinweise, Akzeptanzkriterien, Aufgaben und Schätzungen für einen bestimmten Sprint enthält. Dafür gibt es zahlreiche Möglichkeiten, aber ich persönlich setze die folgende Methode ein, die die Ideen aller Teammitglieder berücksichtigt und jedem eine Stimme bei der Aufgabenzerlegung gibt.

Bitten Sie den ScrumMaster oder Besprechungsleiter, eine Story vorzulesen, und fragen Sie dann, ob jeder diese Story verstanden hat. Das sollte der Fall sein, da die Teammitglieder die Storys soeben mit dem Produktbesitzer diskutiert haben. Wenn jemand im Team etwas nicht verstanden hat, gehen Sie die Story noch einmal durch und stellen Sie dem Produktbesitzer alle relevanten Fragen.
Bitten Sie die Teammitglieder als Nächstes, sich einen Block mit Haftzetteln zu nehmen. Fordern Sie jedes Teammitglied auf, eine einzelne Aufgabe auf einen Zettel zu schreiben und diesen in die Tischmitte zu werfen.
- Wenn ein Teammitglied einen Zettel in die Mitte wirft, gibt er oder sie die entsprechende Aufgabe bekannt. Wenn also "gespeicherte Prozedur aktualisieren" aufgeschrieben wurde, wird dies laut ausgesprochen. Dies ist wichtig, da so neue Ideen aufkommen und andere Teammitglieder vielleicht sagen: "Oh ja, außerdem müssen wir noch die Datenquelle aktualisieren". An diesem Punkt schreibt jemand "Datenquelle aktualisieren" auf seinen Zettel, spricht es laut aus, und wirft den Zettel in die Mitte. Mit dieser Brainstormingaktivität kann man sich alle relevanten Aufgaben wirklich gut bewusst machen. Kümmern Sie sich zu diesem Zeitpunkt nicht um Duplikate. Alle Aufgabenzettel in die Mitte zu werfen dauert normalerweise fünf bis zehn Minuten pro Story.
Wenn alle Zettel auf dem Tisch sind, müssen sie sortiert werden. Haften Sie alle an die Wand, treten Sie einen Schritt zurück, und schauen Sie sich die Wand an. Jede Menge Zettel! Suchen Sie als erstes alle Duplikate. Heften Sie alle Zettel übereinander, die doppelt zu sein scheinen. Suchen Sie anschließend nach Aufgaben, die zusammengehören, entweder weil sie sich ähneln oder weil sie voneinander abhängig sind. Wenn beispielsweise zwei Zettel eine ähnliche Beziehung aufweisen, hängen Sie sie zusammen, aber versetzt auf (wie in der folgenden Abbildung gezeigt):

Wenn zwei Aufgaben so eng miteinander verknüpft sind, dass sie fast identisch sind, überlappen Sie sie fast ganz (siehe unten):

Durch das Sortieren der Zettel kann das Team die Liste der Aufgaben reduzieren und die Beziehungen zwischen den verbleibenden Aufgaben visuell darstellen.
Wenn die Aufgaben sortiert sind, ist es Zeit für die Schätzung. Ich verwende die Planungspoker-Technik für die Schätzung von Aufgaben, allerdings mit folgendem Unterschied: Die Zahlen auf den Karten stellen Stunden und keine Punkte dar. Der Grund für diese Methode ist, dass Leute sich in Bezug auf Stunden zu sehr in unnötigen Details verlieren, insbesondere bei großen Aufgaben. Es gibt einen triftigen Grund für diese Zaghaftigkeit. Zu häufig verwenden Unternehmen Schätzungen als Knüppel gegen das Team: "Sie haben gesagt, es würde 8 Stunden dauern, stattdessen hat es 12 gedauert. Was ist schiefgelaufen?" oder "Sie haben gesagt, es würde 8 Stunden dauern, aber es waren nur 4. Ihre Schätzungen sind zu hoch."

Ähnlich wie Karten dabei helfen, Story Point-Schätzungen abstrakt zu halten, kann sich das Team bei der Verwendung von Karten für die Aufgabenschätzung die Freiheit zunutze machen, aus einer Gruppe vorgegebener Zahlen auswählen zu können und gleichzeitig sicherzustellen, dass letztendlich eine Auswahl getroffen wird. Außerdem beugt dies hitzigen Diskussionen darüber vor, ob eine Aufgabendauer auf 6 Stunden, 6,5 Stunden oder 7 Stunden geschätzt werden sollte.

Wie immer die endgültige Schätzung aussehen mag, wichtig ist, dass die Schätzung vom Team vorgenommen wird und dem Team einfach dabei helfen soll, Selbstvertrauen aufzubauen und zu ermitteln, ob die vom Produktbesitzer geforderten Aufgaben in Bezug auf die Geschwindigkeit durchführbar sind. Aufgabenschätzungen sind keine Metriken und sollten nicht als solche eingesetzt werden. Verwenden Sie Schätzungen niemals als Waffe gegen das Team.
Nun da die Aufgaben geschätzt wurden, muss das Team bestimmen, ob es Kapazitäten für weitere Arbeit hat. Dazu müssen Sie die Kapazität des Teams kennen, also die Gesamtstundenzahl, die dem Team während des Sprints zur Verfügung steht. Das Ermitteln der Kapazität ist einfach, wenn Sie ein fest zugeordnetes Team haben. Aber bei einem Team aus Teilzeitmitarbeitern, die an verschiedenen Projekten arbeiten, ist die Sache schon schwieriger. Bitten Sie jedes Teammitglied, die Anzahl von Stunden zu notieren, die er oder sie pro Tag am Projekt mitarbeiten kann (oder eine Gesamtzahl für den Sprint). Addieren Sie alle Zahlen, so erhalten Sie die Gesamtzahl an verfügbaren Stunden für das Team. Sagen wir einmal, die Kapazität des Teams beläuft sich auf 200 Stunden. Wenn die Aufgabendauer für eine Story insgesamt auf 30 Stunden geschätzt wird, fragen Sie das Team: "Können wir noch mehr Arbeit annehmen?" Zu diesem frühen Zeitpunkt lautet die Antwort natürlich "Ja".

Da mehr Kapazität besteht, gehen Sie zur nächsten Story über und wiederholen die Schritte eins bis fünf.

(Weitere Informationen zur Verwendung von Team Foundation Server für diese Aufgabe finden Sie unter Zusammenarbeit [umgeleitet].)

Sie werden an einen Punkt kommen, an dem die Beantwortung der Frage "Können wir noch mehr Arbeit annehmen?" schwierig wird. Dies liegt daran, dass Sie sich der Kapazitätsgrenze des Teams nähern. Berücksichtigen Sie bei diesem Prozess, dass Sie die Kapazität für diesen Sprint nicht bis an die Grenzen ausschöpfen sollten. Wenn Sie ein Glas bis zum Rand mit Wasser füllen, ist die Wahrscheinlichkeit sehr hoch, dass etwas überläuft. Dasselbe gilt für Sprints. Wenn die geschätzten Stunden die gesamte verfügbare Zeit ausfüllen und später im Sprint eine neue Aufgabe identifiziert wird, kommt es zum Überlaufen. Sie müssen Platz für unvorhergesehene Aufgaben lassen.

Beim Prüfen der Sprintverpflichtung hilft es, historische Daten aus den letzten Sprints zu berücksichtigen. Muss das Team konsistent weitere Arbeit suchen? Vielleicht könnte sich das Team während der Sprintplanung zu mehr Arbeit verpflichten. Ist das Team konsistent nicht in der Lage, die gesamte Arbeit für einen Sprint fertig zu stellen? Möglicherweise muss das Team in Bezug auf seine Verpflichtungen vorsichtiger sein, bis die zugrunde liegende Ursache der nicht abgeschlossenen Sprints beseitigt worden ist.

Um der Frage, wie voll man das Glas füllen sollte, eine Zahl zuzuordnen, können Sie sich zum Beispiel die Zunahme der Plangröße ansehen. Die Zunahme der Plangröße misst die tatsächlich aufgewendeten Arbeitsstunden im Vergleich zur ursprünglichen Schätzung. Nehmen wir beispielsweise an, dass das Team eine Kapazität von 200 verfügbaren Stunden hat. Die Team verpflichtet sich auf der Grundlage von Schätzungen zu 190 Stunden. Am Ende des Sprints berechnet das Team, dass sich der Arbeitsaufwand für diese Storys tatsächlich auf 240 Stunden belief, wodurch sich eine Zunahme der Plangröße von 20 % ergibt.

Bei einer derartigen Diskrepanz sollte ein Team sich während der Nachbetrachtung mit den Gründen auseinandersetzen:

Werden während der Ausführung zu viele Aufgaben ermittelt, die bei der Planung nicht identifiziert wurden?
Unterschätzt das Team die Aufgaben in Anbetracht der verfügbaren Kompetenzen?
Hat das Team seine Kapazität überschätzt?
Und so weiter.

Das Team sollte die Zunahme der Plangröße auch bei der nächsten Sprintplanungsbesprechung berücksichtigen, wenn es ermittelt, ob es sich auf eine Story festlegen kann. Zurück zu unserem Beispiel: Wenn das Team immer noch von einer geschätzten Kapazität von 200 Stunden ausgeht, sollte es 20 % abziehen, um basierend auf den historischen Daten der "erwarteten" Plangrößenzunahme entgegenzuwirken. Das heißt zumindest für diesen Sprint, dass das Team von einer maximalen Kapazität von 160 Stunden ausgehen sollte, um ein Überlaufen zu verhindern.

Die Berücksichtigung der Plangrößenzunahme ist eine Möglichkeit, die Sprintauslastung zu bestimmen. Aber bedenken Sie, dass es darum geht, die Kapazität nicht voll auszulasten. Stattdessen soll das Team zuversichtlich sein, wenn es sich auf eine entsprechende Anzahl von Storys festlegt – eine Zahl, die das Team fordert, ohne es zu überlasten. Die Zunahme der Plangröße hilft einfach dabei zu bestimmen, wie hoch die Auslastung des nächsten Sprints sein sollte, wenn alle anderen Faktoren gleich sind.

Wenn die Schätzung für alle Storys abgeschlossen ist oder die gesamte Zeit durch Storys belegt wurde, teilen Sie dem Produktbesitzer den Sprintrückstand mit, zu dem sich das Team verpflichtet hat. Nun fängt der Sprint an, also an die Arbeit!

Häufige Probleme

In meiner Tätigkeit als Berater von Teams in Bezug auf die Umsetzung von Scrum habe ich im Laufe der Jahre immer wieder gesehen, wie dieselbe Art von Problemen eine erfolgreiche Sprintplanung verhindern. Obwohl die Sprintplanung auf den ersten Blick einfach scheint, haben Teams am Anfang oft mit Scrum zu kämpfen. In diesem Abschnitt sind viele dieser Probleme und die möglichen Lösungen beschrieben.

Szenario: Das Team kann sich nicht auf alle vom Produktbesitzer gewünschten Storys festlegen.

Sie sollten davon ausgehen, dass so etwas gelegentlich passiert. Solange das Team seine Verpflichtung mit Daten aus den Schritten vier und fünf weiter vorne in diesem Thema substantiieren kann, sollte der Produktbesitzer zufrieden sein. Sie sollten darauf achten, dass dieses Verfehlen der Verpflichtung nicht das Ergebnis einer zu hohen Schätzung oder großer Aufgaben ist. Der ScrumMaster sollte zu konservativ scheinende Schätzungen hinterfragen, um sicherzustellen, dass die Schätzungen stimmen. Der Produktbesitzer sollte jede Aufgabe näher überprüfen, für die eine Schätzung in zweistelliger Höhe angesetzt wurde. Jede Aufgabe, die laut Schätzung länger als zwei Werktage dauert, sollte in kleinere Aufgaben aufgegliedert und neu geschätzt werden. Dies gilt für alle Projekte, ist jedoch besonders relevant für Teams, die an ein- oder zweiwöchigen Sprints arbeiten.

Szenario: Der Produktbesitzer hat sich nicht vorbereitet.

Einer der Scrum-Werte ist Respekt. Es ist respektlos, unvorbereitet zu einer Besprechung zu kommen. Was sollte ein Team also tun, wenn der Produktbesitzer ohne die vom Team benötigten Informationen kommt? Eine Option ist natürlich, die Besprechung zu verschieben bis der Produktbesitzer bereit ist, aber das fördert dieses Verhalten nur. Vermeiden Sie also diesen Weg. Eine andere Möglichkeit besteht darin, den Sprint abzubrechen. Das kann zwar funktionieren, ist aber extrem.

Meiner Erfahrung nach funktioniert ein kombinierter Ansatz am besten. Zunächst einmal sollte der Produktrückstand nach Prioritäten sortiert sein. Denn wenn der Produktbesitzer keinen bestimmten Satz von Storys hat, kann das Team mit dem Produktbesitzer über die Storys in der Reihenfolge ihrer Priorität diskutieren, bis alle an einen Punkt gelangen, an dem sie meinen, ihre Kapazität erreicht oder überschritten zu haben. Das Team kann sich dann wie üblich im zweiten Teil der Besprechung für die genaue Verpflichtung entscheiden.

Nach der Besprechung muss der ScrumMaster versuchen, zu verstehen, warum der Produktbesitzer unvorbereitet war. Wenn das Problem mangelndes Engagement war, kann der ScrumMaster den Produktbesitzer darüber aufklären, wie wichtig es ist, mit einem vorbereiteten Satz von Storys zur Besprechung zu kommen. Und wenn das Problem darin bestand, dass der Produktbesitzer sich nicht vorbereiten konnte, vielleicht weil das Team bei der Bereinigung keine Unterstützung geleistet hat, sollte der ScrumMaster ebenfalls bei der Problemlösung helfen.

Szenario: Teil 1 überschreitet den Zeitrahmen.

Ein weiterer Wert ist Fokus. Wenn Teil 1 der Besprechung zu lange dauert, ist dies ein Symptom für mangelnden Fokus. Manchmal ist der Produktbesitzer aufgrund fehlender Vorbereitung oder Priorisierung nicht bei der Sache, oder vielleicht versucht er, zu viele Storys zu erläutern. Zu anderer Zeit beruht der Mangel an Fokus vielleicht darauf, dass die Teamdiskussion vom "was" zu den Einzelheiten des "wie" entgleist.

Der ScrumMaster sollte helfen, die Diskussion zu beschleunigen, indem er darauf besteht, dass der Produktbesitzer alle Storys, die nicht vollständig erklärt werden können, vorgibt, und dass das Team in Teil 1 der Besprechung keine ausführlichen Implementierungsdiskussionen führt. Eine einfache Lösung für sich im Kreis drehende Diskussionen ist der Einsatz einer Stoppuhr oder eines Zeitgebers.

Szenario: Teil 2 überschreitet den Zeitrahmen.

Auch hier geht es wieder um den Fokus. Wenn Ihr ein Team viel redet, ist manchmal einfach nur die Disziplin nötig, alle Diskussionen einzuschränken, um die Besprechung wieder auf den Punkt zu bringen. Bringen Sie eine Eieruhr zur Besprechung, und begrenzen Sie die Unterhaltungen zwischen zwei Aufgabenschätzungen auf eine oder zwei Minuten. Das Ziel ist Genauigkeit, aber keine 100-prozentige Präzision.

Mangelnder Fokus beim zweiten Teil der Besprechung kann auch ein Symptom dafür sein, dass der Produktrückstand während der Sprintausführung nicht entsprechend bereinigt wurde. Bei der Bereinigung kann sich das Team zukünftige Storys ansehen und zusammen mit dem Produktbesitzer Storys oder Spitzen hinzufügen, um Entwurfsrichtungen festzulegen oder Architekturfragen zu beantworten. Ohne eine regelmäßige Produktrückstandsbereinigung wird die Sprintrückstandsplanung schwerfällig und qualvoll.

Szenario: Der Produktbesitzer ist nicht verfügbar.

Wenn der Produktbesitzer aus irgendeinem Grund nicht an der Besprechung teilnehmen kann und keinen Vertreter bestimmt hat, sollten Sie so tun, als ob der Produktbesitzer unvorbereitet zur Besprechung gekommen wäre. Arbeiten Sie wichtigsten Elemente durch, und legen Sie sich so gut es geht fest. Möglicherweise sind Sie versucht, den Besprechungstermin umzulegen und an den Terminkalender des Produktbesitzers anzupassen. Tun Sie das nicht. Die Besprechung zu verschieben bedeutet, die Bedürfnisses eines Einzelnen zu Lasten vieler anderer zu befriedigen. Das ist die Sache nicht wert.

Szenario: Das Team verfügt nicht über die erforderlichen Akzeptanzkriterien.

Ich rate Teams immer, den Produktbesitzer in Teil 1 nach den Akzeptanzkriterien zu fragen oder die Frage zu stellen "Was müssen wir tun, damit Sie unsere Arbeit akzeptieren?" Fehlt diese Angabe in Teil 2, wenn das Team die Aufgaben bestimmt, dann weiß das Team nicht, wie eine Story abzuschließen ist. Wenn das Team basierend auf dem, was es in Teil 1 gehört hat, raten muss, läuft es Gefahr, dass der Produktbesitzer am Ende des Sprints entscheidet, dass die Story nicht abgeschlossen sei. Fragen Sie für jede Story von Anfang an nach Akzeptanzkriterien. ScrumMaster – Sorgen Sie dafür, dass Produktbesitzer diese Daten bereitstellen.

Szenario: Der Produktbesitzer weiß nicht, was "abgeschlossen" genau bedeutet.

Ebenso wie das Team Akzeptanzkriterien braucht, verdient der Produktbesitzer eine aktuelle Erläuterung dazu, was sich das Team unter einer abgeschlossenen Story vorstellt. Diese Liste zum Thema "Abgeschlossen" sollte leicht zu finden und auf dem aktuellen Stand sein und dem Produktbesitzer jederzeit zur Verfügung stehen. Eine veraltete Liste erschwert die Planung, da es dann keine Verständigung darüber gibt, was "abgeschlossen" bedeutet. Stellen Sie sicher, dass eine aktualisierte "Fertig"-Liste Teil jeder Sprintüberprüfung oder -nachbereitung ist.

Szenario: Der ScrumMaster oder der Produktbesitzer nimmt die Schätzung vor bzw. beeinflusst die Schätzungen/Arbeit des Teams.

Der Produktbesitzer ist beim zweiten Teil der Besprechung willkommen, aber seine Rolle sollte sich dabei auf die Klärung von Anforderungen oder die Beantwortung bestimmter Fragen beschränken. Der Produktbesitzer sollte nie in die Teamdiskussion über die Art der Implementierung einer Story eingreifen, und er besitzt kein Mitspracherecht in Bezug auf die Aufgabenschätzung. Der Produktbesitzer muss dem Team vertrauen, dass es seine Arbeit erledigt.

Falls sich der Produktbesitzer nicht an diese Richtlinien hält, sollte der ScrumMaster den Produktbesitzer darauf hinweisen, wie seine Rolle aussehen sollte. Wenn der Produktbesitzer eine passivere Rolle ablehnt, kann der ScrumMaster ihn auffordern, die Besprechung zu verlassen.

Sprintplanung muss nicht schwierig sein. Sie kann Spaß machen und hilft dem Scrumteam, Teamgeist zu entwickeln, indem gemeinsam die Frage beantwortet wird "Wozu können wir uns verpflichten?" Und denken Sie daran: Besprechungen, die tendenziell zu lange dauern, liegen wahrscheinlich Kernprobleme zugrunde. Als ScrumMaster können Sie die Besprechung beim Thema halten, indem Sie sicherstellen, dass der Produktbesitzer und das Team den Produktrückstand bereinigen. Helfen Sie dem Produktbesitzer dabei, vorbereitet zur Besprechung zu kommen, indem Sie vor der Besprechung Storyakzeptanzkriterien bereit haben. Und unterstützen Sie den Produktbesitzer und das Team dabei, sich auf die vorliegende Aufgabe zu konzentrieren, also zu bestimmen, wofür sie sich bei diesem Sprint verpflichten können.