Ce n’est pas un hasard si les prévisions météorologiques indiquent une probabilité de pluie de 70 % au lieu de promettre qu’il pleuvra exactement à 15 h. Elles s’appuient sur les informations disponibles, tiennent compte des incertitudes et sont mises à jour à mesure que de nouvelles données sont disponibles. Vous pouvez tout de même organiser votre après-midi en fonction de ces prévisions, à condition de ne pas les confondre avec une garantie.
La planification de sprint fonctionne selon un principe similaire. Une équipe Scrum dispose d’un backlog produit, d’une estimation de sa capacité disponible et d’un objectif qu’elle souhaite atteindre. Mais certains détails du travail ne se précisent qu’au fur et à mesure que le sprint avance. Planifier chaque heure à l’avance laisse peu de place à ces découvertes, tandis que se lancer sans orientation commune rend plus difficile de déterminer ce qui mérite l’attention.
L'objectif est de s'accorder sur un résultat à forte valeur ajoutée et de réaliser une prévision de la quantité de travail que l'équipe peut achever pour y parvenir. À partir de là, l'équipe peut adapter son plan au fur et à mesure qu'elle en sait plus, sans perdre de vue l'objectif du sprint.
Ce guide aborde la préparation du backlog, un agenda chronométré, des calculs pratiques de capacité et un exemple concret illustrant comment ajuster le plan au cours du sprint.
TL;DR La planification de sprint rassemble l'équipe Scrum afin de s'accorder sur un objectif de sprint, de sélectionner les éléments du backlog et d'établir un plan de livraison initial :
- Préparez-vous en affinant le travail à venir et en vérifiant les disponibilités, les éléments inachevés, les dépendances et la définition de « Terminé ».
- Fondez vos prévisions sur la capacité réelle et les performances passées, en tenant compte des congés, des réunions, des tâches d’assistance et des incertitudes, sans compter deux fois les engagements.
- À l'issue de la planification, disposez d'un backlog de sprint partagé, puis adaptez le plan de livraison à mesure que l'équipe acquiert de nouvelles connaissances, tout en préservant l'objectif du sprint.
- Utilisez l’exemple d’agenda de deux heures et l’exemple concret de calcul de la capacité comme points de départ, en les adaptant aux besoins de l’équipe.
Qu'est-ce que la planification de sprint ?
La planification de sprint est un évènement Scrum qui se tient au début de chaque sprint afin de s'accorder sur ce que l'équipe souhaite réaliser et sur la manière dont elle abordera le travail. Elle rassemble l'ensemble de l'équipe Scrum, y compris le Product Owner, le Scrum Master et les développeurs. D'autres spécialistes, tels que des ingénieurs en sécurité ou des responsables en contact avec la clientèle, peuvent également y participer lorsque leur contribution aide l'équipe à prendre des décisions éclairées.
Selon le Guide Scrum, chaque session de planification doit aboutir à trois éléments : un objectif de sprint qui explique la valeur du travail, une sélection d’éléments du backlog produit qui soutiennent cet objectif, et un plan initial pour leur livraison. Ensemble, ces éléments constituent le backlog de sprint, que les développeurs continuent de mettre à jour au fur et à mesure que le sprint avance.
Le Guide Scrum fixe une durée maximale de huit heures pour un sprint d’un mois, et les sprints plus courts nécessitent généralement moins de temps. Avec un backlog bien affiné, l’agenda ci-dessous tient en deux heures.
Si certains de ces termes vous sont inconnus, notre glossaire présente les notions fondamentales de l'agilité et de Scrum.
Les trois questions auxquelles répond la planification de sprint
Chaque session de planification de sprint s'articule autour de trois questions :
- En quoi ce sprint est-il utile ?
- Que pouvons-nous accomplir ?
- Et comment allons-nous mener à bien ce travail ?
Le Guide Scrum organise la planification autour de ces questions, en partant de la valeur que vous souhaitez apporter. Une fois que tout le monde a bien compris cela, il est plus facile de décider quels éléments du backlog méritent votre attention et quelle charge de travail votre équipe peut raisonnablement assumer.
| Question | Qui dirige la réunion ? | Résultats | Exemple pour un sprint de deux semaines |
|---|---|---|---|
| En quoi ce sprint est-il utile ? | Le Product Owner fait des propositions ; toute l'équipe donne son accord | Objectif du sprint | Les nouveaux clients peuvent payer par carte lors du paiement sans avoir à contacter l’équipe commerciale. |
| Que peut-on réaliser au cours de ce sprint ? | Les développeurs sélectionnent, en collaboration avec le Product Owner | Éléments sélectionnés du backlog | Formulaire de paiement par carte bancaire, intégration d'un fournisseur de paiement, e-mail de confirmation de paiement, gestion des erreurs |
| Comment le travail sélectionné sera-t-il terminé ? | Développeurs | Plan de travail initial | Les éléments sont décomposés en tâches, qui prennent souvent une journée ou moins chacune, et les responsabilités initiales sont convenues. |
Pourquoi le sprint est-il important ?
L'objectif du sprint donne à l'équipe une ligne directrice et aide les parties prenantes à comprendre ce à quoi elles peuvent s'attendre. Mettez-vous d'accord sur cet objectif avec votre équipe Scrum avant la fin de la session de planification.
Décrivez un résultat que tout le monde peut reconnaître, tel que « Les utilisateurs en période d’essai peuvent inviter des collègues », plutôt qu’une cible de charge de travail du type « Terminer 34 points d’histoire ». Si un problème imprévu survient, l’objectif aide l’équipe à décider quelles tâches ajuster tout en préservant le résultat escompté.
En savoir plus : Comment rédiger des objectifs de sprint efficaces (+ exemples)
Ce que l'équipe peut réaliser au cours de ce sprint
Une fois l’objectif défini, il est temps de déterminer ce que l’équipe est réellement en mesure de livrer.
Les développeurs sélectionnent les éléments du backlog en concertation avec le Product Owner, tout en tenant compte de la capacité disponible, des performances passées et de la définition du « terminé ». C’est également le moment idéal pour passer en revue les engagements existants susceptibles d’influencer le temps dont dispose l’équipe pour le travail du sprint.
De nombreuses équipes utilisent les points de story pour comparer l'effort et la complexité relatifs des éléments du backlog. Une échelle de Fibonacci peut aider à structurer ces discussions, en particulier lorsque l'effort requis n'est pas clairement défini.
Si vous découvrez les points d'histoire ou si vous souhaitez voir comment ils sont utilisés dans la pratique, voici un guide détaillé du processus d'estimation.
Comment l'équipe va-t-elle s'atteler au travail ?
Une fois les éléments du backlog sélectionnés, les développeurs déterminent comment les transformer en un incrément de produit fini qui réponde à la définition du « terminé ». Le Guide Scrum suggère de décomposer les éléments les plus volumineux en tâches plus petites, dont la taille est souvent estimée à une journée ou moins.
Cela ne signifie pas pour autant que vous deviez planifier chaque heure du sprint. Les premiers jours peuvent nécessiter un plan plus détaillé, tandis que les tâches ultérieures peuvent rester susceptibles d’ajustements à mesure que de nouveaux détails apparaissent. Considérer les premières estimations comme des engagements fermes peut mettre la pression sur l’équipe pour qu’elle respecte les chiffres initiaux, même si le périmètre évolue en cours de route.
Comme l'explique Dave West, PDG de Scrum.org :
Une prévision utilisée pour justifier une date encourage précisément les comportements qui sapent la confiance, comme gonfler les estimations, dissimuler les risques ou redéfinir discrètement ce que signifie « terminé » afin d’atteindre un nombre.
Une prévision utilisée pour justifier une date encourage précisément les comportements qui sapent la confiance, comme gonfler les estimations, dissimuler les risques ou redéfinir discrètement ce que signifie « terminé » afin d’atteindre un nombre.
Quelle est la différence entre la planification de sprint et l'affinage du backlog ?
L'affinage du backlog permet à votre équipe de mieux cerner le travail à venir avant de décider des éléments à inclure dans le prochain sprint. La planification du sprint s'appuie sur cette préparation pour convenir d'un objectif, sélectionner les éléments du backlog et établir un plan de livraison initial.
Ces deux activités ont des objectifs différents au sein de Scrum :
| Dimension | Affinement du backlog | Planification du sprint |
|---|---|---|
| Objectif | Clarifiez, décomposez et estimez les éléments à venir du backlog | Définissez l'objectif du sprint, sélectionnez le travail et planifiez la livraison |
| Calendrier | Tout au long du sprint | Au début de chaque sprint |
| Statut du Scrum | Une activité récurrente | Un évènement Scrum formel avec une durée fixe |
| Qui participe ? | Product Owner et développeurs concernés | L'ensemble de l'équipe Scrum |
| Résultats | Éléments du backlog avec des détails, des estimations et un périmètre plus clairs | Le backlog du sprint : l'objectif du sprint, les éléments sélectionnés et le plan de livraison |
Veillez à ce qu’un nombre suffisant d’éléments du backlog à venir soient suffisamment affinés pour que l’équipe dispose de choix clairs lors de la planification du sprint. Le niveau de préparation nécessaire dépend de la rapidité avec laquelle les priorités évoluent et du degré d’incertitude qui subsiste. Les éléments situés plus bas dans le backlog peuvent rester moins détaillés jusqu’à ce qu’ils se rapprochent du moment de leur sélection.
À lire également : Pour plus de conseils, consultez nos articles sur la gestion du backlog et sur la manière d'organiser et de hiérarchiser votre backlog produit.
Comment se préparer à la planification de sprint
Quelques jours avant la réunion, vérifiez que le backlog a une bonne forme et que chacun dispose des informations nécessaires pour prendre des décisions. Ainsi, vous pourrez consacrer la session à discuter de ce qu’il faut livrer et de la manière de s’y prendre, sans avoir à définir chaque exigence à partir de zéro.
Voici une checklist à parcourir avant votre prochain sprint :
- Rédigez un objectif de sprint : demandez au Product Owner de proposer un résultat qui s'inscrit dans l'objectif global du produit, en fournissant à l'équipe des points concrets à discuter
- Passez en revue le backlog produit : assurez-vous que les éléments les plus à haute priorité sont classés par ordre d'importance, bien compris et estimés si nécessaire
- Vérifiez la disponibilité de l'équipe : demandez aux développeurs de partager leurs congés prévus, leurs rotations d'assistance et tout autre engagement susceptible d'affecter leur capacité.
- Revoir le travail inachevé : passez en revue les tâches reportées du sprint précédent et les améliorations identifiées lors de la rétrospective
- Identifiez les dépendances : signalez le travail qui nécessite la contribution ou l’approbation d’une autre équipe et précisez qui se chargera de la coordination
- Passez en revue la définition de « Terminé » : assurez-vous que tout le monde comprenne les critères de qualité auxquels chaque élément du backlog doit répondre une fois achevé.
Si vous programmez la rétrospective de sprint et la session de planification à peu de temps d’intervalle, prévoyez suffisamment de temps pour permettre une discussion approfondie lors de chacune d’elles. Les conclusions de la rétrospective doivent servir de base au plan du prochain sprint ; veillez donc à ce qu’aucune des deux réunions ne soit précipitée.
Ordre du jour de la planification de sprint : un exemple chiffré pour un sprint de deux semaines
Pour un sprint de deux semaines, commencez par une session de planification de deux heures, en particulier lorsque le backlog a déjà été affiné. Prévoyez du temps supplémentaire si le travail implique des dépendances complexes ou plusieurs décisions nécessitant une discussion.
Vous pouvez adapter cet échantillon d'agenda aux besoins de votre équipe.
| Durée | Élément de l'agenda | Qui dirige la réunion ? | Résultats attendus |
|---|---|---|---|
| 0:00–0:10 | Passez en revue les résultats du sprint précédent, le travail inachevé et les actions issues de la rétrospective. | Le Scrum Master anime la réunion. | Un partage de la vision sur les points à traiter |
| 0:10–0:30 | Discutez de l’objectif de sprint proposé par le Product Owner et mettez-vous d’accord sur le résultat souhaité. | Toute l'équipe Scrum | Une ébauche d’objectif de sprint compréhensible par tous |
| 0:30–0:45 | Vérifiez la disponibilité des membres de l'équipe et passez en revue les éventuelles contraintes de capacité | Développeurs | Une vision réaliste des capacités disponibles |
| 0:45–1:15 | Sélectionnez les éléments du backlog qui contribuent à l'objectif | Les développeurs, en collaboration avec le Product Owner | Une sélection de travaux que l'équipe estime pouvoir achever |
| 1 h 15 – 1 h 45 | Décomposez les éléments sélectionnés et discutez de l'approche de livraison | Développeurs | Un plan initial pour achever le travail |
| 1 h 45 – 2 h 00 | Passez en revue les dépendances, évaluez le niveau de confiance et finalisez l'objectif du sprint. | Toute l'équipe Scrum | Un objectif de sprint convenu et un backlog de sprint prêt à être utilisé par l'équipe |
Avant de conclure, vous pouvez recourir à un rapide test de confiance tel que le Fist of Five, où chacun effectue une évaluation de son niveau de confiance dans le plan en levant de zéro à cinq doigts. Si quelqu’un attribue une note faible, demandez-lui ce qui suscite ses inquiétudes. Cela pourrait révéler une dépendance non résolue, une prévision trop ambitieuse ou une exigence nécessitant une discussion plus approfondie.
L'objectif est de faire émerger les préoccupations tant qu'il est encore temps d'ajuster le plan.
Comment mener une réunion de planification de sprint en 6 étapes
Une fois que vous avez préparé le backlog et confirmé la liste des participants, lancez la session de planification. L'objectif ici est d'aider l'équipe à transformer ses priorités et sa capacité disponible en un plan qu'elle est sûre de pouvoir mener à bien.
Étape 1 : Passer en revue le travail précédent et se mettre d’accord sur un objectif de sprint
Commencez par passer brièvement en revue ce qui a été achevé, ce qui reste à faire et si des actions issues de la rétrospective doivent influencer le prochain sprint. Concentrez-vous sur tout ce qui pourrait modifier les priorités ou l’approche de l’équipe, plutôt que de revenir sur l’intégralité de la revue de sprint.
Demandez ensuite au Product Owner de présenter l’objectif de sprint proposé et d’expliquer en quoi il s’inscrit dans l’objectif global du produit. Laissez aux développeurs la possibilité de s’interroger sur sa portée, de soulever les dépendances et de suggérer des ajustements.
Par exemple, si l’objectif est de permettre aux clients d’achever leur commande sans contacter l’équipe commerciale, mettez-vous d’accord sur ce que signifie une commande réussie. Cela inclut-il la confirmation du paiement et la gestion des erreurs ? L’envoi automatisé du reçu est-il indispensable pour la première version ?
Ces discussions vous aident à définir un résultat vers lequel l’équipe peut tendre. La formulation peut évoluer au fur et à mesure que les éléments du backlog sont sélectionnés, mais tout le monde doit s’accorder sur l’objectif final avant la fin de la planification.
Étape 2 : Calculer la capacité disponible de l’équipe
Avant de sélectionner le travail, déterminez le temps que vos développeurs peuvent réellement consacrer au sprint.
Commencez par déterminer le nombre de jours ouvrés et la disponibilité prévue de chaque personne. Tenez ensuite compte des congés prévus, des évènements Scrum, des responsabilités d’assistance et des autres engagements connus. Si un développeur passe la moitié de sa semaine à gérer des problèmes de production, ces heures sont déjà engagées et ne sont pas disponibles pour le travail prévu dans le sprint.
Voici un calcul simple : Capacité disponible = Nombre total d'heures de travail − Engagements connus
Par exemple, un développeur disposant de 80 heures de travail sur deux semaines peut avoir 8 heures de congés, 10 heures de réunions et 12 heures d’assistance. Il lui reste donc 50 heures avant de prendre en compte toute incertitude supplémentaire.
Comparez ce chiffre aux performances passées de l’équipe. La vélocité indique la quantité de travail que l’équipe a achevé lors des sprints précédents, tandis que la capacité reflète le temps disponible pour ce sprint.
Conseil de pro : si vous utilisez des heures pour planifier la capacité, ne les mélangez pas avec les points de story. Ces deux unités mesurent des choses différentes, et il n’existe pas de conversion universelle entre elles.
Étape 3 : Réévaluez le travail inachevé du sprint précédent
Les éléments du backlog non terminés méritent d’être réexaminés avant de les ajouter au nouveau sprint. Un élément qui était important il y a deux semaines peut avoir changé de priorité, ou l’équipe a peut-être appris quelque chose qui influe sur la charge de travail restante.
Passez en revue chaque élément avec le Product Owner et réfléchissez aux éléments suivants :
- Pertinence : Cela soutient-il toujours l'objectif de sprint proposé ou une autre priorité importante du produit ?
- Effort restant : Quelle quantité de travail reste-t-il à effectuer maintenant que l’élément a été achevé ?
- Dépendances : Y a-t-il un élément qui empêche l'équipe de réaliser sa progression ?
- Priorité : Cet élément doit-il passer avant les éléments du backlog récemment affinés ?
Pour les tâches qui doivent encore être intégrées au sprint, utilisez l’effort restant pour évaluer la capacité nécessaire. Un élément à moitié terminé peut nécessiter moins de travail que prévu initialement, mais il reste considéré comme inachevé tant qu’il ne répond pas à la définition du « Terminé ».
Étape 4 : Sélectionnez les éléments du backlog qui contribuent à l'objectif
Une fois que votre capacité et le travail en cours sont bien cernés, les développeurs peuvent sélectionner les éléments du backlog produit qu’ils estiment pouvoir achever.
Commencez par les éléments qui contribuent directement à l’objectif du sprint. Discutez de leurs critères d’acceptation, de leurs dépendances techniques et de toute incertitude susceptible d’affecter la livraison. Si un élément est trop vaste ou trop flou, envisagez de le diviser en parties plus petites pouvant apporter de la valeur au cours du sprint.
Vous pouvez également prévoir du temps pour la maintenance ou d’autres priorités liées au produit, mais vérifiez si le travail nécessaire pour atteindre ces objectifs risque de compromettre l’objectif principal.
Quelle capacité devez-vous réserver ?
Ne planifier que 80 % de la capacité disponible peut constituer un point de départ raisonnable pour les équipes qui doivent régulièrement gérer du travail d'assistance imprévu, mais Scrum ne prescrit pas de pourcentage fixe.
Si votre équipe a subi des interruptions fréquentes, vous pouvez réserver 10 à 20 % de sa capacité ajustée et comparer cette marge avec les besoins constatés lors des sprints précédents. Une équipe dont la charge de travail est stable et qui subit peu d’interruptions aura peut-être besoin d’une marge moindre. En revanche, une équipe chargée d’un service en production connaissant des incidents fréquents aura peut-être besoin d’une marge plus importante.
Évitez de comptabiliser deux fois le même engagement. Si les heures d’assistance prévues ont déjà été déduites à l’étape 2, la marge supplémentaire doit couvrir les incertitudes au-delà de cette charge de travail connue. Utilisez la capacité ainsi obtenue comme base de discussion, et non comme une cible à atteindre.
N’oubliez pas : un sprint présentant une capacité inutilisée n’est pas nécessairement sous-planifié. Si vous avez sélectionné suffisamment de tâches pour atteindre l’objectif du sprint, remplir les heures restantes avec des tâches sans rapport peut créer des priorités contradictoires. Parfois, une prévision plus modeste est plus réaliste, en particulier lorsque les tâches sélectionnées comportent une part d’incertitude importante.
Étape 5 : Décomposez le travail et vérifiez les dépendances
Une fois les éléments du backlog sélectionnés, les développeurs peuvent réfléchir à la manière dont ils vont les livrer. Cela peut impliquer de décomposer les éléments les plus volumineux en tâches de développement, de test, d’intégration et de révision.
Examinez attentivement l'ordre des tâches. Si l'interface de paiement dépend de l'intégration d'un fournisseur de paiement, l'équipe doit savoir quand cette intégration doit être prête. Si une autre équipe doit approuver une modification de sécurité, précisez comment et quand cette décision sera prise.
Planifiez le travail immédiat de manière plus détaillée, en laissant les tâches ultérieures ouvertes à une discussion ultérieure. Le Guide Scrum suggère de décomposer les éléments sélectionnés en tâches plus petites, d'une taille généralement inférieure ou égale à une journée, mais ce sont les développeurs qui décident comment organiser et répartir le travail.
Vérifiez que le plan tient compte de la « définition du « terminé » », y compris les tests et les travaux d’intégration indispensables. Si une dépendance risque d’empêcher la livraison, réexaminez les éléments sélectionnés ou adaptez l’approche de livraison avant de finaliser le plan.
Étape 6 : Finaliser et partager le backlog du sprint
Consignez l’objectif du sprint, les éléments sélectionnés du backlog produit et le plan de livraison initial dans un document accessible à l’équipe et pouvant être mis à jour par celle-ci. Ensemble, ces éléments doivent permettre de clarifier ce que l’équipe vise à réaliser et quelles tâches doivent être traitées en priorité.
Avant de clore la réunion, assurez-vous que l’objectif fait l’unanimité et donnez à chacun l’occasion d’évoquer d’éventuelles préoccupations restantes concernant les prévisions. Si une dépendance importante ou un problème de capacité n’est pas résolu, discutez des changements nécessaires avant que l’équipe ne se mette au travail.
Pendant le sprint, le Daily Scrum permet aux développeurs de faire le point sur les progrès accomplis vers l’objectif et d’ajuster le backlog du sprint. Un diagramme burndown ou burnup peut aider à visualiser l’évolution des progrès, tandis que les tâches sous-jacentes fournissent des détails. Si de nouvelles informations affectent le périmètre sélectionné, les développeurs peuvent discuter des ajustements avec le Product Owner sans compromettre l’objectif du sprint.
Exemple de planification de sprint : une équipe de 6 développeurs
Voyons comment ces décisions se traduisent dans la pratique.
Imaginez que vous planifiez un sprint de deux semaines pour un produit de facturation B2B. Votre équipe compte six développeurs et l’objectif proposé pour le sprint est le suivant : « Les nouveaux clients peuvent payer par carte lors du paiement sans avoir à contacter l’équipe commerciale. »
Avant de sélectionner les éléments du backlog, vous devez connaître le temps dont dispose l’équipe. Pour cet exemple, supposons que chaque développeur dispose de six heures potentielles par jour pour se consacrer au projet, avant de déduire les évènements Scrum prévus et les autres engagements.
Voici comment fonctionne le calcul de la capacité sur 10 jours ouvrés :
| Calcul des capacités | Heures |
|---|---|
| Capacité de base : 6 développeurs × 10 jours × 6 heures | 360 |
| Congé prévu : 1 développeur absent pendant 2 jours | −12 |
| Astreinte : 1 développeur disponible à 50 % | −30 |
| Événements Scrum : 8 heures par développeur | −48 |
| Capacité disponible | 270 |
| Prévoyez 20 % pour le travail imprévu | −54 |
| Capacité disponible pour le travail planifié | 216 |
Vous disposez désormais de 216 heures pour le travail planifié, après avoir prévu une marge de sécurité indicative de 20 %. En pratique, vous détermineriez cette marge en fonction de l'ampleur des interruptions dues à des tâches imprévues lors des sprints précédents.
Choisissez le travail qui contribue à l'objectif du sprint
Une fois la capacité établie, les développeurs passent en revue avec le Product Owner les éléments du backlog liés à la validation.
Voici une sélection illustrative basée sur leurs estimations initiales de l'effort requis au niveau des tâches :
| Élément du backlog | Estimation de l'effort |
|---|---|
| Créer le formulaire de paiement par carte bancaire | 48 heures |
| Intégrez le fournisseur de paiement | 88 heures |
| Gérer les paiements échoués et les erreurs de validation | 50 heures |
| Ajouter la confirmation du paiement et l'envoi du reçu | 24 heures |
| Charge de travail totale prévue | 210 heures |
Ces estimations laissent une marge de 6 heures par rapport au temps alloué au travail planifié, à laquelle s'ajoute une réserve de 54 heures pour les tâches imprévues. L'équipe a également amélioré le tableau de bord de rapports dans le backlog produit. Bien que cette amélioration soit utile, elle ne contribue pas directement à l'objectif de livraison. Le Product Owner et les développeurs conviennent de la reporter à un sprint ultérieur.
Adaptez le forfait en cas de changement
Le sixième jour, le fournisseur de paiement introduit une modification de l’API qui perturbe une partie de l’intégration. Les développeurs examinent le problème et évaluent le travail supplémentaire nécessaire.
Plutôt que de poursuivre selon l’ordre des tâches initial, ils discutent de l’impact avec le Product Owner. Si la correction s’inscrit dans la capacité restante, ils peuvent la prioriser et reporter la mise en forme optionnelle des reçus ou une autre tâche de moindre priorité. La confirmation de paiement et les autres travaux essentiels doivent toujours respecter la définition du « Terminé ».
Si la correction s'avère plus importante que prévu, il faudra réévaluer le périmètre restant et déterminer si l'objectif du sprint est toujours réalisable.
Il se peut que l’équipe termine le sprint avec moins d’éléments du backlog achevés que prévu initialement. Mais si les clients peuvent finaliser leur commande comme prévu et que le travail répond à la définition de « terminé », l’objectif du sprint est atteint.
Exemples d'objectifs de sprint pour d'autres équipes
Vous pouvez appliquer cette même approche de planification au travail autre que le développement logiciel, bien que Scrum soit en soi un cadre spécifique comportant des responsabilités et des évènements bien définis.
Par exemple, une équipe marketing pourrait se fixer un objectif tel que « Publier la page d’accueil du webinaire et permettre aux visiteurs de s’inscrire sans assistance manuelle ». Une équipe opérationnelle pourrait quant à elle viser l’objectif suivant : « S’assurer que chaque collaborateur de la prochaine promotion d’intégration dispose du matériel et des droits d’accès au système nécessaires dès son premier jour ».
Ces deux objectifs décrivent des résultats qui peuvent guider les décisions de l’équipe tout au long du sprint. Les éléments du backlog et les plans de livraison varieront, mais l’équipe doit tout de même tenir compte de sa capacité et s’accorder sur ce que représente la réussite de la livraison.
Erreurs courantes lors de la planification de sprint et comment y remédier
La planification de sprint peut rencontrer des difficultés lorsque les équipes utilisent les points de story pour évaluer les performances individuelles, présentent des éléments du backlog mal définis lors de la réunion, attribuent le travail de manière trop rigide ou négligent les exigences de test et les dépendances externes.
Quelques ajustements peuvent vous aider à détecter ces problèmes avant qu’ils n’affectent la livraison.
| Erreur | Pourquoi cela pose-t-il des problèmes ? | Comment y remédier |
| Utilisation des points de story pour mesurer les performances individuelles | Comparer les développeurs en fonction du travail achevé peut inciter à surestimer les efforts nécessaires ou à éviter le travail complexe. | Veillez à ce que les points de story restent axés sur les prévisions au niveau de l'équipe. Passez en revue le travail achevé sur plusieurs sprints et discutez des modifications d'estimation lors de la phase de raffinement. Évaluez les performances individuelles à travers la qualité du code, la collaboration et les résultats. |
| Intégrer les éléments de backlog peu clairs dans la planification | L'absence de critères d'acceptation ou de questions techniques restées sans réponse transforme la planification en une discussion sur ce qu'il faut développer, ce qui laisse moins de temps pour planifier la livraison. | Répondez aux questions lors du raffinement du backlog afin que les développeurs puissent établir une prévision raisonnable. S'il subsiste des incertitudes, envisagez un travail plus petit et mieux cerné. Visez une clarté suffisante pour prendre une décision, plutôt que des spécifications parfaites. |
| Attribuer chaque tâche à une personne avant le début du travail | Les affectations fixes compliquent l'adaptation lorsque les priorités changent ou qu'un développeur termine plus tôt alors qu'un autre a besoin d'aide. | Laissez les développeurs organiser le travail. Mettez-vous d’accord sur les responsabilités immédiates et l’apport des spécialistes, puis permettez aux membres de l’équipe de prendre en charge, de travailler en binôme ou de redistribuer les tâches pendant le sprint. Veillez à ce que le travail reste visible pour toute l’équipe. |
| Ne pas résoudre les dépendances externes | L'absence d'identifiants API, de revues de sécurité ou de livrables d'une autre équipe peut obliger l'équipe à attendre du travail sur lequel elle n'a aucun contrôle. | Avant de finaliser le backlog du sprint, identifiez les données d’entrée requises, la personne chargée de leur coordination et leur date de livraison prévue. Si une dépendance critique reste incertaine, envisagez un élément alternatif ou un périmètre plus restreint que l’équipe pourra livrer de manière autonome. |
Si les mêmes problèmes reviennent régulièrement au cours de plusieurs sprints, abordez-les lors de la rétrospective de sprint et mettez-vous d’accord sur un changement que vous pourrez tester lors du prochain sprint. Ces modèles de rétrospective de sprint peuvent vous aider à consigner vos observations et les actions de suivi.
À la fin du sprint, profitez de la réunion de revue de sprint pour examiner l'incrément achevé avec les parties prenantes et discuter des prochaines tâches que l'équipe devra aborder.
Comment mener une réunion de planification de sprint dans ClickUp
La planification de sprint demande plus d'efforts lorsque les tâches, les estimations de capacité et les décisions de planification sont dispersées entre différents outils. ClickUp rassemble toutes ces informations, ce qui permet à l'équipe d'examiner le travail en tenant compte de la capacité disponible et de revoir ses décisions de planification en cas de modification du plan.
Commencez par le modèle de planification de sprint Agile de ClickUp. Ses vues « backlog », « statut d'avancement » et « ressources » vous aident à passer en revue le travail à venir et à vous préparer à la réunion de planification.
Voici comment aborder les décisions clés :
- Facilitez l'évaluation des tâches à venir : regroupez les exigences, les critères d'acceptation, les priorités et les dépendances dans une liste de tâches en attente sur ClickUp. Ces informations aident les développeurs à discuter de la portée du projet et à estimer l'effort nécessaire avant de sélectionner les tâches. Ajoutez les tâches choisies au sprint une fois que l'équipe s'est mise d'accord sur le plan.
- Définissez une fenêtre de planification cohérente : configurez la durée du sprint et les dates de début dans ClickUp Sprints. Utilisez les points de sprint ou les estimations de durée pour évaluer l'effort nécessaire et aider l'équipe à déterminer la charge de travail qu'elle peut assumer.
- Vérifiez si le travail est adapté : comparez les tâches attribuées à la capacité de chaque personne dans la vue « Charge de travail » de ClickUp. Examinez les charges de travail inégales et discutez des éventuels ajustements avant de finaliser les prévisions.
- Veillez à ce que l'agenda et les décisions restent en lien étroit avec le travail : utilisez ClickUp Docs pour l'agenda chronométré, l'objectif proposé pour le sprint et les liens vers les tâches concernées. Consignez les décisions relatives au périmètre et les questions en suspens pendant la session afin que l'équipe puisse y revenir au fur et à mesure de l'avancement du travail.
- Consignez la discussion de planification : ClickUp AI Notetaker permet d’enregistrer les réunions sur Zoom, Google Meet, Microsoft Teams ou SyncUps et d’enregistrer un résumé, les décisions clés et les actions à mener dans un document. Passez en revue les notes, puis mettez à jour les tâches du sprint en fonction des suites convenues.
- Utilisez les données d’avancement pour orienter les discussions : ajoutez des cartes « Sprint Burndown » ou « Burnup » aux tableaux de bord ClickUp pour passer en revue le travail achevé et l’effort restant. Lorsque l’avancement s’écarte du plan, examinez les tâches concernées afin d’identifier les retards ou les modifications de périmètre qui nécessitent une attention particulière.
Avant la prochaine session de planification, demandez à Brain²: « Quelles dépendances non résolues sont apparues lors de notre dernière session de planification de sprint ? » Brain peut extraire le contexte à partir des notes de réunion enregistrées. Vérifiez ces détails par rapport aux tâches en cours avant de les utiliser pour établir les prochaines prévisions.
Tarifs de ClickUp
Idéal pour : les équipes Scrum gérant plusieurs sprints, des dépendances partagées et des charges de travail variables, qui ont besoin de gérer leur backlog, de planifier leurs capacités et de produire des rapports sur l’avancement au sein d’un même environnement de travail. Cette solution convient également aux équipes qui coordonnent le travail des sprints avec des projets produit ou métier plus larges.
À éviter si : votre équipe n'a besoin que d'un tableau Scrum basique avec un backlog restreint et des rapports minimalistes. La flexibilité de ClickUp s'accompagne de choix d'installation concernant les paramètres de sprint, les vues et les champs. Certaines fonctionnalités avancées de reporting et d'automatisation des sprints nécessitent également des forfaits d'abonnement supérieurs, ce qui peut s'avérer inutile pour un flux de travail simple.
Dans quelle mesure faut-il planifier avant le début d’un sprint ?
Une session de planification de sprint doit permettre à l'équipe d'avoir une vision suffisamment claire pour se mettre au travail.
L'agenda chronométré et l'exemple de calcul de capacité ci-dessus constituent un point de départ. Adaptez-les à la charge de travail de l'équipe, puis comparez les prévisions avec le travail achevé et les interruptions afin d'améliorer la prochaine session.
Dans ClickUp, vous pouvez associer des notes de planification aux tâches du sprint et mettre à jour le backlog du sprint à mesure que le travail évolue. L'équipe peut se référer au plan convenu pour décider des ajustements à apporter.
Foire aux questions sur la planification de sprint
Quelle est la différence entre la planification de sprint et la planification de version ?
La planification de sprint se concentre sur ce que votre équipe vise à accomplir au cours d’un sprint et sur la manière dont elle va mener à bien ce travail. La planification de version s’inscrit dans une perspective à plus long terme : elle permet notamment de déterminer quelles fonctionnalités pourraient être disponibles sur plusieurs sprints et à quel moment les utilisateurs pourraient en bénéficier. Les prévisions de version peuvent évoluer à mesure que les équipes en savent plus, tandis que chaque objectif de sprint guide le travail au sein du sprint en cours.
Avez-vous besoin d'une « définition de prêt » pour la planification de sprint ?
Non. Scrum n’exige pas de « définition de prêt » formelle. Certaines équipes en utilisent une pour définir des attentes communes concernant les éléments du backlog avant leur sélection, telles que des exigences claires, un périmètre gérable et des dépendances connues. Veillez à ce que ces critères restent suffisamment souples pour faciliter la discussion sans empêcher l’équipe d’affiner les éléments si nécessaire.
Un sprint peut-il être annulé après la planification ?
Oui. Seul le Product Owner peut annuler un sprint, et l’annulation est envisageable lorsque l’objectif du sprint devient obsolète, par exemple en raison d’un changement significatif des priorités de l’entreprise ou des conditions du marché. Une tâche difficile ou une estimation imprécise ne justifie pas à elles seules l’annulation.
Quelle est la différence entre un sprint et la méthode agile ?
L'agilité est une approche plus large de la gestion du travail, fondée sur les valeurs et les principes du Manifeste Agile. Dans le cadre de la méthode Scrum, un sprint est une période fixe d'un mois ou moins, au cours de laquelle une équipe travaille à la réalisation d'un objectif de sprint et crée un incrément utilisable. Il est possible de suivre les principes agiles sans recourir aux sprints. La méthode Kanban, par exemple, favorise un flux de travail continu sans nécessiter d'itérations de durée fixe.
Un sprint peut-il comporter plusieurs objectifs ?
Dans Scrum, l’objectif du sprint est défini comme l’objectif unique de celui-ci. Vous pouvez sélectionner des éléments du backlog qui soutiennent d’autres priorités, à condition qu’ils ne compromettent pas cet objectif. Si votre équipe a régulièrement besoin de plusieurs objectifs sans lien entre eux, discutez avant la planification pour déterminer si le travail contribue à un résultat commun plus large ou s’il faut d’abord résoudre les priorités contradictoires.
Faut-il estimer les bugs en points de story lors de la planification du sprint ?
Les points de story sont facultatifs dans Scrum, y compris pour les bugs. Les équipes qui estiment les bugs doivent se mettre d’accord sur le moment et la raison de cette estimation. Les défauts connus peuvent être évalués lors de la planification, tandis que les bugs découverts au cours du développement peuvent s’inscrire dans le travail déjà nécessaire pour respecter la définition du « terminé ». Évitez de comptabiliser deux fois le même effort.