Combien de temps devrait durer une réunion de planification de sprint?

16

D'après votre expérience, combien de temps devrait durer une réunion de planification de sprint (Scrum)? 8 heures? Ou devrait-il être plus court (succinct) et d'autres discussions devraient être planifiées dans le cadre du sprint? Nos Sprints durent 10 jours.

wleao
la source
4
8 heures par sprint de 10 jours me semblent définitivement trop. Les discussions qui ne nécessitent pas toute l'équipe doivent être prises en sessions distinctes, uniquement pour les membres impliqués.
Péter Török
1
Vous planifiez donc d'autres réunions au lieu de discuter de tout dans la planification. Point noté.
wleao
Des discussions devraient avoir lieu sur les idées et les plans à venir afin que la plupart des membres de l'équipe aient une compréhension de base et partagée à leur sujet. Le critère est le suivant: lors de la réunion de planification, personne ne devrait être surpris à cause d'entendre une certaine chose pour la première fois. Chaque fois qu'une telle "surprise" se produit, ajustez en augmentant la quantité de communication qui se produit avant la prochaine réunion de planification. (Les exceptions à cela sont les annonces vraiment révolutionnaires venant des propriétaires de projets.)
rwong

Réponses:

31

Selon le Scrum Guide :

La réunion de planification du sprint est limitée à huit heures pour un sprint d'un mois. Pour les sprints plus courts, l'événement est proportionnellement plus court. Par exemple, les sprints de deux semaines ont des réunions de planification de sprint de quatre heures.

Cela fonctionne généralement pour moi.

Matthew Flynn
la source
5
C'est probablement un bon point de départ, mais il convient également de noter que vous devez adapter le processus à votre projet, à votre équipe et à votre organisation afin qu'il fonctionne pour vous. Ce n'est pas parce que d'autres personnes ont eu de la chance que cela fonctionnera pour vous dès la sortie de la boîte.
Thomas Owens
6
Cependant, si vous allez essayer Scrum, vous devriez probablement l'essayer d'abord en fonction des directives définies. Ensuite, si quelque chose ne fonctionne pas, affinez-le. Si vous changez les règles avant même de commencer, vous ignorez les preuves empiriques qui ont incité les personnes qui ont conçu Scrum à recommander ce qu'elles ont recommandé - sans aucune preuve empirique pour montrer que ce n'est pas la bonne chose pour vous.
Matthew Flynn,
@MatthewFlynn bon point
HA
Dans mon équipe de 3 personnes, nous n'avions généralement que des sprints d'une demi-heure, et lorsque l'équipe avait 7 ans, c'était généralement seulement une heure pour des sprints de deux semaines.
Zymus
27

Tant qu'elle doit durer, ni plus ni moins. Rien d'autre n'est agile.

Si vous avez une équipe de 2 à 3 développeurs et que vous effectuez des sprints d'une semaine, rien de plus qu'une heure n'est probablement contre-productif.

Si vous avez une équipe de 15 personnes et 2 semaines de sprints que vous regardez toute la journée, rien de moins n'est pas assez détaillé.

Il faut de l'expérience pour bien faire les choses, et c'est à cela que servent les rétrospectives, l'équipe décide de ce qui est trop long ou trop court.

Ne vous inquiétez pas de le rendre parfait ou de vous en tenir à ce que dit un livre, essayez quelque chose et affinez-le.

SCRUM consiste à affiner le processus dans les itérations autant qu'à affiner votre code dans les itérations.


la source
Une heure semble un peu courte pour 3 développeurs / 1 semaine de sprints. Là encore, je viens de terminer un projet relativement petit où nous avons fait une planification de sprint hebdomadaire de 5 minutes. Cela dépend du projet et des cartes, car parfois plus (ou moins) de discussion est nécessaire lors de la planification du sprint.
configurateur
2
L'une des idées clés de Scrum, en tant que cadre Agile, est que vous <i> établissez un calendrier </i>, comme le sprint, la réunion de planification du sprint et le stand-up / scrum quotidien. Le but est de garder les choses concentrées. Le time-boxing ne signifie pas que vous ne pouvez pas prendre moins de temps que prévu. Juste que vous ne devriez pas en prendre plus, car cela a tendance à faire perdre le focus aux gens et à réduire également le temps dont l'équipe dispose pour faire le travail.
Matthew Flynn du
7

Ne façonnez pas votre entreprise autour du processus. Le processus soutient votre entreprise. Au moment où vous faites le processus pour lui-même, il est temps pour le processus d'obtenir la hache. À cette fin, il n'y a pas de "bonne" voie. Les réunions ne devraient durer que tant que vous y accomplissez quelque chose. Si cela vous prend 30 minutes ou 4 heures, tant que cela fonctionne, alors allez-y. Ignorez ce que certains livres / blog / coach vous disent et faites ce qui vous convient.

MattC
la source
1
Pourquoi ne pas démarrer le processus comme prévu et l'adapter à partir de là? Si vous décidez d'utiliser des pratiques agiles et n'avez pas orienté votre entreprise dans cette direction, vous êtes déjà en difficulté.
JeffO
3

Prenez le temps dont vous avez besoin afin de sélectionner suffisamment pour que votre équipe pense qu'elle peut raisonnablement réaliser dans le sprint. Mais vous devriez passer du temps pendant le sprint (précédent) à affiner l'arriéré: estimer et affiner les histoires.

Extrait du Scrum Primer ( PDF ):

Affinement du carnet de produit

L'une des lignes directrices les moins connues, mais précieuses de Scrum est que cinq ou dix pour cent de chaque Sprint doivent être consacrés par l'équipe à affiner (ou «entretenir») le carnet de produit. Cela comprend une analyse détaillée des besoins, la division de gros articles en plus petits, l'estimation de nouveaux articles et la réestimation des articles existants. Scrum est silencieux sur la façon dont ce travail est effectué, mais une technique fréquemment utilisée est un atelier ciblé vers la fin du Sprint, afin que l'équipe et le propriétaire du produit puissent se consacrer à ce travail sans interruption. Pour un Sprint de deux semaines, cinq pour cent de la durée implique que chaque Sprint comporte un atelier de raffinement du carnet de commandes d'une demi-journée. Cette activité de raffinement ne concerne pas les éléments sélectionnés pour le sprint en cours; c'est pour des éléments pour l'avenir, très probablement dans les un ou deux prochains sprints. Avec cette pratique, Sprint Planning devient relativement simple car le Product Owner et Scrum Team commencent la planification avec un ensemble d'éléments clair, bien analysé et soigneusement estimé. Un signe que cet atelier de perfectionnement n'est pas fait (ou n'est pas bien fait) est que la planification de sprint implique des questions importantes, une découverte ou une confusion et se sent incomplète; le travail de planification déborde alors souvent sur le Sprint lui-même, ce qui n'est généralement pas souhaitable.

Cela signifie que vous pouvez vous concentrer sur la planification pendant la planification, et cela ne prend pas toute la journée et l'équipe commence à perdre le focus et à s'ennuyer.

Hugo
la source
@GottliebNotschnabel: Merci, c'est nouveau. J'ai changé le lien pour celui qui ne nécessite pas de connexion.
Hugo
2

Dans Scrum, lorsque vous travaillez sur des sprints de 2 semaines, la planification du sprint est limitée à 4 heures, ce qui en fait un événement d'une demi-journée. L'une des raisons de la durée relativement longue est que l'équipe de développement doit être en mesure de convenir en toute confiance que tous les éléments tirés dans le carnet de sprint peuvent être livrés, ce qui signifie qu'ils doivent connaître les détails. Il n'est pas rare dans le cadre de la planification du sprint que les équipes se détachent de l'espace de réunion pendant des périodes afin d'étudier les éléments plus en profondeur et de s'assurer qu'ils sont "prêts" à entrer dans le carnet de sprint. (Il peut être utile de considérer la planification du sprint comme un événement plutôt que comme une réunion.)

Utilisez votre «Définition de prêt» et la durée pendant laquelle l'événement de planification de sprint permet de garantir que tous les éléments de backlog entrant dans le sprint sont à la fois faisables et prêts . c'est-à-dire qu'elles peuvent être effectuées (complètement, selon la "Définition de Terminé") dans le sprint, et il y a suffisamment d'informations pour que l'équipe puisse les faire maintenant.
Notez bien sûr que vous ne voulez probablement pas le faire pour TOUS les éléments lors de la planification du sprint, car cela peut prendre beaucoup de temps. Essayez d'avoir un backlog régulier (hors planification de sprint) où vous pouvez décomposer les éléments du backlog, et estimer les éléments non encore estimés en utilisant la planification du poker par exemple. (J'ai trouvé que cela peut être une activité efficace pendant un dîner de travail avec l'équipe de développement, si vous avez le luxe de la disponibilité de votre équipe à l'heure du dîner!)

Les éléments de haute priorité peuvent souvent être ajoutés au backlog de produit par le propriétaire du produit juste avant la planification du sprint, et bien que le nettoyage de backlog de routine puisse, et devrait normalement, être fait avant l'événement de planification de sprint, il y aura toujours de nouveaux éléments comme celui-ci où l'équipe doit passer du temps à travailler sur les détails et à estimer la complexité pendant l'événement de planification de sprint, d'où la raison pour laquelle elle peut s'étendre à 4 heures pour des sprints de 10 jours / 2 semaines.

Si vous avez besoin de prolonger les discussions sur cet événement, vous pouvez avoir un élément de backlog dans le backlog de sprint pour "avoir telle ou telle discussion pour établir x", mais vous devez éviter d'inclure des éléments de sprint pour faire tout ce que vous allez faire déterminer les besoins réalisés au cours de cette discussion, car ceux-ci ne sont pas des éléments de carnet de commandes «prêts» à entrer dans le sprint.

Comme les gens l'ont dit, il y a des raisons pour lesquelles vous voudrez peut-être changer la façon dont vous exécutez Scrum si le processus ne fonctionne pas efficacement pour vous. Scrum est cependant un cadre très bien pensé et testé pour commencer, donc je m'assurerais que votre raisonnement est justifié avant de changer le processus.

David Pritchett
la source
1

Lors de la réunion de planification du sprint, l'équipe doit déterminer deux ensembles de choses:

A) Ce qui sera développé par l'équipe durant ce sprint

B) Comment sera-t-il développé

Cette réunion doit être limitée dans le temps, jusqu'à deux heures par semaine de sprint, réparties également pour chaque partie (partie A et partie B) de la réunion.

Donc, pour un Sprint de 4 semaines, cette réunion ne devrait pas durer plus de 8 heures, jusqu'à 4 heures pour la partie A et jusqu'à 4 heures pour la partie B.

Au cours de la partie A, l'équipe de développement doit estimer la vitesse de l'équipe qu'elle considère avoir pendant ce Sprint. Ils doivent également estimer les user stories prioritaires, et choisir suffisamment de ces user stories (déjà estimées) pour compléter en fonction de leur propre vitesse d'équipe estimée.

Dans la partie B, l'équipe de développement discutera de la façon de développer les user stories les plus difficiles déjà sélectionnées pour être développées. Très probablement, l'équipe de développement n'aura pas assez de temps pour discuter de la façon de développer toutes les user stories sélectionnées, donc, l'équipe doit choisir les user stories les plus difficiles.

Pendant le Sprint, l'équipe de développement a suffisamment de temps pour terminer cette discussion.

GEN
la source
-1

Selon le Scrum Guide :

Événements Scrum

Les événements prescrits sont utilisés dans Scrum pour créer une régularité et minimiser le besoin de réunions non définies dans Scrum. Tous les événements sont des événements temporels, de sorte que chaque événement a une durée maximale. Une fois qu'un Sprint commence, sa durée est fixe et ne peut pas être raccourcie ou allongée. Les événements restants peuvent se terminer chaque fois que l'objectif de l'événement est atteint, ce qui garantit un temps approprié sans laisser de gaspillage dans le processus.

Lénine
la source
Pourriez-vous s'il vous plaît expliquer le downvote car je ne fais que copier / coller un paragraphe du Scrum Guide?
Lénine