Combien de points d'histoire devez-vous allouer lors d'un sprint initial?

Lors de la première mise en œuvre de Scrum au sein d'une équipe, comment devriez-vous déterminer la quantité de points d'histoire qui se trouvent dans un sprint initial lorsque vous n'avez aucune idée de la vitesse de l'équipe?

Devriez-vous baser cela sur une estimation des heures et n'utiliser les points qu'à un stade ultérieur?

Vous n'avez aucun fait historique sur lequel vous baser, donc je vous suggère de ne pas vous soucier du tout. Essayer de calculer la vitesse en fonction uniquement d'une formule n'est qu'une perte de temps.

Estimez simplement assez d'histoires et laissez l'équipe travailler dessus pendant le premier sprint. Ils finiront de toute façon ce qu'ils finissent. Après ce sprint initial, vous aurez votre vitesse réelle. Puisque vos sprints sont (excellents!) 1 semaine, vous obtiendrez très tôt la vraie vitesse.

Personne ne peut vous dire combien de points d'histoire pouvez-vous prendre pour votre premier sprint. Tout d'abord, le point de l'histoire est la valeur sans unité. Vous ne devez pas prendre de décisions initiales comme 1 point d'histoire = 6 heures, car dans de nombreux cas, cela se heurtera à vous plus tard. De plus, chaque projet peut avoir une "taille" différente de points d'histoire.

L'engagement doit être fait sur la base d'une réunion de planification avec le propriétaire du produit. Vous allez parcourir les user stories et PO vous expliquera quelques détails à leur sujet. Il fournira également quelques critères d'acceptation (définition du fait). La réunion de planification est limitée dans le temps (en fonction de la longueur et de la taille du sprint de l'équipe), la première observation est donc le nombre d'histoires d'utilisateurs dont vous avez pu discuter. Sur la base des informations reçues de l'OP, l'équipe devrait être en mesure de juger de manière professionnelle combien d'histoires d'utilisateurs discutées peuvent être réalisées dans le sprint. Parce que l'équipe sait qu'il s'agit d'un sprint initial et que rien n'est encore fait, l'équipe ne s'engagera probablement que sur une petite quantité de travail, mais cela augmentera dans les sprints futurs.

La valeur des points d'histoire purs ne doit pas être utilisée pour la planification et l'estimation du temps. Il devrait être utilisé pour décrire la complexité relative, mais 8 points d'histoire peuvent toujours signifier quelque chose entre 6-12 (Fibonacci) points d'histoire en réalité, donc dire que 8 points d'histoire équivaut à 4 jours est vraiment dangereux car il peut aussi être 3 ou 6 + "déchets" (frais généraux) au sprint initial.

L'un des principaux principes agiles est «Empower People». La planification et l'engagement sont exactement cette responsabilisation que vous donnez à l'équipe. L'équipe est responsable de la livraison des user stories commutées, mais bien sûr, elles peuvent échouer et il ne faut pas les blâmer pour l'échec de l'engagement dans les sprints initiaux. Les sprints initiaux sont pour l'étalonnage.

Une technique consiste à sélectionner quelques user stories de taille moyenne, à leur donner une taille arbitraire en points et à les répartir en tâches par l'équipe. Ensuite, l'équipe estime chaque tâche en heures, ce qui, une fois résumé, vous donne une estimation approximative des heures de travail par point d'histoire. Connaissant la capacité de travail totale pour le sprint, vous pouvez extrapoler pour obtenir un certain nombre de points d'histoire que vous pourriez théoriquement compléter dans le sprint.

Cela ne doit pas être interprété comme un objectif exact à atteindre, et doit être oublié dès que la première vitesse réelle de l'équipe apparaît, lorsque le premier sprint est terminé.

Vous devez deviner, car vous n'avez pas encore d'informations. Cependant, si vous avez déjà effectué un travail en dehors de Scrum mais avec la même équipe, vous pourrez peut-être utiliser votre expérience d'estimation précédente pour guider vos hypothèses. Ou vous pouvez simplement prendre des histoires supplémentaires jusqu'à ce que vous manquiez de temps.

De toute façon, vous ne comptez pas exclusivement sur des estimations ponctuelles pour la planification du sprint. Pendant la planification, votre vélocité peut vous aider à «proposer» rapidement un plan de sprint et / ou à effectuer votre bilan de santé avant de prendre l'engagement final; mais, peu importe la quantité de données de vélocité dont vous disposez, l'équipe doit finalement s'engager sur des histoires, pas sur des points .

Gardez à l'esprit que les histoires de 5 x 1 point ne sont pas égales à 1 histoire de 5 points pour des valeurs exceptionnellement petites de 1. Elles sont à peu près équivalentes aux fins de la planification à long terme.

Et c'est là que la valeur principale des points entre en jeu: lorsque vous devez évaluer quand une épopée ou une version peut être terminée, ou si vous en avez trop dans votre assiette pour une date de sortie prévue.

Cela dit, une équipe performante finira par planifier le même nombre de points à chaque sprint. Mais, il y aura des écarts basés sur les histoires particulières de ce sprint. Une équipe performante peut expliquer pendant la planification pourquoi certaines histoires en 5 points ne compensent pas réellement les 5 histoires en 1 point initialement proposées ...