Unter Scrum haben wir eine Geschichte, die als ziemlich kurz eingeschätzt wurde. Als die Geschichte von einem Entwickler aufgegriffen wurde, stellte sich heraus, dass eine erhebliche Menge an technischer Vorbereitung erforderlich ist, und dies zieht sich enorm hin.
Das Unternehmen hat zugestimmt, dass die Vorbereitungsarbeiten so belassen werden können, sobald wir das Ende des Sprints erreicht haben, damit der Entwickler andere (wichtigere) Arbeiten erledigen kann – was bedeutet, dass die Geschichte nicht abgeschlossen werden kann. Es handelt sich hierbei um eine ausdrückliche Vereinbarung mit dem Unternehmen, dass die aktuelle Story später (nach Ablauf einer bestimmten Frist) abgeholt wird.
Soll diese problematische Story nach Done verschoben, als abgebrochen markiert und dann in einem späteren Sprint wiederbelebt werden, oder sollten wir sie einfach als blockiert markieren und dort belassen, bis ein (möglicherweise viel) späterer Sprint die Kapazität hat, sie aufzunehmen?
Eine dritte Option ist, dass wir die Geschichte in zwei Teile zerlegen: einen für die Vorbereitungsarbeit und einen für die eigentliche Arbeit. Aber damit bleibt die Frage: Was soll mit der eigentlichen Story angesichts der agilen Vorgaben geschehen?
Bewerten Sie die Auswirkungen auf das Sprint-Ziel und lassen Sie dann den Product Owner seine Funktion entsprechend erfüllen.
[D]ie Geschichte kann nicht gemacht werden...Sollte diese problematische Geschichte nach Erledigt verschoben, als abgebrochen markiert und dann in einem späteren Sprint wiederbelebt werden[,] oder sollten wir sie einfach als blockiert markieren und sie dort lassen, bis einige ( möglicherweise viel) späterer Sprint hat die Kapazität, es abzuholen?
Nichts des oben Genannten. Sie können eine unvollständige Geschichte oder ein nicht lieferbares Feature nicht als „erledigt“ behandeln. Die Arbeit kann auch nicht automatisch von Sprint zu Sprint fortgeführt werden, ohne gegen grundlegende Framework-Prinzipien zu verstoßen.
Eine größere Frage, die im ursprünglichen Beitrag unbeantwortet bleibt, ist, ob diese Geschichte für das Erreichen des aktuellen Sprintziels unerlässlich ist oder nicht. Wenn dies der Fall ist und nicht innerhalb des aktuellen Sprints abgeschlossen werden kann, muss der Product Owner entscheiden, ob er mit dem Team zusammenarbeitet, um das Ziel neu zu definieren, oder ob er den Sprint vorzeitig beendet und zur Sprint-Planung zurückkehrt.
Unabhängig davon, ob der Sprint vorzeitig beendet wird oder nicht, ist unerledigte Arbeit „nicht erledigt“ und wird am Ende des Sprints in das Product Backlog zurückgeführt. Der Product Owner kann dann entscheiden, ob er die Arbeit für einen zukünftigen Sprint neu priorisieren, depriorisieren, ganz verwerfen oder die Story so umgestalten/bearbeiten/zerlegen möchte, wie er es für richtig hält.
Mir sind diesbezüglich keine offiziellen agilen Richtlinien bekannt. Es gibt jedoch ein paar Dinge, die die gängige Praxis vorschreiben würde:
1) Es hört sich so an, als hätten Ihr Team und Ihr Unternehmen genau das richtige Gespräch darüber geführt, was zu tun ist, als sie feststellten, dass es viel größer war. Gut gemacht!
2) Die Geschichte wurde begonnen und Sie haben aufgehört, daran zu arbeiten. Ich würde es nicht auf erledigt verschieben, sondern einfach zurück in den Rückstand verschieben, um es später aufzunehmen. Es hört sich nicht wirklich so an, als wäre es blockiert, nur dass Sie es depriorisiert haben, also sollte der PO es dorthin verschieben, wo es seiner Meinung nach Priorität hat. Dies ist eine der wenigen Ausnahmen, bei denen ich tatsächlich empfehlen würde, die Größe der Geschichte an die neue Größe anzupassen, nur weil dies spätere Entscheidungen tatsächlich beeinflussen wird.
3) Aufräumen: Wenn das Team etwas an der Story gearbeitet hat, möchte es vielleicht keinen halbfertigen Code herumliegen lassen. Ob der richtige Weg zur Bereinigung darin besteht, ihn rückgängig zu machen oder den Code einfach aufzuräumen, damit er später problemlos wiederhergestellt werden kann, ohne Probleme zu verursachen, muss Ihr Team entscheiden, aber schaffen Sie etwas Platz dafür.
Scrum definiert drei Rollen. Die Arbeit im Sprint wird vom Entwicklungsteam prognostiziert und an einem vom Scrum-Team festgelegten Sprint-Ziel ausgerichtet.
Wenn sich die Arbeit als anders herausstellt als vom Entwicklungsteam erwartet, arbeitet es mit dem Product Owner zusammen, um den Umfang des Sprint-Backlogs innerhalb des Sprints auszuhandeln.
Wie das Scrum-Team diese Arbeit verwaltet, liegt bei ihnen, da sie hinsichtlich Aufwand, Problemen und Ergebnissen transparent bleiben. Versucht das Team, den Elefanten auf einmal zu essen, anstatt in kleinen Bissen? Kann der Artikel in kleinere funktionale Einheiten zerlegt werden? Sind mehrere Lernspitzen (Forschung, Prototyp, Proof-of-Concept oder Safe-to-fail-Experimente) erforderlich, um den besten Ansatz zu ermitteln?
Was sind „agile Richtlinien“ und wie sind sie Ihrer Meinung nach anwendbar? (Siehe die Definition von agil .)