Découvrez ce que vous devriez faire avant même le début de votre réunion de planification de sprint afin de faire du prochain sprint un succès.

https://blog.gurock.com/sprint-planning/ par Nishi Grover Garg

Les équipes Scrum se réunissent pour décider des éléments de travail de leur prochain sprint lors de la réunion de planification du sprint. Mais est-ce le début de la conversation pour le sprint à venir, ou y a-t-il des choses à faire avant ?

Priorisez le Product Backlog, l’arriéré de produit

La première et la plus importante considération est d’avoir un product backlog vivant qui est à jour et hiérarchisé pour suivre l’évolution des besoins de l’entreprise. Le propriétaire de produit doit avoir un œil constant sur l’ajout, la suppression, la modification et la mise à jour d’éléments dans le product backlog. Lorsque le temps vient de planifier le sprint suivant, le chef de produit doit apporter à la table une liste des éléments de valeurs les plus élevées que l’équipe puisse choisir.

Détaillez les fonctionnalités

Étant donné que la plupart des exigences agiles sont courtes, soit sous la forme d’histoires utilisateur (User Stories) ou simplement de phrases listant les fonctionnalités nécessaires, elles nécessitent d’être détaillées pour pouvoir être implémentées. Le propriétaire de produit doit passer du temps à rechercher chacune des fonctionnalités et à essayer de présenter en termes simples le besoin réel que chacune exprime. Utilisez des listes à puces ou des phrases simples, pour expliquer la fonctionnalité en détail. Nous voyons cela se produire principalement pendant ou après la réunion de planification du sprint, mais si des exigences sont connues avant la réunion, le propriétaire de produit peut avoir une longueur d’avance.

Décidez d’une définition de done

Au cours d’une réunion de planification de sprint, l’équipe choisit généralement ce qu’elle fera et livrera à la fin de cette itération de sprint. Il est impératif que les membres de l’équipe connaissent et conviennent d’une définition de done pour chaque histoire utilisateur ainsi que chaque tâche de chacune. Qu’il s’agisse d’une tâche de développement, d’une tâche de conception ou d’exécution de test ou d’une tâche de revue de livrable, tout le monde doit s’accorder sur une compréhension commune de ce que signifie « done » afin d’assurer une livraison fluide et aucun conflit à la fin du sprint.

Soignez les user stories

Chaque histoire utilisateur qui est mise en avant pour la planification du sprint doit être soignée, développée et détaillée avec les connaissances et les commentaires de l’équipe entière.

Lorsque les testeurs, les développeurs et le propriétaire de produit s’assoient ensemble et discutent d’une nouvelle fonctionnalité, de nombreuses nouvelles questions peuvent survenir de la part de l’équipe. Les questions portent souvent sur l’intégration avec les fonctionnalités existantes, le comportement de la fonctionnalité dans des cas spécifiques ou la manière dont le comportement doit être adapté pour différents types d’utilisateurs. Les cas spéciaux font également partie des critères d’acceptation définis dans l’histoire utilisateur pour la rendre complète.

Quelles que soient les questions, il est préférable de les poser au plus tôt et d’y répondre avant de choisir l’histoire utilisateur. Fondamentalement, cela signifie qu’une conversation doit avoir lieu pour chaque user story, afin que l’équipe puisse se comprendre et décider des critères d’acceptations définis et agréés par tous.

Ces sessions de « toilettage d’histoires » doivent avoir lieu avant la réunion de planification du sprint afin que pendant la planification, l’équipe sache exactement ce qui est requis de cette fonctionnalité et puisse donner de meilleures estimations et story points en fonction de sa complexité.

Commencez par le design

De nombreuses histoires utilisateur ont besoin de storyboards visuels ou de maquettes de l’interface utilisateur, et dans ces situations, les concepteurs d’expérience utilisateur ou UX designers peuvent avoir besoin d’être impliqués. Ces histoires doivent être sélectionnées un sprint à l’avance et allouées d’abord aux UX designers, afin qu’ils puissent construire les maquettes ou les images d’écran prêtes avant que la fonctionnalité ne soit sélectionnée pour le développement dans le sprint suivant. Cette approche facilite la communication et évite les retards pendant le développement.

De même, certaines histoires utilisateur peuvent nécessiter une recherche sur une nouvelle approche, une nouvelle technologie ou un nouvel outil avant de commencer, ou il peut être nécessaire de créer un design d’architecture complet pour une certaine partie avant de se lancer dans sa mise en œuvre. Dans de tels cas, la tâche de conception ou de R&D doit être créée et démarrée dans un sprint précédent, puis allouée au développeur ou à l’architecte principal au sein de l’équipe pour préparer les designs et résultats de recherche pertinents. Ils peuvent ensuite partager ces informations avec l’équipe afin que tout le monde soit prêt à commencer à travailler sur la mise en œuvre dans le sprint suivant.

Un propriétaire de produit doit être constamment à l’affût des histoires utilisateur qui peuvent nécessiter un travail de conception ou de recherche avant de les commencer, et avoir ces user stories distribuées aux personnes concernées avant le sprint pour s’assurer que la mise en œuvre sera fluide et que la livraison pourra avoir lieu à temps.

Nishi est une formatrice en entreprise, une passionnée agile et une testeuse dans l’âme ! Avec plus de 11 ans d’expérience dans l’industrie, elle travaille actuellement chez Sahi  Pro en tant qu’évangéliste et responsable des formations. Elle est passionnée par la formation, l’organisation d’événements et de rencontres pour une communauté de test, et a été conférencière lors de nombreux événements et conférences de test.

Consultez  son blog où elle écrit sur les derniers sujets dans les domaines Agile et Testing.