Combien de temps devrait durer une réunion de planification de sprint?
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.
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.
Tant qu'il doit durer, ni moins ni plus. Tout le reste n'est pas 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 des sprints de 2 semaines 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 vise à affiner le processus en itérations autant qu'à affiner votre code en itérations.
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.
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.
À partir du Scrum Primer ( PDF ):
Affinement du backlog 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 Backlog 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'articles 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.
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 importante 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 backlog 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 réalisables et prêt . c'est-à-dire qu'ils peuvent être effectués (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 faire cela pour TOUS les éléments pendant 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 du 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.
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 il sera développé
Cette réunion doit être limitée dans le temps, jusqu'à deux heures pour chaque semaine du Sprint, répartie é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 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.