Partager via


Réunion de planification de sprint

Votre équipe génère le journal des sprints en souffrance au cours de la réunion de planification le premier jour du sprint. Lors de cette réunion, le propriétaire du produit travaille conjointement avec votre équipe pour déterminer les récits que cette dernière finalisera dans le cadre du sprint. La réunion de planification est divisée en deux parties de durée égale. Au cours de la première partie, l'équipe et le propriétaire du produit identifient les récits utilisateur que l'équipe peut s'engager à effectuer pendant le sprint, en fonction de l'expérience des sprints précédents. Une fois que les récits utilisateur ont été identifiés, vous pouvez utiliser le classeur Planification du produit pour les assigner au sprint. Pour plus d'informations, consultez Planification de produit, classeur.

Lors de la deuxième partie de la réunion, l'équipe détermine comment elle développera et testera ces récits utilisateur. Elle divise alors ces récits utilisateur en tâches et estime le travail nécessaire pour les effectuer. Enfin, votre équipe s'engage à implémenter tout ou partie des récits utilisateur en fonction de ces évaluations.

Au cours de la première partie de la réunion, le propriétaire du produit rencontre votre équipe pour déterminer les récits utilisateur pouvant être inclus dans le sprint. Il partage des informations avec votre équipe et répond aux questions de cette dernière concernant ces récits. Cette conversation peut contribuer à identifier des détails tels que les sources de données, la disposition de l'interface utilisateur, les attentes liées aux temps de réponse et les considérations relatives à la sécurité et aux possibilités d'utilisation. Votre équipe doit ajouter ces détails aux récits utilisateur. Au cours de cette partie de la réunion, votre équipe découvre ce qu'elle doit créer.

Une fois que votre équipe a examiné tous les détails des récits utilisateur qui lui semblent nécessaires, le ScrumMaster entame la deuxième partie de la réunion de planification. Le propriétaire du produit doit assister à cette partie de la réunion pour clarifier les spécifications et faciliter la compréhension et la sélection d'alternatives. Le ScrumMaster anime cette partie de la réunion au cours de laquelle votre équipe détermine comment elle implémentera les récits utilisateur et si elle peut s'engager à implémenter tous les récits que le propriétaire du produit a demandés. Pour mieux comprendre ce qu'implique la finalisation de chaque récit utilisateur, votre équipe le décompose en tâches qu'elle doit effectuer pour l'implémenter et vérifier qu'il est terminé. Les exemples de tâches suivants figurent dans le journal des sprints en souffrance : « Mettre à jour la procédure stockée pour utiliser la nouvelle source de données » et « Créer la classe pour le service Web de collecteur ».

Votre équipe peut utiliser le classeur Journal des itérations en souffrance pour décomposer les récits utilisateur en tâches. Pour plus d'informations, consultez Journal des itérations en souffrance, classeur.

L'équipe évalue ensuite le nombre d'heures de travail requis par chaque tâche. Étant donné que les tâches ne sont assignées qu'après avoir été évaluées, les membres de l'équipe travaillent ensemble sur ces évaluations. (Souvent, les équipes ne peuvent pas identifier et estimer tout le travail pendant la réunion de planification sprint. 40 % du travail qu'une équipe effectue pendant un sprint émerge après la réunion de planification sprint.)

La technique du planning poker est un bon outil pour estimer les heures de tâche. À l'aide de cet outil, chaque membre de l'équipe peut participer à l'estimation, au lieu de laisser les experts techniques évaluer ses propres tâches. Que vous utilisiez cette technique ou une autre, vous devez impliquer toute l'équipe dans l'évaluation du nombre d'heures requis pour chaque tâche. Pour plus d'informations, consultez la ressource Web suivante : Planning Poker (page éventuellement en anglais).

L'exécution des tâches ne doit pas prendre plus d'une journée. Si une tâche est trop étendue, l'équipe doit la décomposer. Dans certains cas, vous pouvez ne pas être en mesure d'estimer certaines tâches efficacement tant que d'autres tâches n'ont pas été effectuées. Créez la tâche maintenant, mais estimez-la lorsque vous disposez de suffisamment d'informations. Les évaluations de tâches individuelles sont cumulées pour permettre de déterminer le nombre d'heures dont l'équipe aura vraisemblablement besoin pour finaliser chaque récit utilisateur.

Votre équipe continue à analyser chaque récit utilisateur et à estimer les tâches correspondantes jusqu'à ce qu'elle détermine que le nombre de récits disponibles pour le sprint est suffisant. Pour déterminer cette information, elle compare le nombre d'heures estimées au nombre d'heures qu'elle prévoit de consacrer au sprint.

Vous pouvez utiliser la feuille de calcul Capacité de l'équipe du classeur Journal des itérations en souffrance pour déterminer la capacité de votre équipe à exécuter le sprint. Vous devez indiquer les détails du sprint dans la feuille de calcul des paramètres. Pour prendre en compte les congés, les jours fériés et d'autres interruptions, vous devez remplir la feuille de calcul des interruptions. Pour plus d'informations, consultez Journal des itérations en souffrance, classeur.

Si votre équipe détermine qu'elle ne peut pas finaliser un ou plusieurs récits demandés par le propriétaire du produit car ses évaluations de tâche dépassent le nombre d'heures disponibles, vous devez en informer le propriétaire du produit. Le propriétaire du produit peut opter pour un récit utilisateur plus petit, fractionner le récit concerné ou le placer dans le journal des travaux en souffrance du produit pour un sprint ultérieur. À l'issue des deux parties de la réunion de planification, votre équipe :

  • a créé le journal des sprints en souffrance, avec les tâches et heures correspondant à chaque récit utilisateur ;

  • s'est engagée à finaliser les récits utilisateur qu'elle fournira dans le cadre du sprint

  • a compris, en tant qu'équipe autonome, comment elle va travailler de façon à tenir ses engagements

Voir aussi

Concepts

Planification et suivi de projets

Autres ressources

MSF for Agile Software Development v5.0