Was soll der Scrum Master tun, wenn die Timebox des Events bereits abgelaufen ist, das Ziel aber noch nicht erreicht ist?
Dieses Zitat hat mich zu dieser Frage veranlasst:
Was tun wir also, wenn sich das terminierte Sprint-Planungsmeeting dem Ende nähert und es keine Anzeichen für ein Sprint-Ziel oder einen Sprint-Rückstand gibt? Sollen wir es einfach abkürzen??? Oder verlängern wir es um eine Stunde? Oder beenden wir das Meeting und setzen es am nächsten Tag fort?
Das passiert immer wieder, besonders bei neuen Teams. Also, was machst du? Ich weiß nicht. Aber was tun wir? Oh, ähm, na ja, normalerweise breche ich das Treffen brutal ab. Beende es. Lass den Sprint leiden. Genauer gesagt sage ich dem Team und dem Product Owner: „Also, dieses Meeting endet in 10 Minuten. Wir haben nicht wirklich einen Sprintplan. Sollen wir uns mit dem begnügen, was wir haben, oder sollten wir morgen ab 8 Uhr ein weiteres 4-stündiges Sprint-Planungsmeeting ansetzen?“. Sie können sich denken, was sie antworten werden ... :o)
Ich habe versucht, das Meeting in die Länge zu ziehen. Das bringt meistens nichts, weil die Leute müde sind. Wenn sie in 2 – 8 Stunden (oder wie lang Ihre Timebox auch sein mag) keinen anständigen Sprintplan erstellt haben, werden sie es wahrscheinlich in einer weiteren Stunde nicht schaffen. Die nächste Option ist eigentlich ganz in Ordnung, am nächsten Tag ein neues Meeting zu planen. Abgesehen davon, dass die Leute normalerweise ungeduldig sind und mit dem Sprint loslegen wollen, und nicht noch ein paar Stunden mit der Planung verbringen.
Also habe ich es kurz geschnitten. Und ja, der Sprint leidet. Der Vorteil ist jedoch, dass das Team eine sehr wertvolle Lektion gelernt hat und das nächste Sprint-Planungsmeeting viel effizienter sein wird. Darüber hinaus werden die Leute weniger Widerstand leisten, wenn Sie eine Besprechungslänge vorschlagen, die sie zuvor für zu lang gehalten hätten.
Scrum und XP aus den Schützengräben. Wie wir Scrum machen. Von Henrik Kniberg.
In Wirklichkeit gibt es meiner Meinung nach nur zwei mögliche Lösungen: Dem Ereignis etwas Zeit hinzufügen oder es einfach unterbrechen.
Dies sind meine Ideen und das, was ich in meiner Praxis gemacht habe (meine Lösungen können falsch sein, deshalb habe ich diese Frage gestellt):
Tägliches Scrum. Eigentlich hatte ich nie Probleme mit dem Timebox-Limit von Daily Scrum. Aber ich habe nichts dagegen, diese Veranstaltung nach 15 Minuten zu unterbrechen.
Sprint-Planung. Alles, was Henrik Kniberg geschrieben hat, macht Sinn. Aber in meiner Praxis füge ich immer nur etwas zusätzliche Zeit hinzu. Dieses Problem trat in meiner Praxis sehr selten auf (ist aber trotzdem vorgekommen). Dies geschah zu Beginn von Projekten, wenn das Product Backlog noch nicht gut ausgearbeitet war. Viel öfter verbringen wir viel weniger Zeit als der Scrum Guide vorschreibt (was vielleicht auch nicht gut ist, aber das ist eine andere Frage).
Sprint-Review. Dieses Problem tritt bei mir beim Sprint Review häufiger auf als beim Sprint Planning. Unterbrechen und am nächsten Tag eine neue Sitzung machen? Nein danke. Es wird schmerzhaft sein, alle Beteiligten an einem ungewöhnlichen Tag zu versammeln. Machen Sie überhaupt keine neue Sitzung? Es kann dem nächsten Sprint schaden. Also habe ich immer etwas zusätzliche Zeit hinzugefügt, wenn die Zeitbox nicht ausreicht. Wenn es nicht die richtige Entscheidung ist, korrigieren Sie mich bitte.
Sprint-Retrospektive. Wie im Fall von Daily Scrum habe ich nichts dagegen, dieses Event zu unterbrechen, wenn die Timebox abgelaufen ist.
Über die Verfeinerung des Product Backlogs: In Wirklichkeit habe ich nie genau berechnet, wie viel Prozent der Kapazität dafür benötigt wurden. Aber ich denke, es ist nichts Schlimmes daran, dass es mehr als 10 Prozent sind, besonders zu Beginn des Projekts.
Der Zweck des Timeboxings in Scrum besteht darin, als Alarm für das Scrum-Team zu fungieren. Wenn die Timeboxen regelmäßig überschritten werden, gibt es ein Problem, das angegangen werden muss.
Als Scrum Master würde ich das in dieser Situation tun.
Beim Daily Scrum würde ich das Meeting nicht nach 15 Minuten unterbrechen. Stattdessen würde ich versuchen, einzelne Teammitglieder zu unterbrechen, die zu lange über Themen sprechen, die außerhalb des Rahmens des Daily Scrum liegen. Eine Regel, die ich im Allgemeinen verwende, lautet: Wenn ein technisches Gespräch im Daily Scrum länger als 40-60 Sekunden dauert, würde ich vorschlagen, dass es offline und außerhalb des Daily Scrum geführt wird.
Bei der Sprint-Planung ist ein langes Meeting ein starker Hinweis darauf, dass nicht genug Backlog-Verfeinerung durchgeführt wird. Scrum schlägt vor, dass 10 Prozent der Zeit in einem Sprint darauf verwendet werden, den nächsten Sprint vorzubereiten, aber das ist nur ein Vorschlag. Bei einigen Teams wird es weniger sein, bei anderen mehr. Eigentlich sollte die Zeit, die für die Verfeinerung des Rückstands aufgewendet wird, so lange steigen, bis es keinen Nutzen mehr bringt, wenn man sie weiter erhöht.
Ein weiterer wichtiger Punkt bei Sprint Planning Meetings ist, dass nicht alles im Sprint exakt geplant werden muss. Das Scrum-Team sollte entscheiden, was im Sprint vor sich geht, und dann eine begrenzte Zeit damit verbringen, zu diskutieren, wie es diese Arbeit liefern wird. Das Wichtigste ist, nach dem Planungsmeeting genug Verständnis für das Team zu haben, um den Sprint zu starten. Es ist nicht notwendig, den gesamten Sprint im Detail zu planen, da es genügend Gelegenheit für das Team gibt, sich wieder zu treffen, um dieses Detail während des Sprints selbst zu besprechen.
Für den Scrum Master ist es also ganz natürlich, das Sprint Planning zu unterbrechen. Ich sage dem Team oft: „Wir haben genug Planung, um anzufangen. Lasst uns den Sprint starten und uns nach ein paar Tagen wieder treffen, wenn wir besprechen müssen, was in diesem Meeting nicht behandelt wurde.“
Beim Sprint Review geht es darum, Feedback von den Stakeholdern einzuholen. Das Feedback vom Product Owner sollte während des Sprints selbst eingeholt worden sein, sodass der Product Owner beim Sprint Review nur wenige oder gar keine Fragen zu stellen hat. Feedback von den Stakeholdern ist per Definition unbefristet. Daher ist es wichtig, dass der Scrum Master und der Product Owner die Stakeholder darüber aufklären, dass sie nur eine begrenzte Zeit haben, um während des Sprint-Review-Meetings Feedback zu geben. Das ist wiederum eine Situation, in der der Scrum Master eingreifen und unterbrechen könnte. Vielleicht schlagen Sie vor, dass sich der Product Owner und die Stakeholder später wieder treffen, wenn weitere Diskussionen über Anforderungen anstehen.
Sprint-Retrospektiven können die Zeitbox leicht überschreiten. Der Scrum Master muss die Struktur des Meetings nutzen, um dies zu vermeiden. Zum Beispiel werde ich oft eine Sprint-Retrospektive wie diese durchführen:
Die ersten 10 Minuten – Teammitglieder schreiben ihr Feedback auf Haftnotizen. In den nächsten 15 Minuten liest der Scrum Master die Notizen mit dem Team durch und versucht, einen (oder möglicherweise zwei) Bereiche zu identifizieren, auf die er sich konzentrieren muss. Letzte 30 Minuten – diskutieren Sie eine mögliche Verbesserung und vereinbaren Sie, sie in den nächsten Sprint einzubringen. Wenn die Verbesserung sehr komplex ist, könnte ich vorschlagen, dass sie als Aufgabe in das Backlog aufgenommen wird. Das kann dann angepasst und formal in einen Sprint eingebracht werden, wenn es angebracht ist. Es wäre nicht notwendig, alle Probleme vollständig zu lösen. Nur um festzustellen, woran gearbeitet werden soll.
„Was soll Scrum-Master tun, wenn dieses Problem (Time-Box abgelaufen, aber Ziel noch nicht erreicht) bereits aufgetreten ist?“
Lassen Sie das Team den Schmerz spüren, damit es sich bewusst wird, dass es wirklich ein Problem gibt. Bewusstsein ist immer der erste Schritt. Menschen haben eine dickere Haut, als Sie möchten oder wissen. Aber ... Sie kennen Ihr Team am besten, also beurteilen Sie, welche Aktion den Schmerz verursacht und am schnellsten den Wunsch weckt, dass das Team diesen Schmerz löst.
Reagieren sie am meisten (fühlen den Schmerz), wenn Sie am nächsten Tag etwas planen? Dann scheuen Sie sich nicht; Planen Sie am nächsten Tag ein Follow-up und behalten Sie sie dort, bis die Arbeit erledigt ist oder bis sie kurz davor stehen, unproduktiv oder demoral zu werden. Fragen Sie sie anschließend, ob es ihnen gefallen hat und welche Ideen sie haben, um die Situation in Zukunft zu vermeiden. Sie müssen nicht auf eine Retrospektive warten, um Änderungen zu besprechen. Sie befähigen das Team, sein Problem zu lösen, solange es noch frisch im Gedächtnis ist. Halten Sie sie dann an ihren Lösungsvorschlägen fest. Spülen und bei Bedarf wiederholen.
Wenn Sie schließlich dem Scrum-Framework folgen, um Scrum zu folgen, hören Sie auf, agil zu sein.