Kann hier jemand meine Frage beantworten? Ich habe 5 bis 6 Aufgaben wie Analyse (4 Std.), Design (3 Std.), logische Überprüfung (1 Std.), Peer-Review (1 Std.), Komponententests (1 Std.), Codierung (2 Std.) und Freigabe ( 1 Std.). Aber während der Analyse selbst erfuhr ich, dass der Rest der Aktivität nicht anwendbar sein wird. Soll ich in diesem Szenario die Stunden für alle Aufgaben, die veraltet sind, auf null setzen oder die Aufgaben löschen?
Hier ist, was die Bibel der Scrum Praktiker, der Scrum Guide, über das Sprint Backlog sagt :
Wenn neue Arbeit erforderlich ist, fügt das Entwicklungsteam sie dem Sprint Backlog hinzu. Wenn Arbeit ausgeführt oder abgeschlossen wird, wird die geschätzte verbleibende Arbeit aktualisiert. Wenn Elemente des Plans als unnötig erachtet werden, werden sie entfernt. Nur das Entwicklungsteam kann sein Sprint Backlog während eines Sprints ändern. Das Sprint Backlog ist ein gut sichtbares Echtzeit-Bild der Arbeit, die das Entwicklungsteam während des Sprints zu erledigen plant, und es gehört ausschließlich dem Entwicklungsteam.
Wenn Sie also festgestellt haben, dass einige der Aufgaben nicht erforderlich sind, entfernen Sie sie.
@David Arno schlug Ansätze vor, um die Lücke im Sprint zu füllen. Wenn dies jedoch häufig vorkommt oder es einen großen Teil Ihres Sprints ausmacht, sollten Sie erwägen, in einem früheren Sprint eine zeitgesteuerte Forschungsgeschichte (auch bekannt als Spike) zu erstellen. Dieselbe Analyse, möglicherweise einschließlich eines minimalen Proof-of-Concept, ermöglicht es Ihnen, mit mehr Vertrauen zu planen.
Löschen Sie die Aufgaben.
Wenn Sie feststellen, dass Sie dieselben Aufgaben wie J-Unit, Entwicklungstests usw. für alle Ihre Stories/Backlogs schreiben, sind dies keine Aufgaben, sondern Erledigungskriterien und können in eine Aufgabe auf höherer Ebene wie „Implementieren von XYZ als Teil von die Lösung."
Versuchen Sie, den Aufwand zu minimieren, der mit dem Erstellen und Verwalten von Details auf Aufgabenebene innerhalb der Iteration verbunden ist, wenn dies keinen Mehrwert bringt.
Der erste Punkt ist, dass ich vorschlagen würde, dass Sie Ihre Aufgaben zu sehr ins Detail brechen und einen Mini-Wasserfall innerhalb Ihres Sprints erzeugen. Komponententests und Codierung werden normalerweise gleichzeitig durchgeführt, sodass es wahrscheinlich zu Problemen führen wird, wenn Sie zwei separate Aufgaben haben. Wenn Sie TDD-Prinzipien übernehmen, ist das Schreiben der Tests und das Entwickeln des Codes das Design usw.
Abgesehen davon, Ihre Aufgaben sind, was sie sind. Wenn eine Aufgabe andere irrelevant gemacht hat, würden Sie je nach den Umständen normalerweise eine der folgenden Aktionen ausführen:
Wenn dem Sprint viele andere Aufgaben zugewiesen sind, entfernen Sie einfach die nicht benötigten Aufgaben daraus. Besprechen Sie dann mit dem Scrum Master und dem Product Owner, ob es möglich ist, stattdessen andere Aufgaben (aus dem Backlog) in den Sprint aufzunehmen.
Wenn die zu entfernenden Aufgaben den Großteil des verbleibenden Sprints ausmachen, dann weisen Sie den Product Owner darauf hin, dass der Sprint abgebrochen werden sollte und die End-/Start-Sprint-Meetings dann vorgezogen und ein neuer Sprint geplant werden sollten.
Todd A. Jacobs
David Arno