Une liste de vérification pour planifier un sprint que vous terminerez à temps
La planification de sprint est le moment où l'équipe Scrum s'engage sur un plan réaliste pour les prochaines semaines. Quand elle se passe mal, les symptômes sont connus : une réunion de deux heures qui en dure quatre, un Sprint Backlog auquel personne ne croit vraiment, et un sprint qui déborde en silence. Le Guide Scrum confie trois sujets à la planification — pourquoi le sprint a de la valeur, ce qui peut être fait, et comment le travail sera réalisé — mais il ne vous donne pas la discipline pour les régler vite. Cette partie revient à l'équipe.
À la mi-2021, alors que de nombreuses équipes travaillaient encore à distance ou en mode hybride bancal et que les ruptures d'approvisionnement rendaient les échéances nerveuses, le coût d'un plan bâclé a augmenté. Un plan élaboré sur trois fuseaux horaires et un appel vidéo capricieux doit être plus serré, pas plus lâche. La liste ci-dessous est faite pour être utilisée dès cette semaine.
Avant la réunion
L'essentiel de la douleur en planification vient d'un travail que l'équipe aurait dû faire en amont. Le raffinement ne fait pas partie de la planification ; c'est une activité continue qui la raccourcit. Passez en revue ceci la veille :
Le Product Owner a un objectif de produit clair et un Product Backlog ordonné, avec les premiers éléments suffisamment raffinés pour démarrer.
Les éléments probables du haut sont petits — chacun tient confortablement dans un sprint, avec de la marge.
Chaque élément candidat a des critères d'acceptation que les développeurs ont réellement lus, pas survolés cinq minutes avant.
Vous connaissez votre vraie capacité : qui est absent, qui est à temps partiel sur cette équipe, quels congés ou astreintes tombent dans le sprint.
Toute dépendance entre équipes a un responsable nommé et une date, pas une supposition optimiste.
Pendant la réunion
Gardez les trois sujets dans l'ordre et résistez à l'envie de concevoir tout le système. Le but est un plan assez bon pour démarrer, pas un plan qui survit intact au contact du réel.
Nommez d'abord l'objectif de sprint. Convenez d'une phrase décrivant pourquoi ce sprint compte avant de choisir le moindre élément. L'objectif est l'engagement ; les éléments se négocient autour de lui.
Tirez, ne poussez pas. Les développeurs choisissent la quantité de travail prise. Le Product Owner clarifie la priorité et les compromis, mais n'assigne pas la charge.
Planifiez sur la capacité réelle. Utilisez la vélocité ou le débit comme repère, puis retranchez les absences, réunions et charge de support. Un plan bâti sur une semaine parfaite est un plan qui échoue.
Décomposez juste assez pour démarrer. Découpez les premiers éléments en travail que les développeurs comprennent. Vous n'avez pas besoin de toutes les tâches de la semaine deux — juste d'un chemin crédible vers le jour un.
Faites un test de confiance. Demandez à chaque développeur sa confiance que l'objectif est atteignable. Si l'enthousiasme est tiède, réduisez le périmètre maintenant, pas au huitième jour.
Avant de conclure
Ne laissez pas la réunion s'arrêter d'elle-même. Concluez-la délibérément pour que chacun reparte avec la même image : l'objectif de sprint est écrit là où l'équipe le voit, le Sprint Backlog reflète ce qui a été réellement convenu, les dépendances et risques sont consignés avec des responsables, et quelqu'un a dit à voix haute : « Oui, nous pensons pouvoir terminer cela. » Pour une équipe à distance, cet artefact partagé compte plus que jamais — c'est la source unique de vérité quand personne n'est dans la même salle. Si la planification reste longue après quelques sprints, la cause est presque toujours en amont : un backlog mal raffiné. Réglez cela, et la planification se raccourcira d'elle-même.
Quand la pression de livraison est forte et que le plan doit tenir, le conseil en gestion de programmes et de projets de XNM aide les équipes à planifier un travail qu'elles peuvent réellement terminer.