Wie lange sollte ein Sprint-Planungstreffen dauern?

Wie lange sollte ein Sprint Planning-Meeting (Scrum) Ihrer Erfahrung nach 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.

Laut Scrum Guide :

Das Sprint Planning Meeting ist auf acht Stunden für einen einmonatigen Sprint terminiert. Bei kürzeren Sprints ist das Ereignis proportional kürzer. Beispielsweise haben zweiwöchige Sprints vierstündige Sprint-Planungstreffen.

Das funktioniert in der Regel bei mir.

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 Woche lang sprinten, ist etwas mehr als eine Stunde wahrscheinlich kontraproduktiv.

Wenn Sie ein Team von 15 Leuten und 2 Wochen 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 in einem Buch steht, 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.

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

Nehmen Sie sich so lange Zeit, bis Sie genug ausgewählt haben, damit Ihr Team glaubt, dass es im Sprint einigermaßen erfolgreich ist. Sie sollten sich jedoch während des (vorherigen) Sprints Zeit nehmen, um den Rückstand zu verbessern: das Schätzen und Verfeinern von Geschichten.

Aus dem Scrum Primer ( PDF ):

Verfeinerung des Produktrückstands

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 Artikel in kleinere, die Schätzung neuer Artikel und die erneute Schätzung bestehender Artikel. Scrum schweigt darüber, wie diese Arbeit ausgeführt wird, aber eine häufig verwendete Technik ist ein konzentrierter Workshop gegen Ende des Sprints, damit sich das Team und der Product Owner ohne Unterbrechung dieser Arbeit 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 Verbesserung des Product Backlog durchgeführt wird. 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 bestimmt, höchstwahrscheinlich für die 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 Anzeichen dafür, dass dieser Verfeinerungsworkshop nicht durchgeführt wird (oder nicht gut durchgeführt wird), ist, dass die Sprintplanung wichtige Fragen, Entdeckungen oder Verwirrung mit sich bringt und sich unvollständig anfühlt. Die Planungsarbeit wird 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.

Wenn in Scrum an zweiwöchigen Sprints gearbeitet wird, ist die Sprintplanung auf vier Stunden festgelegt, sodass es sich um ein halbtägiges Ereignis handelt. Ein Grund für den relativ großen Zeitaufwand ist, dass das Entwicklungsteam sicher sein muss , dass alle Elemente, die in das Sprint-Backlog 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 Sprint-Planung für bestimmte Zeiträume vom Besprechungsraum abbrechen, um die Elemente weiter zu untersuchen und sicherzustellen, dass sie "bereit" sind, in das Sprint-Backlog einzusteigen. (Es kann hilfreich sein, die Sprintplanung als Ereignis und nicht als Besprechung zu betrachten.)

Verwenden Sie Ihre "Definition of Ready" und den Zeitraum, den das Sprint-Planungsereignis zur Verfügung stellt, um sicherzustellen, dass alle im Sprint enthaltenen Rückstandselemente machbar und bereit sind . Das heißt, sie können im Sprint (vollständig gemäß "Definition of Done") ausgeführt werden, und das Team verfügt über genügend Informationen, um sie jetzt ausführen zu können.
Beachten Sie natürlich, dass Sie dies wahrscheinlich nicht für ALLE Elemente während der Sprint-Planung tun möchten, da dies sehr zeitaufwändig sein kann. Versuchen Sie, einen regelmäßigen Backlog-Grooming (außerhalb der Sprint-Planung) durchzuführen, bei dem Sie Backlog-Elemente aufschlüsseln und Elemente schätzen können, die noch nicht mithilfe von Planning Poker geschätzt wurden. (Ich habe festgestellt, dass dies eine effektive Aktivität für ein arbeitsreiches Abendessen mit dem Entwicklungsteam sein kann, falls Sie den Luxus der Verfügbarkeit Ihres Teams zum Abendessen haben!)

Artikel mit hoher Priorität können jedoch häufig vom Product Owner unmittelbar vor der Sprint-Planung zum Product Backlog hinzugefügt werden. Während die routinemäßige Aufbereitung des Backlogs vor dem Sprint-Planungsereignis durchgeführt werden kann und sollte, gibt es immer solche neuen Artikel Das Team muss während des Sprint-Planungsereignisses Zeit darauf verwenden, die Details zu erarbeiten und die Komplexität abzuschätzen. Daher kann es für Sprints von 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 Rückstandselement im Sprint-Rückstand, um "eine solche und eine solche Diskussion zu etablieren", aber Sie sollten es vermeiden, Sprint-Elemente einzuschließen, um das zu tun, was Sie wollen Ermitteln der während dieser Diskussion getätigten Anforderungen, da es sich nicht um "fertige" Backlog-Elemente handelt, die in den Sprint aufgenommen werden können.

Wie bereits erwähnt, gibt es Gründe, warum Sie Scrum möglicherweise anders ausführen möchten, wenn der Prozess für Sie nicht effektiv funktioniert. Scrum ist jedoch zunächst ein sehr gut durchdachtes und erprobtes Framework, sodass ich sicherstellen möchte, dass Ihre Überlegungen gerechtfertigt sind, bevor Sie den Prozess ändern.

Beim Sprint Planning Meeting muss das Team zwei Dinge festlegen:

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

B) Wie es entwickelt wird

Diese Besprechung muss in einem Zeitrahmen von bis zu zwei Stunden für jede Sprintwoche stattfinden und für jeden Teil (Teil A und Teil B) der Besprechung gleichmäßig aufgeteilt werden.

Für einen Sprint von 4 Wochen sollte diese Besprechung nicht länger als 8 Stunden sein, 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 abschätzen, die es für diesen Sprint erwartet. Sie müssen auch die User Stories mit der höchsten Priorität schätzen und genügend dieser (bereits geschätzten) User Stories auswählen, um sie gemäß 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. Wahrscheinlich hat das Entwicklerteam nicht genug Zeit, um zu besprechen, 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.

Laut Scrum Guide :

Scrum Events

Vorgeschriebene Ereignisse werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Besprechungen zu minimieren, die in Scrum nicht definiert sind. Alle Ereignisse sind Zeitfensterereignisse, sodass jedes Ereignis eine maximale Dauer hat. Sobald ein Sprint beginnt, ist seine Dauer festgelegt und kann nicht verkürzt oder verlängert werden. Die verbleibenden Ereignisse können immer dann enden, wenn der Zweck des Ereignisses erreicht wurde, wobei sichergestellt wird, dass eine angemessene Zeitspanne aufgewendet wird, ohne dass dabei Abfall entsteht.