Planification de sprint

Article
06/10/2015

Par Mitch Lacey. Propriétaire : Mitch Lacey & Associates, Inc, cabinet de consultants spécialisé dans l'adoption et l'amélioration des pratiques Agile et Scrum.

Janvier 2012.

S'applique à

Gestion du cycle de vie des applications ; Team Foundation Server

Dans cet article :

Introduction
Prévisions et engagement
Qu'est-ce que la planification de sprint ?
Comment y parvenir ?
Problèmes courants
- Scénario : l'équipe ne peut pas s'engager à transposer tous les récits, comme le demande le directeur de produit.
- Scénario : le directeur de produit n'est pas préparé.
- Scénario : la première partie dépasse son délai imparti.
- Scénario : la seconde partie dépasse son délai imparti.
- Scénario : le directeur de produit n'est pas disponible.
- Scénario : l'équipe ne dispose pas des critères d'acceptation dont elle a besoin.
- Scénario : le directeur de produit ne sait pas ce que signifie « Terminé ».
- Scénario : le directeur de produit ou ScrumMaster estime/influence les estimations/le travail de l'équipe.

Nous ne planifions pas. Nous suivons la méthode Scrum et nous contentons d'exécuter des tâches.

J'entends cela tout le temps. Les gens pensent que Scrum et Agile signifient l'absence de planification, d'estimation, de réunions, de tout ! Rien n'est moins vrai. Nous planifions à différents niveaux dans un projet Agile, comme en témoignent, entre autres, le plan quotidien ou les réunions quotidiennes, les plans hebdomadaires (journal des travaux en souffrance des sprints ou des itérations) et le plan de publication (journal des travaux en souffrance du produit).

Concentrons-nous sur la planification d'un sprint.

Prévisions et engagement

Au cours de l'été 2011, Ken Schwaber et Jeff Sutherland ont révisé leur Guide de Scrum. De ce dernier, ils ont supprimé un comportement de longue date spécifique de Scrum, à savoir l'engagement de l'équipe auprès du directeur de produit et des clients. L'engagement a été remplacé par la prévision. Ils affirment que les équipes peuvent prévoir leur travail, mais ne pas s'y engager.

Tout en comprenant leur logique, je préfère l'engagement pour les raisons suivantes :

L'engagement vis-à-vis de quelque chose ne place pas l'équipe dans le même état d'esprit que la seule prévision. Si une équipe prévoit, cela implique qu'il serait acceptable que chaque objectif annoncé comme réalisable ne soit pas atteint. Bien que les équipes puissent tirer des leçons de leurs prévisions, réduisant ainsi l'écart par rapport aux estimations, je trouve que les équipes qui prévoient mettent plus de temps à réduire l'écart que les équipes qui s'engagent.
La prévision, ou estimation, est appropriée pour le journal des travaux en souffrance du produit. Toutefois, quand les équipes déplacent les récits du journal des travaux en souffrance du produit vers le journal des travaux en souffrance des sprints et qu'elles les décomposent, elles ajoutent un niveau de granularité, et les petits détails qu'elles trouvent alors les amènent à se poser la question « Pouvons-nous nous engager là-dessus ? ». La prévision fait courir à l'équipe le risque de la paresse sur le mode « nous devons simplement prévoir, ce n'est pas un problème si quelque chose nous échappe, nous pourrons y remédier ultérieurement ».

Sur une note plus légère, imaginez que vous disiez à votre femme, mari ou concubin(e) « je prévois que nous vivrons ensemble dix ans » au lieu de « je m'engage auprès de toi » : avouez que l'effet ne sera pas le même.

En fin de compte, Scrum est une question de bon sens. Je vous suggère d'essayer l'approche de l'engagement et l'approche de la prévision. Tout est affaire d'apprentissage, et les mots employés importent peu ; alors, agissez de manière intelligente, expérimentez les deux approches et utilisez celle qui convient le mieux à votre équipe, à votre entreprise et à vous-même.

Qu'est-ce que la planification de sprint ?

Une réunion de planification de sprint permet de planifier le contenu que l'équipe mettra en place pendant le sprint à venir et comment elle s'y prendra. Bien que nous l'appelions réunion de planification de sprint, la réunion comprend en réalité deux parties très différentes. La première partie porte sur ce qui a été demandé à l'équipe de mettre en place et réunit le directeur de produit et l'équipe. La seconde partie est consacrée à la façon dont l'équipe envisage de mettre en place la fonctionnalité souhaitée. Bien que toute l'équipe doive participer à la seconde partie, la présence du directeur de produit est facultative. Si, pour quelque raison que ce soit, le directeur de produit ne participe pas à la seconde partie, il doit rester disponible pour répondre aux questions éventuelles.

Au cours de la première partie de la réunion de planification de sprint, le directeur de produit peut décrire un ensemble de récits souhaité à l'équipe. Il s'agit d'une séance approfondie portant sur le contenu des récits. Le directeur de produit présente les récits, souligne les différentes interactions et parcourt l'interface. En outre, il peut examiner l'infrastructure ou les éléments de l'architecture. L'objectif est de communiquer à l'ensemble des membres de l'équipe suffisamment d'informations pour qu'ils entrevoient comment mettre en place la fonctionnalité. L'équipe posera de nombreuses questions pour recueillir des informations quant à la partie de la réunion qui portera sur le comment, par exemple :

« Quels sont les critères d'acceptation de tous ces récits ? »
« Quelles sources de données pensez-vous que nous utilisons ? »
« Quelle forme l'interface doit-elle prendre sur ce composant ? »

Pendant la seconde partie de la réunion de planification de sprint, l'équipe se concentre sur la création du journal des travaux en souffrance des sprints, qui contient la liste des récits et les tâches à effectuer pour ceux-ci au cours du sprint. Pour créer le backlog, l'équipe décompose en tâches chaque récit demandé par le directeur de produit ; chaque tâche se voit affecter une durée estimée en heures. Avant la fin de la seconde partie, l'équipe détermine les récits qu'elle peut s'engager à terminer pendant le sprint.

Ensemble, les deux parties de la réunion de planification de sprint peuvent durer entre deux et huit heures. En règle générale, je considère que chaque partie doit durer une heure par semaine que compte le sprint. Ainsi, dans le cas d'un sprint d'une semaine, la réunion doit durer deux heures en tout (une heure pour la première partie et une autre pour la seconde partie). De même, dans le cas d'un sprint de quatre semaines, la réunion doit durer huit heures en tout (quatre heures pour la première partie et quatre autres pour la seconde partie).

Comment y parvenir ?

Si l'équipe quitte la réunion de planification de sprint avec l'engagement de terminer une liste de récits, elle a atteint l'objectif de la planification de sprint. Toutefois, certaines dispositions relatives à la préparation de la planification et à son déroulement doivent être mises en œuvre pour que tous les membres de l'équipe se sentent à l'aise au moment de la prise de cet engagement.

Le directeur de produit remplit une tâche pendant la planification de sprint : se présenter à la réunion en étant à même de décrire un ensemble de récits souhaités. L'objectif de l'équipe est de comprendre les récits du point de vue du directeur de produit, afin de partager la vision de ce dernier. Le ScrumMaster doit s'assurer que l'équipe pose suffisamment de questions et qu'elle réunit toutes les données collectées, notamment les critères d'acceptation, les ébauches et les hypothèses éventuelles. Le ScrumMaster doit également indiquer au directeur de produit que l'équipe est susceptible d'avoir des questions supplémentaires une fois qu'il commence à décomposer les questions en tâches. Bien que le directeur de produit présente des récits dont les points sont généralement en phase avec le rythme de travail habituel de l'équipe, celle-ci décide au bout du compte si elle peut effectivement prendre en charge tous les récits dans un sprint donné, en fonction de ce qu'elle a appris pendant les première et seconde parties de la réunion de planification de sprint.

Une fois que l'équipe a obtenu toutes les informations auprès du directeur de produit, elle doit décomposer les récits en tâches et créer un journal des travaux en souffrance des sprints, qui rassemble la totalité des récits, notes, critères d'acceptation, tâches et estimations pour un sprint particulier. Bien qu'il existe de nombreuses façons d'effectuer cette opération, j'utilise la méthode suivante, qui tire parti des idées de tous les membres de l'équipe et permet à chacun de s'exprimer sur la décomposition des tâches.

Demandez au ScrumMaster ou à l'animateur de la réunion de lire un récit et de poser la question « Quelqu'un le comprend-il ? ». Normalement, l'équipe doit le comprendre, car elle vient d'en discuter avec le directeur de produit. Si un membre de l'équipe ne comprend pas le récit, prenez le temps de revisiter celui-ci, en posant toutes les questions nécessaires au directeur de produit.
Ensuite, demandez à chaque membre de l'équipe de se saisir d'un bloc de papiers adhésifs, puis d'écrire une seule tâche sur chaque papier et de jeter celui-ci au milieu de la table.
- Chaque fois qu'un membre de l'équipe jette un papier adhésif au milieu de la table, il annonce la tâche. Ainsi, si le texte écrit est « mettre à jour la procédure stockée », il doit être prononcé à voix haute. Cela est important, car de nouvelles idées peuvent émerger, un autre membre pouvant alors enchaîner en disant « Oh oui, et nous devons mettre à jour la source de données ». Quelqu'un écrira alors « mettre à jour la source de données » sur un papier adhésif et jettera celui-ci au milieu de la table. Ce remue-méninges est particulièrement efficace pour faire jaillir toutes les tâches associées. Ne vous inquiétez pas des doublons à ce stade. En règle générale, la séance du jet de tous les papiers adhésifs sur lesquels sont notées les tâches prend environ entre cinq et dix minutes par récit.
Quand tous les papiers adhésifs sont sur la table, il est temps de les trier. Collez-les tous sur un mur, reculez et observez : cela fait beaucoup de papiers adhésifs ! Commencez par identifier les doublons éventuels ; collez les uns sur les autres les papiers adhésifs qui s'apparentent à des doublons. Ensuite, recherchez les tâches qui semblent aller ensemble, soit en raison de leur similitude, soit à cause de leur interdépendance. Par exemple, s'il existe une relation entre deux papiers adhésifs, placez-les ensemble en les décalant, comme le montre l'illustration suivante :

Si deux tâches sont liées au point d'être pratiquement identiques, superposez-les presque complètement, comme illustré ci-après :

En triant les papiers adhésifs, l'équipe peut réduire la liste des tâches et visualiser les relations entre les tâches restantes.
Une fois les tâches triées, vous pouvez passer à la phase d'estimation. J'utilise la technique du Planning Poker pour estimer les tâches, avec une différence toutefois : les nombres sur les cartes ne représentent pas des points, mais des heures. Je procède ainsi, car les gens ont tendance à trop s'attarder sur des détails superflus concernant les heures, notamment dans le cas des tâches de grande ampleur. Leur anxiété s'explique très bien. Trop souvent, les entreprises utilisent l'estimation comme un bâton pour battre l'équipe. « Vous aviez dit que cela prendrait 8 heures, et 12 heures vous ont été nécessaires. Que s'est-il passé ? » ou « Vous aviez dit que cela prendrait 8 heures, et seules 4 heures ont été nécessaires. Vos estimations sont surévaluées. »

De la même façon que les cartes préservent le caractère abstrait des estimations des points de récit, leur utilisation pour l'estimation des tâches amène l'équipe à effectuer en toute liberté un choix parmi un ensemble de nombres prédéfinis. En outre, ce procédé élimine les débats passionnés quant au fait de savoir si la durée d'une tâche doit être estimée à 6, 6,5 ou 7 heures.

Quelle que soit l'estimation finale, gardez à l'esprit que la phase d'estimation est effectuée par l'équipe et que sa seule vocation est de lui permettre de gagner en confiance et de déterminer si elle peut accomplir le travail que le directeur de produit a demandé en fonction du rythme de travail habituel. Les estimations des tâches ne sont pas des mesures et ne doivent pas être utilisées en tant que telles. N'utilisez jamais les estimations comme une arme contre l'équipe.
Une fois les tâches estimées, l'équipe doit déterminer si elle peut prendre en charge davantage de travail. Pour ce faire, vous devez connaître la capacité de l'équipe, c'est-à-dire le nombre total d'heures dont dispose l'équipe pendant le sprint. La détermination de la capacité est facile si tous les membres de l'équipe travaillent exclusivement sur votre projet, mais devient plus difficile si certains membres consacrent du temps à d'autres projets. Demandez à chacun de noter le nombre d'heures qu'il peut consacrer au projet par jour (ou le nombre total d'heures par sprint). Faites la somme de tous les nombres pour obtenir le nombre total d'heures disponibles pour l'équipe. Supposons que la capacité de l'équipe s'élève à 200 heures. Si la somme des tâches pour un récit est estimée à 30 heures, posez à l'équipe la question « Pouvons-nous prendre en charge davantage de travail ? ». À ce stade précoce, la réponse est évidemment « oui ».

Comme vous disposez d'une marge en termes de capacité, passez au récit suivant, et répétez les étapes 1 à 5.

(Pour plus d'informations sur la façon d'accomplir cette tâche à l'aide de Team Foundation Server, consultez Collaborer [redirection].)

À un moment donné, il sera difficile de répondre à la question « Pouvons-nous prendre en charge davantage de travail ? ». En effet, vous vous rapprochez de la capacité de votre équipe. Au cours de ce processus, évitez de remplir le sprint à sa capacité maximale. Si vous remplissez complètement un verre d'eau, vous risquez d'en 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 pendant le sprint, vous serez confronté à un débordement. Vous devez prévoir de la place pour les tâches émergentes.

Quand vous analysez l'engagement à respecter pour un sprint, pensez à vous appuyer sur les données des sprints passés. L'équipe a-t-elle systématiquement eu besoin de prendre en charge davantage de travail ? Peut-être peut-elle s'engager à effectuer davantage de travail pendant la planification du sprint. L'équipe a-t-elle été systématiquement incapable de terminer tout le travail relatif à un sprint ? Peut-être l'équipe doit-elle modérer ses engagements jusqu'à ce qu'elle ait résolu le problème qui l'empêche de terminer les sprints.

Pour traduire en chiffres la question « jusqu'où faut-il remplir votre verre », vous pouvez prendre en compte la croissance de la taille du plan. La croissance de la taille du plan permet de comparer les heures réelles travaillées aux estimations initiales. Supposons que notre équipe ait une capacité de 200 heures disponibles. Elle s'engage sur une durée qu'elle estime à 190 heures. À la fin du sprint, les calculs qu'elle effectue montrent que les récits concernés ont représenté 240 heures de travail réelles, soit une croissance de 20 % de la taille du plan.

Quand une équipe constate un écart de cette ampleur, elle doit en rechercher les causes pendant la rétrospective :

Existe-t-il un nombre trop élevé de tâches découvertes pendant l'exécution qui n'avaient pas été identifiées pendant la planification ?
L'équipe sous-estime-t-elle les tâches à effectuer au regard de ses compétences ?
L'équipe surestime-t-elle ses capacités ?
Etc.

L'équipe doit également prendre en compte la croissance de la taille du plan pendant la prochaine réunion de planification de sprint au moment de déterminer si elle peut s'engager à transposer un récit. Pour en revenir à notre exemple, si l'équipe estime toujours une capacité de 200 heures, elle doit soustraire 20 % pour compenser la croissance « attendue » de la taille du plan compte tenu des données d'historique. En d'autres termes, pour au moins ce sprint et afin d'éviter les débordements, l'équipe doit considérer qu'au bout de 160 heures elle a atteint sa capacité.

Prendre en compte la croissance de la taille du plan permet de déterminer le niveau de remplissage du sprint. Toutefois, gardez à l'esprit que l'objectif n'est pas exactement d'atteindre la capacité, mais plutôt de permettre à l'équipe de s'engager en toute confiance sur la transposition d'un nombre approprié de récits, nombre suffisamment élevé pour occuper l'équipe, sans toutefois la surcharger. Analyser la croissance de la taille du plan est simplement une façon de déterminer approximativement le niveau de remplissage souhaité pour le prochain sprint, dans l'hypothèse où tous les autres facteurs demeurent inchangés.

Quand tous les récits sont estimés ou que la totalité du temps est consommée par les récits, tournez-vous vers le directeur de produit et partagez le journal des travaux en souffrance des sprints que l'équipe s'est engagée à livrer. Le sprint commence à ce moment-là —alors, au travail !

Problèmes courants

Au cours des années pendant lesquelles j'ai conseillé des équipes sur l'adoption de la méthode Scrum, j'ai constaté de nombreux problèmes récurrents entraînant l'échec de la planification des sprints. Bien que la planification des sprints semble simple, les équipes qui débutent avec Scrum ont tendance à éprouver certaines difficultés. Nombre de ces problèmes et les solutions correspondantes éventuelles sont détaillés dans cette section.

Scénario : l'équipe ne peut pas s'engager à transposer tous les récits, comme le demande le directeur de produit.

Cette situation est susceptible de se présenter à vous de temps en temps. Dans la mesure où l'équipe peut tenir son engagement sur la base des données obtenues aux étapes 4 et 5 décrites précédemment dans cette rubrique, le directeur de produit doit être satisfait. Vous pouvez surveiller le déroulement des opérations pour vous assurer que l'échec de l'engagement n'est pas dû à une surcharge ou à des tâches volumineuses. Le ScrumMaster doit vérifier la précision des estimations qui lui semblent trop prudentes. Le directeur de produit doit remettre en cause toute tâche dont la durée est estimée à au moins 10 heures. Toute tâche dont la durée estimée est supérieure à deux jours ouvrés doit être décomposée en tâches plus petites et faire l'objet d'une nouvelle estimation. Cela vaut pour tous les projets, mais concerne particulièrement les équipes qui exécutent des sprints d'une ou deux semaines.

Scénario : le directeur de produit n'est pas préparé.

Une valeur de la méthode Scrum est le respect. Il est irrespectueux de se rendre à une réunion sans s'être préparé. Que peut faire une équipe si le directeur de produit se présente sans les informations dont elle a besoin ? Une option pourrait consister à reporter la réunion jusqu'à ce que le directeur de produit soit prêt, mais cela ne ferait que repousser le problème ; évitez cette solution. Une autre option consiste à annuler le sprint. Bien que cette solution puisse fonctionner, elle est extrême.

Je pense que la meilleure solution présente deux volets. Tout d'abord, le journal des travaux en souffrance du produit doit être plus ou moins hiérarchisé, afin que si le directeur de produit se présente sans un ensemble de récits particulier, l'équipe et lui-même puissent simplement discuter des récits dans l'ordre de priorité jusqu'à ce que la capacité soit, à leurs yeux, atteinte ou sur le point d'être franchie. L'équipe peut ensuite décider de l'engagement exact pendant la seconde partie de la réunion, comme à son habitude.

Après la réunion, le ScrumMaster doit analyser les raisons pour lesquelles le directeur de produit n'était pas préparé. Si le problème était un manque d'implication, le ScrumMaster peut sensibiliser le directeur de produit sur l'importance de se présenter à la réunion en ayant préparé un ensemble de récits. Si, par contre, le problème était que le directeur de produit ne pouvait pas se préparer, peut-être en raison d'un défaut de nettoyage de la part de l'équipe, le ScrumMaster doit œuvrer pour résoudre ces problèmes également.

Scénario : la première partie dépasse son délai imparti.

Une autre valeur est la concentration. Si la première partie de la réunion traîne en longueur, cela est symptomatique d'un manque de concentration. Parfois, le directeur de produit n'est pas concentré en raison d'un manque de préparation ou de hiérarchisation, ou d'un nombre trop élevé de récits à expliquer. Le manque de concentration peut également être dû au fait que l'équipe accorde de la place à la méthode au cours des conversations qui portent sur le contenu.

Le ScrumMaster doit favoriser le bon déroulement du processus en insistant pour que le directeur de produit ajourne les récits qui ne peuvent pas être complètement expliqués et pour que l'équipe n'aborde pas les détails de l'implémentation pendant la première partie. Pour éviter les discussions non structurées, une solution simple consiste à utiliser un chronomètre ou une horloge.

Scénario : la seconde partie dépasse son délai imparti.

Là encore, la concentration est de mise. Si l'équipe est trop bavarde, une discipline appropriée pour limiter les discussions suffit parfois pour que la réunion reprenne son cours normal. Apportez un minuteur et limitez les conversations à une ou deux minutes entre les estimations des tâches. Cela est un ordre de grandeur.

À d'autres occasions, un manque de concentration pendant la seconde partie révèle un manque de nettoyage du journal des travaux en souffrance du produit pendant l'exécution du sprint. Le nettoyage est une phase au cours de laquelle l'équipe peut se pencher sur de futurs récits et collaborer avec le directeur de produit pour ajouter des récits ou des tâches de recherche afin de déterminer des évolutions conceptuelles ou de traiter des questions liées à l'architecture. Le nettoyage régulier du journal des travaux en souffrance du produit simplifie la planification du journal des travaux en souffrance des sprints.

Scénario : le directeur de produit n'est pas disponible.

Si le directeur de produit ne peut pas assister à la réunion et qu'il ne s'est pas fait représenter, faites comme s'il s'était rendu à la réunion sans s'être préparé. Passez en revue les premiers éléments et engagez-vous dessus du mieux que vous pouvez. Vous pourriez être tenté de modifier l'heure de la réunion en fonction de l'emploi du temps du directeur de produit. Ne le faites pas. Modifier l'heure de la réunion profite à une personne au détriment du plus grand nombre. Cela ne vaut pas la peine.

Scénario : l'équipe ne dispose pas des critères d'acceptation dont elle a besoin.

Je conseille toujours aux équipes de poser au directeur de produit la question « Quels sont les critères d'acceptation pour cela? » ou « Que devons-nous faire pour que vous acceptiez le travail? » pendant la première partie. Si ces informations font défaut dans la seconde partie, quand l'équipe détermine les tâches, elle ne saura pas comment mener le récit à terme. Si l'équipe doit deviner en se basant sur les informations entendues pendant la première partie, elle court le risque que le directeur de produit décide à la fin du sprint que le récit n'est pas terminé. Demandez les critères d'acceptation dès le début de chaque récit. Les ScrumMasters doivent former les directeurs de produit à la communication de ces données.

Scénario : le directeur de produit ne sait pas ce que signifie « Terminé ».

De la même façon que l'équipe souhaite connaître les critères d'acceptation, le directeur de produit est en droit de disposer d'une description à jour de ce que l'équipe signifie par « le récit est terminé ». Cette liste d'achèvement doit être publiée de manière évidente, tenue à jour et mise à la disposition du directeur de produit à tout moment. Une liste d'achèvement obsolète complique la planification, car les uns et les autres ne savent pas réellement à quoi ressemble ce qui est terminé. Veillez à ce que la mise à jour de la liste d'achèvement fasse partie de chaque révision ou rétrospective de sprint.

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

Le directeur de produit est le bienvenu dans la seconde partie de la réunion, mais son rôle doit y être limité à la clarification d'une contrainte ou au traitement d'une question spécifique. Le directeur de produit ne doit jamais s'immiscer dans la discussion de l'équipe sur la façon d'implémenter un récit et n'a pas son mot à dire sur l'estimation d'une tâche. Le directeur de produit doit avoir confiance que l'équipe fasse son travail.

Si le directeur de produit ne suit pas ces directives, le ScrumMaster doit le former à un rôle plus approprié. S'il refuse de jouer un rôle plus passif, le ScrumMaster est en droit de lui demander de partir.

La planification du Sprint n'a pas besoin d'être difficile. L'équipe Scrum entière trouve souvent agréable et opportun de renforcer les liens qui unissent ses membres en cherchant ensemble à répondre à la question « Quel est notre engagement ? » Gardez à l'esprit que si vos réunions semblent traîner en longueur, des problèmes profonds en sont probablement responsables. Si vous êtes le ScrumMaster, évitez que la réunion ne se disperse en veillant à ce que le directeur de produit et l'équipe nettoient le journal des travaux en souffrance du produit. Expliquez au directeur de produit qu'il doit se présenter à la réunion en ayant au préalable préparé les critères d'acceptation des récits. Enfin, aidez le directeur de produit et l'équipe à se concentrer sur la tâche à effectuer, en déterminant ce sur quoi ils peuvent s'engager pour le sprint.