Planification de sprint

Article
03/04/2013

De Mitch Lacey.Propriétaire, Mitch Lacey & Associates, Inc, un société de conseils spécialisée dans les adoptions et améliorations Agile et Scrum.

Janvier 2012.

La planification du Sprint n'a pas besoin d'être difficile.Il est souvent amusant et bienvenu pour toute l'équipe Scrum d'établir es liens de camaraderie en travaillant ensemble pour répondre à la question « À quoi pouvons-nous nous engager ? » Dans cet article, les auteurs fournissent des exemples et des stratégies pour que la planification de sprint reste orientée et efficace, et détaillent des solutions potentielles pour les problèmes courants que rencontrent les équipes lors de la planification d'un sprint.

S'applique à

Gestion du cycle de vie des applications ; Team Foundation Server

Dans cet article :

Introduction
Prévision et validation
Qu'est-ce que la planification de sprint ?
Comment l'accomplissons-nous ?
Problèmes courants
- Scénario : l'équipe ne peut pas s'engager dans tous les récits que le propriétaire du produit a demandé.
- Scénario : le propriétaire du produit n'est pas préparé.
- Scénario : la partie 1 dépasse son délai.
- Scénario : la partie 2 dépasse son délai.
- Scénario : le propriétaire du produit n'est pas disponible.
- Scénario : l'équipe n'a pas les critères d'acceptation dont elle a besoin.
- Scénario : le propriétaire du produit ne sait pas ce qui terminé signifie.
- Scénario : le ScrumMaster ou le propriétaire du produit estime/influence les estimations/le travail de l'équipe.
Conclusion

Nous ne planifions pas.Nous procédons au Scrum, nous nous contentons donc d'exécuter.

J'entends cela tout le temps.Certaines personnes pensent que les méthodes Scrum et Agile signifient aucune planification, aucune évaluation, aucune réunion, rien !C'est totalement faux.Nous prévoyons plusieurs niveaux dans un projet agile : planification quotidienne ou réunion quotidienne, planification hebdomadaire (journal des sprints en souffrance ou des itérations en souffrance), plan de version (journal des travaux en souffrance du produit), et éventuellement plus.

Concentrons-nous sur la planification d'un sprint.

Prévision et validation

Pendant l'été 2011, Ken Schwaber et Jeff Sutherland ont revu leur guide Scrum.En son sein, ils ont supprimé un comportement généré depuis longtemps et connu du Scrum, qui est l'engagement de l'équipe pris auprès du propriétaire de produit et des clients.La validation a été remplacée par forecast.Ils disent que les équipes peuvent prédire leur travail, mais qu'elles ne s'y engagent pas.

Lorsque je comprends leur logique, je préfère l'engagement pour les raisons suivantes :

L'engagement spécifique place l'équipe dans une autre mentalité qui dépasse la simple prévision.Si une équipe effectue des prévisions, il est implicite que le fait de ne pas réaliser tout ce qu'elle a dit pouvoir faire est un comportement acceptable.Alors que les équipes peuvent apprendre de leurs prévisions, en ayant finalement moins de variations au niveau des estimations, je trouve que les équipes qui prévoient prennent plus de temps pour réduire la variation par rapport aux équipes qui valident.
La prévision ou l'évaluation est appropriée pour le journal des travaux en souffrance du produit.Toutefois, lorsque les équipes déplacent des récits du journal des travaux en souffrance du produit vers le journal des sprints en souffrance et les décomposent, elles ajoutent un autre niveau de granularité, en recherchant les petits détails qui leur permettent de se poser la question « pouvons-nous faire cela ? » Les prévisions courent le risque de retomber à un état tardif pour l'équipe au lieu de simplement dire « nous devons uniquement faire des prévisions, il est normal que nous omettions des choses, nous pourrons y revenir intégralement plus tard. »

Et sur une remarque plus légère, imaginez si vous disiez à votre épouse, époux, partenaire « J'ai prévu que nous resterions ensemble pendant dix ans » ou « je me suis engagé à tes côtés » – oui, tout ira très bien.

En définitive, Scrum ne tient que du bon sens.Je vous propose d'essayer à la fois l'approche d'engagement et l'approche de prévision.Il est question d'apprentissage et non des mots que vous utilisez. Soyez intelligent, testez les deux et utilisez la solution la mieux adaptée pour vous, votre équipe et votre société.

Qu'est-ce que la planification de sprint ?

Nous tenons une réunion de planification des sprints pour planifier ce que l'équipe générera dans le sprint suivant et comment elle procédera pour ce faire.Bien que nous l'appelions la réunion de planification de sprint, elle se compose en réalité de deux parties très différentes.La première partie se concentre sur ce que l'équipe doit créer et est suivie par le propriétaire du produit et l'équipe.La deuxième partie se concentre sur la manière dont l'équipe envisage de générer les fonctionnalités souhaitées.Toute l'équipe doit assister à la 2ème partie, mais la présence du propriétaire du produit est facultative.Si, pour une raison quelconque, le propriétaire du produit n'assiste pas à la partie 2, ce dernier devra rester disponible en cas de questions.

Dans la partie 1 de la réunion de planification de sprint, le propriétaire du produit a la possibilité de décrire un ensemble de récits souhaité pour l'équipe.Il s'agit d'une session approfondie sur la partie contenu des récits.Le propriétaire du produit présente les récits, montre comment les différents éléments interagissent et parcourt l'interface.En outre, ils peuvent examiner l'infrastructure ou les éléments architecturaux.L'objectif est de fournir assez d'informations aux membres de l'équipe pour qu'ils puissent savoir comment commencer à créer la fonctionnalité.L'équipe doit poser des questions afin de rassembler les informations utiles à la réunion de préparation, par exemple :

« Quels sont les critères d'acceptation de tous ces récits ? »
« À votre avis, quelles sources de données utilisons-nous ? »
« Comment doit se présenter l'interface sur ce composant ? »

Au cours de la partie 2 de la réunion de planification des sprints, l'équipe oriente son attention sur la génération du journal des sprints en souffrance, liste des récits et des tâches requises à accomplir pendant le sprint.Pour générer le journal des travaux en souffrance, l'équipe décompose chaque récit que le propriétaire du produit a demandé au niveau de la tâche ; chaque tâche reçoit une estimation horaire.À la fin de la partie 2, l'équipe décide des récits sur lesquels elle peut s'engager au cours du sprint.

Ensemble, les deux parties de la réunion de planification sprint peuvent prendre de deux à huit heures.La règle empirique générale que j'utilise est que chaque partie doit durer une heure pour chaque semaine de Sprint.Cela signifie que si j'exécute des sprints d'une semaine, la réunion prendra en tout deux heures (une heure pour la partie 1 et une heure pour la partie 2).Si, en revanche, je participe à des sprints durant quatre semaines, la réunion prendra un total de huit heures (quatre heures pour la partie 1 et quatre heures pour la partie 2).

Comment l'accomplissons-nous ?

Tant que l'équipe quitte la réunion de planification de sprints en s'engageant à compléter une liste de récits, elle a réalisé l'objectif de la planification des sprints.Obtention de l'équipe au point où chaque membre de l'équipe se sent à l'aise pour remplir cet engagement, toutefois, requiert un peu de préplanification et de facilitation.

Le propriétaire du produit a un travail à effectuer pendant la planification de sprint : décrire un ensemble de récits pendant la réunion.L'objectif de l'équipe est de comprendre les récits du point de vue du propriétaire de produit, afin de partager la vision du propriétaire de produit.Le Scrum Master doit s'assurer que l'équipe pose suffisamment de questions et qu'elle collecte l'ensemble des données résultantes, y compris les critères d'acceptation, les ébauche et les hypothèses.Le Scrum Master doit également prévenir le propriétaire du produit que l'équipe est susceptible de poser d'autres questions une fois qu'elle commence à diviser les questions en tâches.Bien que le propriétaire du produit présente des récits dont le total de points correspond approximativement à la rapidité historique de l'équipe, l'équipe décidera en dernier ressort si elle peut prendre tous les récits d'un sprint donné en fonction de ce qu'elle apprendra pendant les 1ère et 2ème parties de la réunion de planification de sprint.

Une fois que l'équipe a obtenu toutes les informations du propriétaire du produit, elle doit décomposer les récits en tâches et créer un journal des sprints en souffrance, qui capture les récits, remarques, critères d'acceptation, tâches et estimations pour un sprint particulier.S'il y a plusieurs méthodes pour ce faire, j'utilise la méthode suivante, qui tire parti des idées des idées de tous les membres de l'équipe et donne à chacun une voix dans la décomposition des tâches.

Faites en sorte que le Scrum Master ou le facilitateur de réunion lise d'un trait un récit et demande, « Est-ce que tout le monde a bien compris ce récit ? » En réalité, l'équipe devrait avoir tout compris, puisqu'elle a passé du temps à en discuter avec le propriétaire du produit.Si une autre personne de l'équipe ne comprend pas, reparcourez le récit en vous interrogeant sur des questions pertinentes relatives au propriétaire du produit.
Ensuite, dites à chaque membre de l'équipe de prendre un bloc de post-its.Demandez à chaque membre de l'équipe d'écrire une tâche unique sur chaque note et de la placer au milieu de la table.
- Chaque fois que le pense-bête est lancé au milieu de la table, le lanceur annonce la tâche.Si la « procédure stockée de mise à jour » est écrite, cela est clairement indiqué.C'est important, car cela suscitera des idées et incitera d'autres à dire « Au fait, nous devons mettre à jour la source de données ». À ce stade, quelqu'un écrira sur un papier « Mettre à jour la source de données » et l'annoncera.Cette activité de réflexion permet de réellement se débarrasser des tâches associées.Ne vous préoccupez pas des doublons à ce stade du processus.Pour chaque récit, il faut environ cinq à dix minutes pour supprimer tous les post-its.
Lorsque tous les post-its sont dans le tableau, il est temps de les trier.Mettez-les tous sur un mur, reculez et regardez : ça fait beaucoup de post-its !Commencez par identifier tous les doublons ; éliminez tous les post-its qui semblent être des doublons.Recherchez ensuite les tâches qui semblent avoir un lien, soit parce qu'elles sont semblables, soit parce qu'elles dépendent les unes des autres.Par exemple, si deux stickies ont une relation similaire, rassemblez-les en les décalant, comme le montre l'illustration suivante :

Si deux tâches sont donc étroitement liées au point d'être presque identiques, faites-les se chevaucher presque intégralement, comme indiqué ci-dessous :

En triant les post-its, l'équipe peut éliminer la liste des tâches et visualiser les relations entre celles qui restent.
Lorsque les tâches sont triées, il est temps de faire une estimation.J'utilise la technique de poker de planification pour l'évaluation des tâches, à la différence que les numéros sur les cartes représentent des heures au lieu de points.J'agis ainsi parce que les personnes ont tendance à trop se focaliser sur des détails inutiles par rapport aux heures, en particulier sur des tâches importantes.Leur appréhension est fondée.Trop souvent, les sociétés utilisent l'estimation comme un bâton pour battre l'équipe.« Vous avez dit qu'il faudrait 8 heures et il vous a fallu 12.Que s'est-il passé ? » ou « Vous aviez dit que cela vous prendrait 8 heures et il ne vous en a fallu que 4.Vous remplissez vos estimations. »

De la même façon que les cartes contribuent à conserver les estimations de points de récit abstraits, l'utilisation de cartes pour l'estimation des tâches permet à l'équipe de bénéficier de la liberté d'avoir un ensemble de numéros fixes à choisir tout en la forçant à finir par faire un choix.Cela élimine également les discussions passionnées consistant à déterminer si une tâche doit être estimée à 6 heures, 6,5 heures ou 7 heures.

Quelle que soit l'évaluation finale, rappelez-vous que l'évaluation est effectuée par l'équipe et n'est censée être utilisée par l'équipe que pour aider à améliorer sa confiance et à déterminer si elle peut effectuer le travail demandé par le propriétaire du produit en fonction de la rapidité.Les évaluations de tâches ne sont pas des métriques et ne doivent pas être utilisées en tant que telle.Ne jamais utiliser les évaluations comme arme contre l'équipe.
Maintenant que les tâches sont estimées, l'équipe doit déterminer si elle a la capacité d'accepter plus de travail.Pour ce faire, vous devez connaître la capacité de l'équipe, le nombre d'heures totales dont l'équipe dispose pendant le sprint.La détermination de la capacité est facile si vous disposez d'une équipe entièrement dédiée, en revanche, elle est plus difficile si vous avez une équipe composée de personnes à temps partiel qui sont réparties sur plusieurs projets.Demandez à chaque personne d'écrire le nombre d'heures qu'elle est prête à consacrer au projet par jour (ou le total par Sprint).Ajoutez tous les nombres pour obtenir le nombre total d'heures disponibles pour l'équipe.Disons que la capacité de l'équipe s'avère être de 200 heures.Si la somme des tâches d'un récit est évaluée à une utilisation de 30 heures, l'équipe doit se poser la question suivante : « Pouvons-nous prendre plus de travail ? ». À cette étape, la réponse est évidemment Oui.

Comme vous avez plus de capacité, passez au récit suivant et répétez les étapes une à cinq.

(Pour plus d'informations sur l'exécution de cette tâche à l'aide de Team Foundation Server, consultez Planification et itérations Agile).

À un moment donné, vous aurez du mal à répondre à la question « Est-ce qu'on peut travailler davantage ? » C'est parce que la capacité de votre équipe arrive à saturation.Lorsque vous naviguez dans ce processus, pensez à ne pas remplir la capacité du Sprint.Si vous remplissez un verre d'eau à ras bord, il a des chances de se renverser.Il en va de même pour les sprints.Si les heures estimées consomment tout le temps disponible et qu'une nouvelle tâche est identifiée ultérieurement dans le sprint, les choses prennent alors une nouvelle tournure.Vous devez laisser de l'espace pour les tâches émergentes.

Si l'on considère l'engagement sprint, cela permet de prendre en compte les données rétrospectives des sprints passés.L'équipe doit-elle systématiquement fournir plus de travail ?L'équipe peut peut-être s'engager à faire plus pendant la planification du Sprint.L'équipe est-elle systématiquement incapable de finir le travail complet pour un sprint ?L'équipe devra peut-être être plus conservatrice avec ses engagements jusqu'à ce qu'elle ait traité la cause première des sprints incomplets.

Une façon de mettre un nombre sur la question « comment remplir votre verre » consiste à prendre en compte la croissance de la taille du plan.La croissance de la taille du plan évalue les heures passées réelles par rapport aux évaluations initiales.Disons, par exemple, que notre équipe a une capacité de 200 heures disponibles.En fonction des estimations, l'équipe s'engage pour 190 heures.À la fin du sprint, l'équipe calcule un volume de 240 heures réelles de travail dans ces récits, ce qui entraîne une augmentation du plan de 20 %.

Une équipe qui identifie cette différence doit consacrer du temps pendant la rétrospective à déterminer les raisons :

Est-ce que trop de tâches non identifiées pendant la planification ont été découvertes au moment de l'exécution ?
D'après son ensemble de compétences actuel, l'équipe sous-estime-t-elle ses tâches ?
L'équipe a-t-elle surestimé sa capacité ?
Etc.

Lorsqu'elle détermine si elle peut s'engager pour un récit, l'équipe doit également prendre en compte l'augmentation de la taille du plan au cours de la prochaine réunion de planification des sprints.Pour revenir à notre exemple, si l'équipe évalue toujours une capacité de 200 heures, l'équipe doit soustraire 20% du haut pour compenser la croissance de taille de plan « attendue » selon les données de l'historique.En d'autres termes, pour au moins ce sprint, pour éviter les dépassements, lorsque l'équipe atteint les 160 heures, elle doit se déclarer en capacité.

Prenez en compte la croissance de la taille du plan pour mesurer la capacité total du sprint.Réalise, cependant, que l'objectif n'est pas de correspondre exactement à la capacité.Au contraire, il s'agit de permettre à l'équipe de se sentir en confiance lors de la validation d'un nombre approprié de récits (un nombre qui pousse l'équipe sans la surcharger).La croissance de la taille du plan est simplement une méthode permettant de déterminer approximativement le taux de remplissage du Sprint suivant, si tous les autres facteurs restent égaux.

Lorsque tous les récits sont estimés ou que tout le temps est utilisé par des récits, revenez vers le propriétaire de produit et partagez le journal des sprints en souffrance que l'équipe s'est engagée à fournir.C'est maintenant que le Sprint commence : soyez prêt !

Problèmes courants

Au cours de mes années de consultance auprès des équipes pour les aider à adopter Scrum, j'ai rencontré ces mêmes problèmes qui empêchent la planification de sprint réussie.Bien que la planification de sprint semble simple, les équipes qui viennent de démarrer avec le Scrum rencontrent des difficultés.Beaucoup de ces problèmes et leurs solutions potentielles sont détaillés dans cette section.

Scénario : l'équipe ne peut pas s'engager dans tous les récits que le propriétaire du produit a demandé.

Vous devez vous attendre à ce que cela se produise de temps en temps.Tant que l'équipe peut prouver l'engagement avec des données des étapes quatre et cinq précédentes dans cette rubrique, le propriétaire du produit sera satisfait.Ouvrez l'œil pour vous assurer que l'erreur de validation n'est pas le résultat d'une condition de remplissage excessif ou de tâches volumineuses.Le Scrum Master doit contester les estimations qui semblent trop conservatrices afin de vérifier qu'elles sont exactes.Le propriétaire du produit doit remettre en question toute tâche dont l'évaluation comporte deux chiffres.Toute tâche dont la durée est susceptible de durer plus de deux jours ouvrés doit être décomposée en tâches plus petites et de nouveau estimée.Ceci est vrai pour tous les projets, mais cela préoccupe en particulier les équipes qui exécutent des Sprints d'une ou de deux semaines.

Scénario : le propriétaire du produit n'est pas préparé.

Le respect constitue l'une des valeurs de Scrum.Il est irrespectueux de venir à une réunion sans y être préparé.Que doit faire une équipe si le propriétaire du produit arrive sans les informations dont elle a besoin ?Il est possible de reporter la réunion jusqu'à ce que le propriétaire du produit soit prêt, mais cela ne fait qu'encourager le même comportement. Cette option doit être évitée.Une autre option consiste à annuler le sprint.Elle peut fonctionner, mais elle est extrême.

Je recherche la meilleure solution à obtenir en double.D'abord, le journal des travaux en souffrance du produit doit répondre à un tri par ordre de priorité, donc si le propriétaire du produit n'a pas un ensemble particulier de récits, l'équipe et le propriétaire du produit peuvent simplement discuter des récits par ordre de priorité jusqu'à ce qu'ils atteignent un point de capacité ou de surcapacité.L'équipe peut ensuite décider de l'engagement réel pendant la deuxième partie de la réunion, comme d'habitude.

Après la réunion, le Scrum Master doit s'efforcer de comprendre pourquoi le propriétaire du produit n'était pas préparé.Si le problème était une absence d'engagement, le Scrum Master peut indiquer au propriétaire du produit l'importance d'assister à la réunion préparée sur la base d'un ensemble de récits.Si, en revanche, le problème est que le propriétaire du produit n'a pas pu se préparer, peut-être parce que l'équipe n'a pas réussi à effectuer le nettoyage, le Scrum Master devra également aider à résoudre ces problèmes.

Scénario : la partie 1 dépasse son délai.

Une autre valeur a le focus.Si la partie 1 de la réunion est trop longue, cela est le signe symptomatique d'un manque de focus.Quelquefois le propriétaire du produit est à l'état unfocused en raison d'un manque de préparation, de définition de priorités ou de tentatives d'illustrer un trop grand nombre de récits.D'autres fois, le manque de focus peut provenir du fait que l'équipe mélange les conversations de type « quoi » les conversations de type « comment ».

Le Scrum Master doit contribuer à la bonne gestion du projet en insistant pour que l'équipe obtienne des explications sur le tableau et les récits du propriétaire du produit qui ne sont pas compris. Le Scrum Master doit également veiller à ce que l'équipe conserve la trace des discussions détaillées relatives à l'implémentation de la première partie.Un correctif simple pour la discussion unfocused consiste à utiliser un chronomètre ou une minuterie.

Scénario : la partie 2 dépasse son délai.

Encore une fois, le focus.Si vous avez une équipe qui parle beaucoup, quelquefois le fait de limiter les discussions peut s'avérer nécessaire pour ramener la réunion dans les rails.Utilisez un minuteur pour gardez la durée des conversations entre une et deux minutes entre les estimations de tâche.L'objectif est l'exactitude, et non la précision à 100 %.

Il peut aussi arriver qu'un manque de focus pendant la partie 2 indique un manque de nettoyage du journal des travaux en souffrance du produit pendant l'exécution du sprint.Le nettoyage s'effectue lorsque l'équipe peut examiner les futurs récits et utiliser le propriétaire du produit pour ajouter des récits ou des pics afin de mettre le doigt sur des instructions de conception ou des problèmes d'architecture d'adressage.Sans révision régulière du journal des travaux en souffrance du produit, la planification du journal des sprints en souffrance Sprint devient complexe et difficile.

Scénario : le propriétaire du produit n'est pas disponible.

Si le propriétaire du produit ne peut pas assister à la réunion pour une raison quelconque, et n'a pas appelé un proxy, agissez comme si le propriétaire du produit s'était rendu à la réunion non préparée.Examinez les éléments supérieurs et validez-les le mieux possible.Vous pouvez être tenté de modifier l'heure de la réunion pour qu'elle s'adapte au calendrier du propriétaire du produit.À ne pas faire.Le fait de décaler l'heure de la réunion arrange certaines personnes mais aux dépens de beaucoup d'autres.Cela n'en vaut pas la peine.

Scénario : l'équipe n'a pas les critères d'acceptation dont elle a besoin.

Je conseille toujours aux équipes d'interroger le propriétaire du produit pendant la phase 1 : « Quels sont les critères d'acceptation pour aboutir au résultat ? » ou « Que devons-nous faire pour que vous acceptiez ce travail ? » Si ces informations sont manquantes dans la phase 2 lorsque l'équipe détermine les tâches, l'équipe n'aura aucune idée de la fin du récit.Si l'équipe doit deviner, en fonction de ce qu'elle a entendu dans la partie 1, elle court le risque de voir le propriétaire de produit décider à la fin du sprint que le récit n'est pas terminé.Demandez les critères d'acceptation au départ pour chaque récit.ScrumMasters : accompagnent les propriétaires de produits pour fournir ces données.

Scénario : le propriétaire du produit ne sait pas ce qui terminé signifie.

Tout comme l'équipe veut des critères d'acceptation, le propriétaire du produit mérite une description actualisée de ce l'équipe entend par « Le récit est terminé. ». Cette liste approuvée doit être publiée distinctement, mise à jour et doit être disponible à tout moment pour le propriétaire du produit.Une liste obsolète rend la planification difficile parce que le travail réalisé peut donner lieu à de multiples interprétations.Assurez-vous que la mise à jour de la liste approuvée fait partie de chaque révision ou rétrospective du sprint.

Scénario : le ScrumMaster ou le propriétaire du produit estime/influence les estimations/le travail de l'équipe.

Le propriétaire du produit est le bienvenu dans la deuxième partie de la réunion, mais son rôle doit seulement consister à clarifier une spécification ou à répondre à une question spécifique.Le propriétaire du produit ne doit jamais interférer avec l'équipe lors des discussions relatives à l'implémentation d'un récit et ne doit pas donner son point de vue en ce qui concerne l'estimation d'une tâche.Le propriétaire du produit doit faire confiance à l'équipe pour l'exécution du travail.

Si le propriétaire du produit agit différemment de ces instructions, le Scrum Master doit orienter le propriétaire du produit vers un rôle plus approprié.Si le propriétaire du produit refuse de recevoir un rôle plus passif, le Scrum Master a l'autorité suffisante pour demander au propriétaire du produit de quitter le projet.

La planification du Sprint n'a pas besoin d'être difficile.Il est souvent amusant et bienvenu pour toute l'équipe Scrum d'établir des liens de camaraderie en travaillant ensemble pour répondre à la question « À quoi pouvons-nous nous engager ? N'oubliez pas que si vous trouvez vos réunions longues, cela provient probablement de problèmes avec une cause première.Si vous êtes le Scrum Master, maintenez la réunion concentrée en vérifiant que le propriétaire du produit et l'équipe nettoient le journal des travaux en souffrance du produit.Permettre au propriétaire du produit de se préparer en ayant des critères d'acceptation des récits prêts avant la réunion.Enfin, faites en sorte que le propriétaire du produit et l'équipe correspondante restent concentrés sur la tâche en cours (déterminer leurs engagements pour le sprint).