it-swarm-eu.dev

Wie lange sollte ein Sprint-Planungstreffen dauern?

Wie lange sollte Ihrer Erfahrung nach ein Sprint Planning-Meeting (Scrum) dauern? 8 Stunden? Oder sollte es kürzer (prägnant) sein und weitere Diskussionen im Rahmen des Sprints geplant werden? Unsere Sprints dauern 10 Tage.

16
wleao

Nach dem Scrum Guide :

Das Sprint-Planungstreffen ist für einen einmonatigen Sprint auf acht Stunden festgelegt. Bei kürzeren Sprints ist das Ereignis proportional kürzer. Zweiwöchige Sprints haben beispielsweise vierstündige Sprint-Planungstreffen.

Das funktioniert bei mir generell.

31
Matthew Flynn

Solange es dauern muss, nicht weniger und nicht mehr. Alles andere ist nicht agil.

Wenn Sie ein Team von 2 - 3 Entwicklern haben und 1-wöchige Sprints durchführen, ist mehr als eine Stunde wahrscheinlich kontraproduktiv.

Wenn Sie ein Team von 15 Personen und 2-wöchige Sprints haben, die Sie den ganzen Tag betrachten, ist alles andere nicht detailliert genug.

Es braucht Erfahrung, um es größtenteils richtig zu machen, und dafür sind Rückblicke gedacht. Das Team entscheidet, was zu lang oder zu kurz ist.

Mach dir keine Sorgen, dass es perfekt wird oder dass du dich an das hältst, was ein Buch sagt, probiere etwas aus und verfeinere es.

Bei SCRUM geht es sowohl um die Verfeinerung des Prozesses in Iterationen als auch um die Verfeinerung Ihres Codes in Iterationen.

27
user7519

Formen Sie Ihr Geschäft nicht um den Prozess herum. Der Prozess unterstützt Ihr Unternehmen. In dem Moment, in dem Sie den Prozess um seiner selbst willen durchführen, ist es Zeit für den Prozess, die Axt zu bekommen. Zu diesem Zweck gibt es keinen "richtigen" Weg. Meetings sollten nur so lange dauern, wie Sie etwas in ihnen erreichen. Wenn Sie 30 Minuten oder 4 Stunden brauchen, solange es funktioniert, dann machen Sie mit. Ignorieren Sie, was Ihnen ein Buch/Blog/Coach sagt, und tun Sie, was für Sie richtig ist.

7
MattC

Nehmen Sie sich so viel Zeit wie nötig, damit Sie genug auswählen, damit Ihr Team glaubt, dass es im Sprint vernünftigerweise etwas erreichen kann. Aber Sie sollten während des (vorherigen) Sprints Zeit damit verbringen, den Rückstand zu verfeinern: Geschichten zu schätzen und zu verfeinern.

Aus dem Scrum Primer ( PDF ):

Verfeinerung des Product Backlogs

Eine der weniger bekannten, aber wertvollen Richtlinien in Scrum ist, dass fünf oder zehn Prozent jedes Sprints vom Team für die Verfeinerung (oder „Pflege“) des Product Backlogs verwendet werden müssen. Dies umfasst eine detaillierte Anforderungsanalyse, die Aufteilung großer Elemente in kleinere Elemente, die Schätzung neuer Elemente und die Neubewertung vorhandener Elemente. Scrum schweigt sich darüber aus, wie diese Arbeit ausgeführt wird, aber eine häufig verwendete Technik ist ein gezielter Workshop gegen Ende des Sprints, damit sich das Team und der Product Owner dieser Arbeit ohne Unterbrechung widmen können. Für einen zweiwöchigen Sprint bedeuten fünf Prozent der Dauer, dass für jeden Sprint ein halbtägiger Workshop zur Verfeinerung des Product Backlog stattfindet. Diese Verfeinerungsaktivität gilt nicht für Elemente, die für den aktuellen Sprint ausgewählt wurden. Es ist für Gegenstände für die Zukunft, höchstwahrscheinlich in den nächsten ein oder zwei Sprints. Mit dieser Vorgehensweise wird die Sprint-Planung relativ einfach, da der Product Owner und das Scrum-Team die Planung mit einem klaren, gut analysierten und sorgfältig geschätzten Satz von Elementen beginnen. Ein Zeichen dafür, dass dieser Verfeinerungsworkshop nicht durchgeführt wird (oder nicht gut durchgeführt wird), ist, dass die Sprintplanung wichtige Fragen, Entdeckungen oder Verwirrung beinhaltet und sich unvollständig anfühlt. Planungsarbeiten werden dann häufig auf den Sprint selbst übertragen, was normalerweise nicht wünschenswert ist.

Auf diese Weise können Sie sich während der Planung auf die Planung konzentrieren. Dies dauert nicht den ganzen Tag und das Team verliert allmählich den Fokus und langweilt sich.

3
Hugo

Wenn Sie in Scrum an zweiwöchigen Sprints arbeiten, ist die Sprintplanung auf 4 Stunden festgelegt, sodass es sich um ein halbtägiges Ereignis handelt. Ein Grund für die relativ lange Zeit ist, dass das Entwicklungsteam muss sicher zustimmen kann, dass alle Elemente, die in den Sprint-Rückstand gezogen werden, geliefert werden können, was bedeutet, dass sie die Details kennen müssen. Es ist nicht ungewöhnlich, dass Teams im Rahmen der Sprintplanung für bestimmte Zeiträume vom Besprechungsraum abbrechen, um weitere Punkte zu untersuchen und sicherzustellen, dass sie "bereit" sind, in den Sprint-Rückstand einzusteigen. (Es kann hilfreich sein, die Sprintplanung als Ereignis und nicht als Meeting zu betrachten.)

Verwenden Sie Ihre "Definition of Ready" und die Zeitdauer, die das Sprint-Planungsereignis benötigt, um sicherzustellen, dass alle in den Sprint eingeführten Backlog-Elemente sowohl als auch und machbar sind bereit . d.h. sie können innerhalb des Sprints (vollständig gemäß "Definition of Done") durchgeführt werden, und es gibt genügend Informationen, damit das Team sie jetzt ausführen kann.
Beachten Sie natürlich, dass Sie dies wahrscheinlich nicht für ALLE Elemente während der Sprintplanung tun möchten, da dies sehr zeitaufwändig sein kann. Versuchen Sie, eine regelmäßige Backlog-Pflege (außerhalb der Sprint-Planung) durchzuführen, bei der Sie Backlog-Elemente aufschlüsseln und Elemente schätzen können, die noch nicht mithilfe von Planungspoker geschätzt wurden. (Ich habe festgestellt, dass dies eine effektive Aktivität für ein Arbeitsessen mit dem Entwicklungsteam sein kann, wenn Sie den Luxus haben, dass Ihr Team zum Abendessen verfügbar ist!)

Elemente mit hoher Priorität können vom Product Owner jedoch häufig unmittelbar vor der Sprintplanung zum Produkt-Backlog hinzugefügt werden. Während die routinemäßige Pflege des Backlogs vor dem Sprint-Planungsereignis durchgeführt werden kann und sollte, gibt es immer neue Elemente wie dieses Das Team muss Zeit damit verbringen, die Details zu erarbeiten und die Komplexität während des Sprint-Planungsereignisses abzuschätzen. Daher kann es für Sprints mit 10 Tagen/2 Wochen bis zu 4 Stunden dauern.

Wenn Sie längere Diskussionen aus diesem Ereignis herausnehmen müssen, haben Sie möglicherweise ein Backlog-Element im Sprint-Backlog, um "eine solche und eine solche Diskussion zu haben, um x einzurichten". Sie sollten jedoch vermeiden, Sprint-Elemente einzuschließen, um alles zu tun, was Sie wollen Bestimmen Sie die während dieser Diskussion durchgeführten Anforderungen, da diese nicht "bereit" sind, um in den Sprint zu gelangen.

Wie bereits erwähnt, gibt es Gründe, warum Sie die Art und Weise, wie Sie Scrum ausführen, ändern möchten, wenn der Prozess für Sie nicht effektiv funktioniert. Scrum ist jedoch zunächst ein sehr gut durchdachtes und getestetes Framework, daher würde ich sicherstellen, dass Ihre Argumentation gerechtfertigt ist, bevor Sie den Prozess ändern.

2
David Pritchett

In der Sprint-Planungsbesprechung muss das Team zwei Dinge festlegen:

A) Was wird das Team während dieses Sprints entwickeln?

B) Wie es entwickelt wird

Diese Besprechung muss zeitlich begrenzt sein, bis zu zwei Stunden für jede Woche des Sprints, gleichmäßig verteilt für jeden Teil (Teil A und Teil B) der Besprechung.

Für einen Sprint von 4 Wochen sollte dieses Meeting nicht länger als 8 Stunden dauern, bis zu 4 Stunden für Teil A und bis zu 4 Stunden für Teil B.

Während Teil A muss das Entwicklerteam die Teamgeschwindigkeit schätzen, die es während dieses Sprints haben wird. Sie müssen auch die User Stories mit der höchsten Priorität schätzen und genug dieser (bereits geschätzten) User Stories auswählen, um sie entsprechend ihrer eigenen geschätzten Teamgeschwindigkeit zu vervollständigen.

In Teil B wird das Entwicklerteam diskutieren, wie die anspruchsvolleren User Stories entwickelt werden können, die bereits für die Entwicklung ausgewählt wurden. Höchstwahrscheinlich hat das Entwicklerteam nicht genügend Zeit, um zu diskutieren, wie alle ausgewählten User Stories entwickelt werden sollen. Daher muss das Team die herausforderndsten User Stories auswählen.

Während des Sprints hat das Entwicklerteam genügend Zeit, um diese Diskussion abzuschließen.

1
GEN