Wie man damit umgeht, wenn geplante Arbeiten blockiert sind und ein Entwickler die Kapazität hat, eine neue User Story zu übernehmen, die möglicherweise zu groß ist

Gehen Sie von folgender Situation aus. Alle bis auf eine in einem Sprint geplante User Story sind abgeschlossen.

Die verbleibende User Story ist blockiert.

Ein Entwickler möchte Arbeiten in der Arbeit mit der höchsten Priorität im geschätzten Auftragsbestand übernehmen.

Leider ist die Geschichte größer als die verbleibende Zeit. Idealerweise möchte der Entwickler frühzeitig mit Arbeiten beginnen, die für den nächsten Sprint geplant sind.

Was ist der richtige Weg, um mit dieser Situation umzugehen?

Soll der Benutzer die ungeplante Arbeit dem nächsten Sprint zuweisen? In diesem Fall enthält der aktive Sprint nicht die gesamte Arbeit, an der aktiv gearbeitet wird (idealerweise möchten wir, dass der aktive Sprint die Quelle der Wahrheit dafür ist, woran Entwickler arbeiten).

Wenn wir es dem aktiven Sprint zuweisen, wird es höchstwahrscheinlich zu einem Spill-over kommen. Jeder würde es vorziehen, dies nicht zu tun, es sei denn, es gibt einen direkten Weg, um Spill-Over von geplanter Arbeit und Spill-Over von ungeplanter Arbeit zu unterscheiden.

Was ist der übliche Weg, um mit dieser Situation umzugehen?

Antworten (1)

Willkommen bei PMSE!

Gute Frage. Es kann ein Duplikat sein, aber ich konnte es nicht finden, also werde ich antworten. Ich kann Ihnen sagen, wie ich Teams coache, damit sie damit umgehen.

Leider ist die Geschichte größer als die verbleibende Zeit. Idealerweise möchte der Entwickler frühzeitig mit Arbeiten beginnen, die für den nächsten Sprint geplant sind

Ich trainiere, um es in den Sprint zu bringen . Ich persönlich glaube, dass die Geschwindigkeit nur als Maß für die Zeit nützlich ist. Die Geschwindigkeit einer einzelnen Timebox ist nicht so wichtig. Teams konzentrieren sich zu sehr darauf.

Der wirkliche Wert wird darin liegen, einige der tieferen organisatorischen Hinweise zu entschärfen, die wir hier kurz erörtern können.

Lässt sich die Geschichte weiter aufschlüsseln?

Kann die Geschichte mit einer der vielen Story-Splitting-Techniken aufgeschlüsselt werden ? Wenn ja; Brechen Sie es auf und nehmen Sie einen Teil als eigenständige, kleinere Geschichte in den Sprint auf.

Geschichte aufgeteilt

Haben Sie einen 1-Punkte-Eimer?

Ermutigen Sie Entwickler in Zukunft, grundlegende technische Aufgaben in einen Epic oder einen Eimer namens 1-Punkt-Eimer zu werfen. Dies ist ein ständiger Vorrat an kleinen, lästigen Geschichten mit niedriger Priorität oder geringem Wert, die als Füllmaterial verwendet werden können, wenn Entwickler nicht bereit sind, ein beträchtliches Stück komplexer Arbeit zu übernehmen.

Der 1-Punkt-Eimer dient auch als Arbeitsspeicher für Junior- oder Lehrlingsentwickler oder neue Teammitglieder, die sich mit der Technologie vertraut machen, wie z. B. ein Systemarchitekt, der versucht, Python usw. usw. zu lernen.

Kann der Entwickler ohne eine weitere Story zum Sprint-Ziel beitragen?

Bevor Sie sich einer anderen Geschichte annehmen, haben Sie die Möglichkeiten erschöpft, die der Entwickler zum aktuellen Sprint-Ziel beitragen kann. Können sie programmieren, debuggen oder testen?

Kann der Entwickler den nächsten Sprint zum Erfolg führen?

Können sie die CI/CD-Pipeline verbessern? Haben Sie eine Support-Warteschlange, die gelöscht werden muss? Braucht der Product Owner Unterstützung? Können sie einige Aspekte des vorherigen Sprints umgestalten? Soll ein technisches Schuldbuch recherchiert und geplant werden? Ist das eine weitere Fähigkeit, die sie lernen können?

Dies sind nur einige der Aktivitäten, die ein Entwickler nutzen kann, um einen Mehrwert für ein Team zu schaffen, bevor er sich im aktuellen Sprint einer großen User Story widmet

Wie man damit umgeht, wenn geplante Arbeiten blockiert sind und ein Entwickler die Kapazität hat, eine neue User Story zu übernehmen, die möglicherweise zu groß ist
AntwortenHierDatenschutz-Bestimmungen1y, 0v