Angenommen, das Produkt-Backlog hat 90 Storys und etwa 30 Storys, die einen Teil der Funktionalität der Anwendung ausmachen, die während früherer Sprints entwickelt und bereitgestellt wurde. Der PO entscheidet sich dafür, diese gelieferte Funktionalität freizugeben und in Produktion zu nehmen.
Aktuell bin ich bei Sprint 6 und die Sprintdauer beträgt 3 Wochen. Der Sprint hat mit etwa 5 Stories als Sprint-Backlog-Items begonnen und inzwischen ist eine Woche des Sprints vergangen.
Jetzt entdeckt der PO einen Produktionsfehler oder eine wichtige Funktionalität, die der Produktionsanwendung mit höchster Priorität hinzugefügt werden muss. Die Schätzung für diesen Fix oder diese Funktionalität sind nur wenige Story Points, die basierend auf der Geschwindigkeit des Teams in wenigen Stunden bereitgestellt werden können.
Hoffentlich sehen Sie jetzt die Situation, in der sich die PO befindet. Selbst wenn das Entwicklungsteam (da nur DT das Sprint-Backlog ändern kann, nicht die PO) bereit ist, diesen Fix/diese Funktionalität in das Sprint-Backlog aufzunehmen, wird die Lieferung dauern weitere 2 Wochen (da nur eine Woche der 3 Wochen Sprint vergangen ist) und die PO kann nicht so lange warten.
Was kann die PO in dieser Situation tun?
1) Kann er einen weiteren neuen Sprint initiieren, der nur wenige Stunden oder höchstens einen Tag dauert (ich möchte dies Mikrosprints nennen). Hier also ein Teil der Frage: Können Sprints einige Stunden oder höchstens ein oder zwei Tage dauern? (Nach allem, was ich irgendwo gelesen habe, beträgt die kürzeste Sprintdauer, die ich gelesen oder gehört habe, 1 Woche.) Ich habe also diese Zweifel, ob es möglich ist, kurze Sprints von wenigen Stunden oder einem Tag zu haben, und ob sie in Scrum gültig und akzeptabel sind .
2) Was schlagen Sie vor, wie die Bestellung mit dieser dringenden Lösung/Funktionalität von höchster Priorität umgehen sollte, die sofort geliefert werden muss.
Hinweis: Alles am Projekt sollte nur durch einen formellen Scrum-Prozess erledigt werden.
Tolle Antworten oben.
Aber ich füge hinzu ... Nehmen Sie sich etwas Zeit mit dem PO & DT, um Fehlerbehebungen in der Produktion zu besprechen, und versuchen Sie, eine Richtlinie zu erstellen, damit Ihr Team ein besseres Verständnis von Scrum Vs Emergency Fixes hat.
Normalerweise wenden Teams eine … „Wenn es so wichtig ist … Fix it, deploy it, return to Sprint Tasks“-Methodik an.
Achten Sie dann auf die schleichende Änderung von PO als Notfälle, wenn es sich in Wirklichkeit nur um verfehlte Anforderungen handelt.
Viel Glück!
Scrum ist ein Vehikel, um schneller und bequemer ans Ziel zu kommen. Kein Club, um sich gegenseitig über den Kopf zu schlagen ...
Nichts in Scrum hindert Sie daran, den Umfang dieses Sprints neu zu verhandeln oder während des Sprints eine neue Version zu veröffentlichen. SCRUM sagt nur, dass Sprints kurz genug sein sollten, dass so etwas normalerweise nicht notwendig ist (dh der PO kann auf alles, was kommt, auf den nächsten Sprint warten). Aber der springende Punkt bei Agilität ist, dass man sich an veränderte Umstände anpassen kann. Auch sagt Scrum nicht, dass man nur am Ende des Sprints liefern kann, sondern dass man am Ende des Sprints loslassen können soll .
Wenn die Auswirkungen des Fehlers oder der fehlenden Funktionalität so groß sind, wie in der Bestellung angegeben, sollten Sie dies sofort angehen und innerhalb des Sprints eine neue Version veröffentlichen. Sie sollten Ihre nächste Retrospektive auch nutzen, um zu thematisieren, wie es möglich war, diese Ausgabe zu verpassen.
Individuen und Interaktionen über Prozesse und Tools
Funktionierende Software über umfassende Dokumentation
Kundenzusammenarbeit über Vertragsverhandlungen
Auf Veränderungen reagieren, anstatt einem Plan zu folgen
Ich habe gesehen, wie Leute ihrem Kanban-Board eine Rettungsgasse hinzugefügt haben – und diese Tickets haben Vorrang.
Dies verhindert, dass das Kanban-Konzept gebrochen wird – aber, wie Kempeth bereits so eloquent geantwortet hat, gibt es Projektmanagement-Tools, um den Lieferprozess zu erleichtern (und hoffentlich zu beschleunigen), in der ultimativen Hoffnung, das Unternehmen reich zu machen. :-)
Es ist dumm, PjM als unveränderliche Regeln zu behandeln, obwohl Sie aufpassen müssen, dass Sie nicht eine endlose Liste von „ Notfällen “ haben, die das gesamte Konzept zerstören.
Ich würde sagen, es gibt ein paar verschiedene Dinge, die angesprochen werden müssen.
Anders sieht es aus, wenn es sich um einen Bug oder eine fehlende Funktionalität handelt. Wenn es sich um einen Fehler handelt, schauen Sie sich den Umfang und die möglichen Auswirkungen genau an. Der Product Owner sollte in der Lage sein, wirklich mit gesundem Menschenverstand zu entscheiden, ob dies etwas ist, das bis zum nächsten Sprint warten kann. Normalerweise kann es. Und wenn nicht, sollte der Ansatz wahrscheinlich sein: Korrigieren Sie es, gehen Sie zurück zum Sprint und berücksichtigen Sie dies, wenn das Scrum-Team diesen Sprint in der Retrospektive inspiziert und darüber spricht, wie es verbessert werden kann, damit dies in Zukunft nicht mehr oft passiert . Zum Beispiel: Hatte das Team eine Definition of Done? Hat die bereitgestellte Entwicklung die „Definition of Done“-„Checkliste“ bestanden?
Wenn es sich um eine fehlende Funktionalität handelt, verhandeln Sie mit dem Entwicklungsteam. Es ist wichtig, den Umfang eines Sprints nicht zu ändern, weil Sie Ihr Sprint-Ziel beeinflussen. Wenn es nur ein paar Stunden Arbeit sind, können sie sich wahrscheinlich darauf einigen, daran zu arbeiten. Aber sprechen Sie in der Retrospektive noch einmal darüber und versuchen Sie zu analysieren, warum eine Funktionalität, die scheinbar eine fehlende Anforderung ist, plötzlich so dringend auftaucht, dass sie nicht auf den nächsten Sprint warten kann.
In Bezug auf Deployments sagt Scrum, dass Sie am Ende des Sprints ein Produktinkrement haben sollten. Es bedeutet nicht, dass Sie die Funktionalität erst am Ende des Sprints bereitstellen müssen. Sie können so viele Bereitstellungen haben, wie Sie möchten, benötigen oder während eines Sprints durchführen können.
Es gibt viele Möglichkeiten, damit umzugehen, aber meiner Meinung nach sind die folgenden zwei die nachhaltigsten:
Offensichtlich sollte das längerfristige Ziel darin bestehen, Fehler zu minimieren, indem Praktiken eingeführt werden, die die Qualität fördern. Wenn Sie einen großen Prozentsatz Ihrer Bemühungen für Fehler aufwenden, ist das oben Genannte hilfreich.
Nachdem alles getan wurde, können Produktions-Showstopper immer noch selten auftreten. Mein Ansatz dazu ist, das ganze Team zu stoppen, es zu reparieren, weiterzumachen.
Was wir im Moment machen.
Wir haben einen Sprint geplant, der aus 2 Teilen besteht.
Mit diesem Vorschlag berücksichtigen Sie die Zeit, um Fehler zu beheben. Sie beheben sie nicht alle in einem Sprint, sondern gehen einfach kontinuierlich vor. Wenn die Bestellung ein sehr hohes Produktionsproblem hat, wird die Fehlerzeit berücksichtigt. Auf diese Weise kommt die Neuentwicklung nicht ins Stocken und Sie können das Produktionsproblem beheben.
Dies ist eine Situation, in der das Produkt live ist und wir viele Fehler haben (das verdammte Ding zum Festpreis gekauft). Es funktioniert ziemlich gut für uns.
Achten Sie darauf, diese kleinen Sprints oder so zu nennen. Wenn dies wirklich ein Problem ist, nehmen Sie vielleicht etwas kürzere Sprints. 1 (oder maximal 2) Wochen. Auf diese Weise können Sie auch diese lästigen Produktionsprobleme schneller liefern
Todd A. Jacobs
Samsher
Alan Larimer
Alan Larimer
Sprints must always schedule the same size for a time boxist grammatikalisch problematisch und falsch. Ein Sprint ist eine Zeitbox. Obwohl empfohlen, muss die Sprintlänge nicht konstant sein. DennA new Sprint starts immediately after the conclusion of the previous Sprintder nächste startet nichtat the PO's discretion.