Wir haben eine schwachsinnige Geschichte, die für die Entwicklung abgeschlossen war, aber während des Testens ein Problem aufgedeckt hat. Bei der Untersuchung des Problems wurde festgestellt, dass eine externe Partei eine Lösung bereitstellen muss. Die externe Partei wird diesen Fix nicht vor dem Ende des Sprints bereitstellen. Unsere Story ist daher blockiert, bis die externe Partei ihren Fix liefert.
Mit dem erforderlichen Drittanbieter-Fix haben Sie jetzt effektiv eine Vorbedingung für Ihre Geschichte (von der Sie annahmen, dass sie von Anfang an vorhanden wäre, aber sich herausstellte, dass dies nicht der Fall war).
Sie sollten die Story am Ende des Sprints wieder in das Backlog stellen. Es ist nicht fertig. Ob Sie es in einen nächsten Sprint stecken, hängt von den Regeln Ihres Teams ab, aber ich würde es nicht tun, es sei denn, die Vorbedingung wird vor dem Start des Sprints überprüft und validiert .
Ein Sprint sollte mit Items gefüllt werden, damit das Team glaubt, diese Menge am Ende des Sprints liefern zu können. Wenn unklar ist, ob eine Vorbedingung während des Sprints erfüllt werden kann, sollte dies nicht einmal ein Thema im Planungsmeeting sein, außer zu sagen „Vorbedingungen nicht vorhanden? Okay, WEITER“. Ein Sprint sollte nur mit Elementen gefüllt werden, die das Team liefern kann.
Ausnahmen können wie immer gelten. Ein neuer Backlog-Eintrag für den nächsten Sprint könnte lauten: „Prüfen Sie, ob der Fehler in der Version 1.2.3, die am Dienstag herauskommt, immer noch nicht behoben ist“. Das ist möglich, auch wenn das „erledigt“-Ergebnis der Story lauten könnte „es ist immer noch fehlerhaft, wir können im nächsten Sprint nicht mit der ursprünglichen Story fortfahren“.
Dies ist eine großartige Frage und Gelegenheit zu lernen! Ja, fügen Sie die blockierte Story in das Product Backlog ein, wenn Sie einen ähnlich großen Ersatz haben, und diskutieren Sie bei der nächsten Retrospektive :
Was sagt dies über unsere Schätzung und Definition von Ready aus ?
Wenn diese Story vor dem Ende des Sprints entsperrt wird, kann und/oder sollte sie vor der Ersatz-Story abgeschlossen werden?
Außerdem können Sie mit Kanban eine „blockierte Box“ in jede WIP-Spalte einfügen (der blockierte Artikel sollte nicht zu Ihren WIP-Nummern zählen) und diese Story wäre automatisch der Artikel mit der höchsten Priorität, wenn er entsperrt wird.
Ich würde auch behaupten, dass so etwas irgendwie vom Team als "extern verzögert" verfolgt werden sollte. (Unabhängig vom „Scrum-Namen“ für diesen Begriff.) Jedes Mal (!), wenn das Team seinen nächsten „Sprint“ plant, sollte es den Status all dieser Elemente explizit überprüfen, um die Aufmerksamkeit des Managements darauf zu lenken Angelegenheit (und zu den projektweiten Implikationen davon). Erwähnen Sie es nicht nur „beiläufig“ in Ihrem Projektbericht – für jemand anderen, dies ist ein Aktionspunkt .
Das Management muss wissen – und zwar rechtzeitig –, dass so etwas passiert, und besonders, wenn es wiederholt passiert. Betrachten Sie es als die Pflicht Ihres Teams, sie zu benachrichtigen und auf dem Laufenden zu halten.
"Hier ist der Grund."
Diese stellen aus meiner Sicht funktionale Abhängigkeiten dar, die zwischen „dem Projekt, an dem Ihr Team arbeitet“ und „anderen Projekten, mit denen Sie nichts zu tun haben“, bestehen. Diese bestimmen den „kritischen Pfad“ auf Organisations- oder sogar Unternehmensebene . Sie könnten leicht Bereitstellungs- und/oder Betriebsprobleme darstellen, wenn Ihr Projekt „live“ geht. Diese sind zwar nicht per se „Ihr Anliegen“, müssen aber sowohl innerhalb Ihres Projektes als auch [weit?] darüber hinaus explizit erkannt und nachverfolgt werden.
Todd A. Jacobs