Product Goal et Sprint Goal : celui qu'on peut abandonner n'est pas celui qu'on croit

Le Sprint Goal tient jusqu'au bout du Sprint, quoi qu'il arrive au périmètre. Le Product Goal peut être abandonné en cours de route, et ce n'est pas un échec.

C'est l'inverse de ce que leur nom laisse croire. Celui qui porte l'horizon le plus long est aussi le plus révocable.

Les deux sont des engagements, les deux contiennent le mot « goal », et le Scrum Guide les introduit dans la même respiration. Cette ressemblance est précisément ce que l'examen exploite. Sur nos 2504 questions d'entraînement, 148 portent sur l'un des deux, réparties sur huit certifications. Trois seulement les mettent face à face. Toutes les autres piègent le candidat sur un seul, en s'appuyant sur ce qu'il croit savoir de l'autre.

Chaque artefact porte son engagement

Scrum compte trois artefacts, et chacun est assorti d'un engagement, comme l'énonce la section Artifacts du Scrum Guide 2020.

• Le Product Backlog porte le Product Goal.
• Le Sprint Backlog porte le Sprint Goal.
• L'Increment porte la Definition of Done.

Retenir les trois paires ne suffit pas. Le verbe compte : l'engagement n'est pas accolé à l'artefact, il est dedans. Le Product Goal se trouve dans le Product Backlog. Le Sprint Goal fait partie du Sprint Backlog, au même titre que les éléments sélectionnés et le plan pour les livrer.

Un engagement existe pour rendre la progression mesurable. Sans lui, l'artefact n'est qu'une liste, et l'inspection n'a rien contre quoi se faire.

La symétrie s'arrête au nom

Posés côte à côte, les deux objectifs semblent taillés dans le même patron. Ils divergent sur presque tout.

L'horizon. Le Sprint Goal vit le temps d'un Sprint. Le Product Goal décrit un état futur du produit, sans durée prescrite.

Celui qui s'engage. Le Sprint Goal est l'engagement des Developers. Le Product Goal est celui du Product Backlog, dont le Product Owner est redevable.

Celui qui l'écrit. Le Sprint Goal est rédigé par toute la Scrum Team pendant le Sprint Planning, même s'il n'engage que les Developers. Le Product Owner ne l'apporte pas tout fait. La nuance paraît mince et elle piège beaucoup de monde.

Le moment. Le Sprint Goal est finalisé avant la fin du Sprint Planning, dont il occupe le premier sujet. Aucun moment n'est prescrit pour le Product Goal.

Le nombre. Un seul à la fois, des deux côtés. Un Sprint, un Sprint Goal. Un Product Goal, atteint ou abandonné avant d'en prendre un autre.

Reste l'axe qui les sépare vraiment, et c'est celui que l'examen préfère. Que se passe-t-il quand l'objectif devient caduc ?

Le Sprint Goal ne bouge pas, le périmètre bouge

Pendant le Sprint, aucun changement ne doit mettre le Sprint Goal en péril, selon la section The Sprint du Guide. Le périmètre, lui, se renégocie avec le Product Owner à mesure que l'équipe apprend.

Les éléments sélectionnés sont une prévision. Le Sprint Goal est l'engagement. Découvrir à mi-parcours qu'une hypothèse était fausse ne remet pas l'objectif en cause : cela change le chemin, pas la destination.

Au Daily Scrum, les Developers inspectent leur progression vers le Sprint Goal et adaptent leur plan. Ils adaptent le comment. Jamais le but.

Et si l'objectif devient réellement sans objet ? Le Sprint Goal ne se réécrit pas en cours de route. Le Product Owner peut alors annuler le Sprint, et lui seul. C'est l'unique motif d'annulation prévu, et le cas reste rare. Persévérer en silence sur un objectif hors d'atteinte prive l'équipe d'une décision qui ne lui appartient pas.

Terminer la liste n'est pas atteindre l'objectif

Une équipe peut terminer chaque élément sélectionné et manquer son Sprint Goal. Ce n'est pas une contradiction, c'est un signal.

Il dit que la sélection ne servait pas vraiment le but. La situation revient sous plusieurs formes dans nos questions, et la bonne réponse n'est jamais « c'est quand même une réussite ».

La cause est presque toujours identique. L'équipe commence son Sprint Planning par le choix des éléments, puis formule un objectif qui les résume. Le Sprint Goal devient une description écrite après coup.

Il perd alors tout ce qui faisait son utilité. Un objectif qui décrit la liste ne permet pas de renégocier le périmètre, puisqu'il change dès que la liste change. Il ne dit pas non plus si le Sprint a servi à quelque chose.

Le Sprint Planning traite le pourquoi avant le quoi, et cet ordre n'est pas décoratif. Les éléments soutiennent le Sprint Goal. Ce n'est pas le Sprint Goal qui résume les éléments.

Un test tient en une phrase : si votre Sprint Goal ne survit pas au retrait d'un élément, ce n'était pas un objectif.

Le Product Goal, lui, s'abandonne

Une réglementation change, un concurrent sort avant vous, une hypothèse se révèle fausse. Le Product Goal en cours n'a plus de sens.

La conduite attendue est de l'abandonner. La Scrum Team en formule un nouveau et réordonne le Product Backlog en conséquence. Le Scrum Guide prévoit explicitement qu'un objectif soit atteint ou abandonné avant qu'un autre soit pris.

Ce n'est pas un échec de planification. C'est la conséquence normale d'un développement incrémental et expérimental. Poursuivre un objectif que les faits ont invalidé reviendrait à préférer le plan à la réalité observée, soit l'inverse de l'empirisme.

L'idée est plus ancienne que le Scrum Guide. Le manifeste agile de 2001 place l'adaptation au changement avant le suivi d'un plan. L'un de ses douze principes invite même à accueillir les changements d'exigences tardifs. Le Guide ne cite pas ce texte, et Scrum lui est antérieur. Mais deux de ses créateurs l'ont signé.

Tant qu'il tient, le Product Goal sert d'arbitre. Quand deux parties prenantes défendent des priorités incompatibles, le Product Owner tranche au regard de cet objectif et de la valeur attendue. Puis il explique sa décision. Un objectif révocable reste un critère de décision.

Un dernier point, souvent testé. Plusieurs équipes qui travaillent sur un même produit partagent un Product Goal, un Product Backlog et un Product Owner. L'objectif produit ne se découpe pas par équipe.

Un exemple, aux deux niveaux

Prenons un service de réservation en ligne qui prend encore la plupart de ses rendez-vous par téléphone.

Le Product Goal. « Un client peut réserver et payer une prestation sans passer par notre service téléphonique. »

Il décrit un état futur du produit, pas une liste de fonctionnalités. On peut mesurer la progression vers lui, en suivant la part des réservations qui n'arrivent plus par téléphone. Et il s'abandonne : si les clients tiennent au contact humain, l'équipe l'apprend et en formule un autre.

Les Sprint Goals qui y mènent. Chacun est l'effet d'un Sprint, pas son contenu.

• « Un client peut choisir un créneau et voir le prix final, sans encore payer. »
• « Un client peut payer sa réservation en ligne, avec un seul moyen de paiement. »
• « Un client reçoit sa confirmation et peut annuler seul. »

Aucun ne nomme d'élément de backlog. Aucun ne dit comment faire. Chacun rapproche du Product Goal sans l'atteindre.

Le même Sprint, mal formulé. « Terminer les huit éléments sélectionnés, dont le paiement, la page de confirmation et les tests de bout en bout. »

Trois défauts, et ils tiennent ensemble. L'objectif nomme la liste, donc il change dès qu'un élément sort. Il ne dit pas quel effet le Sprint doit produire. Et il ne permet pas de savoir, à la fin, si le Sprint a servi.

Reprenons le test. Retirez les tests de bout en bout du périmètre : le bon objectif tient, le mauvais est déjà faux. Changez de prestataire de paiement en cours de Sprint : le bon objectif tient encore. Retirez le paiement en ligne : le bon objectif tombe, et c'est bien le signe que c'en était un.

Une précision, parce qu'elle compte à l'examen. La tournure « un client peut » n'est pas une règle. Scrum n'impose aucun format, et un objectif formulé autrement vaut autant s'il désigne un effet plutôt qu'une liste.

Ce que Scrum n'impose pas

La moitié des pièges se trouve de ce côté.

Aucun format. Ni pour l'un ni pour l'autre. Pas de gabarit, pas de phrase type, pas de longueur attendue. Un Product Goal doit être assez concret pour qu'on mesure la progression vers lui, rien de plus.

Aucune durée. Le Scrum Guide ne dit pas combien de temps dure un Product Goal. Il ne le fait correspondre ni à un trimestre, ni à un exercice budgétaire.

Aucune obligation que chaque élément serve le Sprint Goal. L'idéal visé est que tous les Developers travaillent sur des éléments qui le soutiennent. C'est une force d'unification, pas une règle de conformité.

Aucun arrêt anticipé. Une équipe qui atteint son Sprint Goal au sixième jour sur dix ne termine pas le Sprint pour autant. La durée reste fixe. Elle prend du travail supplémentaire avec le Product Owner, ou traite des améliorations identifiées.

Aucune vision obligatoire. Beaucoup d'organisations placent une vision produit au-dessus du Product Goal, et cela aide souvent. Le cadre ne l'exige pas.

Reconnaître la question le jour de l'examen

Les énoncés ne vous demanderont pas la différence entre les deux notions. Ils vous placeront dans une situation, et cette différence décidera de la réponse.

Le premier réflexe est de déterminer de quel objectif on parle. La règle suit ensuite.

• Le Sprint Goal est menacé pendant le Sprint : on renégocie le périmètre avec le Product Owner, pas l'objectif.
• Le Sprint Goal est devenu sans objet : seul le Product Owner peut annuler le Sprint.
• Le Product Goal est devenu sans objet : la Scrum Team en formule un nouveau, et ce n'est pas un échec.
• Tous les éléments sont terminés, l'objectif est manqué : ce n'est pas une réussite, c'est matière à Rétrospective.
• Quelqu'un veut mener deux objectifs de front : un seul à la fois, quel que soit le niveau.

Une réponse qui protège le Sprint Goal, l'auto-gestion des Developers et la redevabilité du Product Owner est presque toujours la bonne. Cela vaut bien au-delà de ces deux notions. C'est même ce qui sépare un candidat qui a compris le cadre d'un candidat qui l'a appris.

Plusieurs de ces dix pièges d'examen touchent aux objectifs, sous des formes qu'on ne reconnaît pas toujours du premier coup.

Questions fréquentes

Le Sprint Goal peut-il changer en cours de Sprint ?

Non. Le périmètre se renégocie avec le Product Owner à mesure que l'équipe apprend, mais l'objectif tient. S'il devient réellement sans objet, il ne se réécrit pas : le Product Owner peut annuler le Sprint, et c'est le seul motif d'annulation prévu.

Qui écrit le Sprint Goal ?

Toute la Scrum Team, pendant le Sprint Planning, même s'il n'engage que les Developers. Le Product Owner propose comment le produit gagnerait en valeur, et l'objectif se formule ensemble. Il n'arrive pas tout fait.

Peut-on avoir plusieurs Sprint Goals dans un Sprint ?

Non, il est unique. C'est ce qui donne sa cohérence au Sprint et pousse l'équipe à travailler ensemble plutôt que sur des chantiers séparés. Deux objectifs de front reviennent à n'en avoir aucun.

Combien de temps dure un Product Goal ?

Le Scrum Guide ne le dit pas. Aucune durée n'est prescrite, et il ne correspond ni à un trimestre ni à un exercice budgétaire. La seule règle porte sur le nombre : un seul à la fois, atteint ou abandonné avant d'en prendre un autre.

Un Sprint Goal manqué est-il un échec ?

Pas en soi. C'est une information, et elle se traite à la Sprint Review puis à la Rétrospective. Ce qui pose problème, c'est de manquer l'objectif en ayant terminé tous les éléments : cela veut dire que la sélection ne le servait pas.

À retenir

• Chaque artefact porte un engagement : Product Backlog et Product Goal, Sprint Backlog et Sprint Goal, Increment et Definition of Done.
• Le Sprint Goal est l'engagement des Developers, mais toute la Scrum Team le rédige pendant le Sprint Planning.
• Pendant le Sprint, le périmètre se renégocie et l'objectif non.
• Un Sprint Goal devenu sans objet ne se réécrit pas : seul le Product Owner peut annuler le Sprint.
• Un Product Goal devenu sans objet s'abandonne, et l'équipe en formule un nouveau.
• Un seul objectif à la fois, aux deux niveaux.
• Terminer tous les éléments sans atteindre le Sprint Goal n'est pas une réussite.

Ces distinctions se retiennent mieux en situation qu'en lecture. L'essai libre PSM I propose des questions originales avec correction immédiate, sans créer de compte.