Le flux de valeur

Sprint Planning et Sprint Backlog

Au début de chaque Sprint, la Scrum Team se réunit pour décider ce qu'elle veut obtenir et comment elle compte s'y prendre. Il en sort un objectif et un plan de travail qui appartient aux développeurs, le Sprint Backlog. Cet article présente les cinq patterns d'A Scrum Book qui décrivent cette réunion, ce plan et la liberté laissée aux développeurs pour l'ordonner.

Un lundi de planification

Cette réunion contient tout ce que Scrum appelle Sprint Planning. La période de deux semaines est un Sprint. La liste de la principale adjointe est le Product Backlog, et elle-même tient le rôle de Product Owner, responsable de la valeur du résultat. Les cinq autres sont les développeurs, au sens large que Scrum donne à ce mot : ceux qui réalisent le travail. Avec la Product Owner et un Scrum Master, qui aide l'équipe à bien appliquer la méthode, ils forment la Scrum Team. Les dix-huit étiquettes forment le Sprint Backlog. Dans A Scrum Book (2019), Jeff Sutherland, James Coplien et leurs coauteurs décrivent chacun de ces éléments par un pattern, c'est-à-dire une solution éprouvée à un problème récurrent.

Le Sprint Planning, du Product Backlog au plan de travail

Le pattern Sprint Planning (planification du Sprint) part d'un constat : les éléments du Product Backlog ne représentent qu'une valeur potentielle tant que personne ne les a réalisés. Il ne suffit pourtant pas de prendre les premiers de la liste dans l'ordre. Ils n'ont pas tous la même taille, et l'ensemble doit tenir dans la durée du Sprint. Les développeurs savent parfois qu'il est plus économique de réaliser un élément avant un autre. Enfin, concevoir chaque élément en détail longtemps à l'avance serait du gaspillage, puisque le contexte change, mais un minimum de conception est nécessaire avant de commencer.

La solution est que la Scrum Team se réunisse au début de chaque Sprint pour planifier la valeur qu'elle créera. Elle s'accorde sur un Sprint Goal (l'objectif du Sprint), puis construit un plan qui dit ce que les développeurs réaliseront et comment. Le pattern énumère quatre activités : vérifier que les éléments du haut du Product Backlog sont prêts, s'entendre sur l'objectif, choisir les éléments que les développeurs prévoient de livrer et planifier leur réalisation. Les auteurs notent que la plupart des équipes les mènent de front, car c'est en cherchant comment faire un travail que l'on comprend son ampleur.

Le pattern ajoute quelques précisions. La réunion est bornée dans le temps : les auteurs donnent comme repère quatre heures au plus pour un Sprint de deux semaines. Si un élément n'est pas assez précisé pour que les développeurs puissent le découper, ils ne le prennent pas. Enfin, le plan qui sort de la réunion n'est qu'une première version, que les développeurs ajustent chaque jour au Daily Scrum, leur point quotidien de quinze minutes.

Le Sprint Backlog et ses éléments

Le pattern Sprint Backlog (que les auteurs appellent aussi Sprint Plan, le plan du Sprint) répond au besoin suivant : pour piloter leur avancement, les développeurs doivent savoir à tout moment ce qu'il reste à faire pour atteindre l'objectif. Or ils ne comprennent le travail qu'en le découpant, ce découpage est déjà de la conception, et leur compréhension reste incomplète au début du Sprint.

La solution est de bâtir un plan de travail qui couvre tout ce que l'équipe doit accomplir pour atteindre le Sprint Goal. Il appartient aux développeurs : ils le créent, et eux seuls peuvent le modifier. Il est dimensionné d'après leur vélocité, c'est-à-dire la quantité de travail qu'ils ont terminée lors des Sprints récents. Il évolue pendant le Sprint, car les développeurs y ajoutent, retirent, scindent ou regroupent des éléments à mesure qu'ils apprennent. Les auteurs demandent qu'il soit visible de tous, par exemple sur un tableau, et chargent le Scrum Master de veiller à ce que personne ne s'en serve pour surveiller les développeurs.

Le Sprint Backlog Item

Le pattern Sprint Backlog Item (élément du Sprint Backlog, abrégé SBI) précise le grain du plan. Un élément du Product Backlog dit ce qu'il faut livrer. Il ne dit pas comment s'y prendre, et il ne révèle rien des risques de réalisation. S'engager sur un tel élément d'après sa seule valeur expose à découvrir trop tard qu'il occupe tout le Sprint. De plus, une équipe qui veut travailler à plusieurs sur le même élément doit d'abord s'être entendue sur ses parties.

La solution est de découper chaque élément du Product Backlog en unités de travail, dont aucune ne devrait dépasser ce qu'une personne termine en une journée. Ces unités peuvent être des tâches ou des pièces intermédiaires du résultat. Les auteurs recommandent de les noter en peu de mots sur des étiquettes, qui servent d'aide-mémoire des discussions. L'ensemble reste sous la responsabilité collective des développeurs, et les unités découvertes en cours de Sprint s'y ajoutent.

L'ordre du travail appartient aux développeurs

Une fois le plan établi, il reste à décider dans quel ordre le dérouler. Le pattern Developer-Ordered Work Plan (plan de travail ordonné par les développeurs) discute une idée répandue : suivre l'ordre du Product Backlog, afin que les éléments les plus importants soient au moins terminés si le Sprint tourne mal. Les auteurs y voient deux inconvénients. Cette habitude installe l'idée qu'un Sprint inachevé est normal, et la prévision des développeurs perd sa valeur. Elle donne aussi au Product Owner un moyen indirect de diriger le travail quotidien, et la tentation d'intervenir en plein Sprint quand ses priorités changent.

Un argument de nombre s'y ajoute. Dix tâches peuvent se ranger de 3 628 800 façons. Les auteurs prennent l'exemple d'un Sprint de cinq éléments découpés chacun en neuf tâches : ces 45 tâches admettent 45! ordres possibles, soit environ 1,2 × 10⁵⁶ (le livre arrondit à 2 × 10⁵⁶). Certains ordres permettent d'aller vite, d'autres non, et le meilleur change chaque jour avec les obstacles et les découvertes. Seuls ceux qui font le travail disposent de l'information nécessaire pour choisir.

La solution est donc de laisser les développeurs décider de l'ordre des tâches qui leur donne les meilleures chances d'atteindre l'objectif et de terminer le plan. L'ordre du Product Backlog les informe sans les contraindre, et ils revoient leur choix chaque jour. Le Product Owner garde deux moyens d'influence : le Sprint Goal, qui indique ce qui compte le plus, et la durée du Sprint. En cas d'urgence, il passe par la procédure d'exception décrite dans l'article Protéger le Sprint des interruptions. Les auteurs signalent le revers de cette liberté : un ordre choisi à la légère laisse beaucoup d'éléments à moitié faits en fin de Sprint. Ils y répondent par le swarming, qui consiste à finir ensemble un élément avant d'en ouvrir un autre.

Dependencies First : régler les dépendances avant la mi-Sprint

Le pattern Dependencies First (les dépendances d'abord) traite un risque précis : si des dépendances critiques restent ouvertes à la moitié du Sprint et que l'équipe en découvre encore, le Sprint est en danger. Une dépendance peut être la livraison d'un fournisseur, une ressource promise qui tarde ou un élément qui en attend un autre. Les auteurs mettent en garde contre l'idée de repousser ces questions au « dernier moment responsable » : on ne sait souvent où se situait ce moment qu'après l'avoir dépassé.

La solution est de faire en sorte que toutes les dépendances connues soient maîtrisées à la mi-Sprint. Pour cela, l'équipe commence par les tâches les plus difficiles et par celles où des dépendances risquent d'apparaître, afin que les surprises surgissent tôt. Si la règle ne peut pas être tenue, le pattern prévoit deux issues : interrompre le Sprint pour replanifier, ou se replier sur le Sprint Goal.

Au collège, cela donne un ordre de travail évident. Les relances des intervenants et la réservation des salles se font le lundi et le mardi, parce qu'elles dépendent de personnes extérieures à l'équipe. Le vendredi de la première semaine, cinq professionnels sur sept ont répondu, et l'équipe appelle les deux remplaçants. Le planning des ateliers peut alors être établi sur des bases sûres. Si l'équipe avait commencé par les affiches, elle aurait découvert les désistements trois jours avant le forum.

Ce que dit le Guide Scrum 2020

• Le Guide organise le Sprint Planning autour de trois questions : pourquoi ce Sprint a de la valeur, ce qui peut être terminé pendant ce Sprint, et comment le travail choisi sera réalisé. La première question a été ajoutée en 2020.
• Le Guide limite la réunion à huit heures pour un Sprint d'un mois, et la prévoit plus courte pour un Sprint plus court. Le repère de quatre heures pour deux semaines donné par le livre est cohérent avec cette règle.
• Le sens de Sprint Backlog diffère. Dans le Guide 2020, il réunit le Sprint Goal, les éléments du Product Backlog retenus et le plan pour les livrer. Dans le livre, le terme désigne surtout ce plan. Le Guide n'emploie pas l'expression « Sprint Backlog Item », mais il évoque un découpage en unités d'une journée ou moins.
• Le Guide confirme que la manière de transformer les éléments en incrément relève des seuls développeurs, et que le Sprint Backlog est un plan fait par eux et pour eux.
• Le Guide admet que les développeurs renégocient le périmètre avec le Product Owner en cours de Sprint, tant que l'objectif n'est pas affecté. Il écrit « Developers » là où le livre dit « Development Team ».

Limites et pièges

La dérive la plus courante transforme le Sprint Planning en séance de distribution : un responsable attribue les tâches à des personnes nommées pour deux semaines. Le plan n'appartient plus aux développeurs, et chacun protège sa liste au lieu de viser l'objectif commun.

Une autre dérive consiste à sauter le « comment ». L'équipe choisit des éléments jusqu'à atteindre sa vélocité et lève la séance. Le Sprint Backlog n'est alors qu'une copie du haut du Product Backlog. Les surprises que le découpage aurait révélées apparaissent en deuxième semaine, et le Daily Scrum n'a aucun plan à ajuster.

La liberté d'ordonner n'autorise pas à ignorer le Product Owner. Les auteurs admettent que des équipes expérimentées discutent l'ordre avec lui, à condition que les développeurs y consentent. Une réunion qui déborde régulièrement signale le plus souvent que les éléments n'ont pas été préparés, ce qui relève de l'affinage du Product Backlog.

Les seuils cités (quatre heures, une journée par tâche, la mi-Sprint) viennent de l'expérience des auteurs et n'ont pas été établis par des études comparatives. L'article Critiques et état des preuves précise la portée de ce type de recommandation.