Comment définir un objectif de sprint (avec des exemples)

Un objectif de sprint est une phrase unique qui explique pourquoi ce sprint mérite d’être mené. C’est le seul résultat auquel l’équipe s’engage : ce qui sera véritablement vrai à la fin du sprint. Tout ce que l’équipe choisit de réaliser doit servir cet objectif, et lorsque le sprint devient serré, c’est cet objectif qui vous indique quelles tâches préserver et lesquelles abandonner.

La plupart des équipes considèrent l’objectif comme un résumé des tickets qu’elles ont sélectionnés. C’est une approche erronée, et c’est la raison pour laquelle tant d’objectifs sont inutiles.

L’objectif prime sur la portée

Fixez d’abord l’objectif, puis choisissez les tâches qui y contribuent. Un objectif élaboré à partir d’une liste de tickets déjà sélectionnés (« livrer les éléments 4, 7 et 12 ») n’est pas un objectif ; c’est une table des matières. Il ne peut pas vous aider à prendre une décision, car il ne donne aucune indication sur ce qui est important.

Tout repose sur l’ordre des priorités. Lorsque vous vous mettez d’accord sur le résultat avant de définir le périmètre, la sélection se résume à une série de questions simples : cet élément nous rapproche-t-il de l’objectif ? Si oui, retenez-le. Si non, il vaut mieux avoir une très bonne raison (un correctif de sécurité, une dépendance incontournable) ou alors, il devra attendre. Lorsque vous définissez d’abord le périmètre, chaque élément semble avoir le même poids, et il n’y a rien à supprimer lorsque la journée de jeudi déraille.

Ce qu’apporte un objectif solide

Un objectif trouve toute sa raison d’être lorsqu’il remplit trois fonctions :

• Il s’agit d’un résultat, et non d’une liste de tâches. « Les utilisateurs peuvent réinitialiser leur mot de passe sans contacter le support » vous indique ce qui a changé. « Réaliser l’épopée de réinitialisation du mot de passe » vous indique quel tableau Jira consulter.
• Cela vous permet de faire des compromis. Le véritable test d’un objectif a lieu le dernier jour du sprint, lorsque tout ne sera pas forcément prêt. Un bon objectif vous indique immédiatement ce qu’il faut privilégier. Si l’objectif est « permettre aux utilisateurs de réinitialiser leur mot de passe », vous livrez le processus de réinitialisation et laissez de côté la refonte de l’e-mail, qui est un plus. Si l’objectif est « terminer les tickets », vous n’avez aucun critère de sélection, si bien que tout prend un peu de retard et que rien n’est livré dans les meilleures conditions.
• L’équipe doit pouvoir le réciter de mémoire. Un objectif que personne ne peut réciter est un objectif qui ne sert de ligne directrice à personne. Si l’équipe doit ouvrir le document de planification pour se rappeler pourquoi elle est là, c’est que l’objectif est trop long ou trop vague.

Objectifs faibles vs objectifs forts

La différence entre un objectif faible et un objectif fort réside presque toujours dans le fait de définir une action plutôt qu’un résultat.

But facile	Pourquoi cela ne fonctionne pas	Un but décisif
« Travail sur la refonte du processus de paiement. »	Désigne un domaine, et non un résultat. Il n’y a pas de ligne d’arrivée.	« Un client fidèle peut finaliser son achat en moins d’une minute sur son mobile. »
« Clôturer 40 points d’histoire du backlog. »	Un indicateur de résultat doit servir l’objectif, et non constituer l’objectif en soi.	« Présentez les trois principales raisons pour lesquelles les clients contactent le service client au sujet de la facturation. »
« Améliorer les performances et corriger les bugs. »	Deux objectifs, aucune priorité, aucun compromis possible.	« Le tableau de bord se charge en moins de deux secondes pour les comptes comportant plus de 10 000 enregistrements. »
« Veuillez finaliser la fonctionnalité de création de rapports. »	Le terme « terminé » masque le champ d’application ; de qui est cette définition de « terminé » ?	« Les responsables peuvent exporter un rapport hebdomadaire de leur équipe au format PDF sans avoir besoin de notre aide. »

Remarquez que les objectifs forts présentent tous la même structure : un utilisateur ou un système précis, effectuant une action précise, conformément à une norme précise. Vous pourriez faire une démonstration de chacun d’entre eux et l’assemblée serait d’accord, sans contestation, sur le fait qu’il a été atteint ou non.

Un seul objectif, et non plusieurs

Concentrez-vous sur un seul objectif. C’est précisément le fait d’avoir un seul objectif qui permet de faire des compromis ; avec deux objectifs contradictoires, il n’y a plus de principe à défendre lorsque le temps vient à manquer, et vous en revenez à une situation où « tout se dégrade un peu ».

Si le travail ne s’inscrit véritablement pas dans un seul objectif, considérez cela comme un signal plutôt que comme un problème à masquer. En général, cela signifie que le sprint est trop chargé, ou que deux flux de travail ont été fusionnés en un seul sprint alors qu’il serait plus clair de les traiter séparément. Il arrive parfois qu’une petite quantité de tâches annexes, sans rapport direct avec l’objectif principal, vienne s’ajouter à celui-ci. Cela n’est pas gênant, tant que chacun sait qu’il s’agit d’un poids mort et non de la mission principale.

À qui appartient le but ?

Le Product Owner apporte l’intention : la raison métier pour laquelle ce sprint est plus important que les autres options possibles. L’équipe tout entière transforme cette intention en un objectif auquel elle peut réellement s’engager, ce qui signifie que les développeurs doivent être convaincus qu’il est réalisable avec la capacité disponible. Un objectif auquel l’équipe ne croit pas n’est qu’un vœu assorti d’une date butoir.

Une fois que vous avez défini un objectif qui mérite que l’on s’y consacre, le reste de la planification devient plus simple : le programme s’appuie sur cet objectif pour sélectionner les tâches, et le scrum quotidien l’utilise comme référence pour mesurer les progrès. L’objectif fixé le lundi sert de ligne directrice à l’équipe tout au long du sprint.

Foire aux questions

Qu’est-ce qu’un objectif de sprint ?

Un objectif de sprint est une phrase unique qui explique pourquoi ce sprint mérite d’être réalisé : il s’agit du seul résultat auquel l’équipe s’engage. Il est défini lors de la réunion de planification du sprint, avant la définition du périmètre, et il fournit à l’équipe un objectif commun auquel les éléments du backlog sélectionnés contribuent. C’est la raison d’être du sprint, et non la liste des tickets qu’il contient.

Qu’est-ce qui caractérise un bon objectif de sprint ?

Un bon objectif de sprint définit un résultat, et non une liste de tâches ; il est suffisamment précis pour vous indiquer ce qu’il faut abandonner lorsque le sprint devient serré ; et toute l’équipe est capable de le reformuler de mémoire. Si votre objectif se résume à « terminer ces tickets », il ne peut pas vous aider à faire des compromis, ce qui est pourtant la seule fonction d’un objectif.

Qui définit l’objectif du sprint ?

Le Product Owner présente l’intention (la raison métier pour laquelle ce sprint est important) et l’équipe tout entière la transforme en un objectif auquel elle peut s’engager lors de la planification. Il s’agit d’une collaboration, et non d’une directive. Les développeurs doivent être convaincus que l’objectif est réalisable avec la capacité disponible, sinon il ne s’agit que d’un vœu pieux.

Un sprint peut-il avoir plusieurs objectifs ?

Visez un seul objectif. C’est un objectif unique qui permet à l’équipe de faire des compromis sous pression ; avec deux objectifs contradictoires, il n’y a plus de principe à défendre lorsque le temps vient à manquer. Si le travail se divise réellement en deux, c’est souvent le signe que le sprint en fait trop, ou que le travail de deux équipes a été fusionné en un seul sprint.