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 doit être véritablement accompli à 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 pourquoi tant d’objectifs sont inutiles.

L’objectif prime sur la portée

Fixez-vous d’abord un 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.

C’est l’ordre qui fait toute la différence. 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 aussi essentiel les uns que les autres, et il n’y a rien à supprimer lorsque la journée de jeudi tourne mal.

Ce qu’apporte un objectif solide

Un objectif trouve toute sa raison d’être lorsqu’il permet de remplir 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é. « Mener à bien 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 règles de l’art.
• 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 activité plutôt qu’un résultat.

But facile	Pourquoi cela échoue-t-il ?	Un but décisif
« Travaux de 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 de story du backlog. »	Un indicateur de résultat doit servir l’objectif, et non constituer cet 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 moyen de trouver un compromis.	« Le tableau de bord se charge en moins de deux secondes pour les comptes comportant plus de 10 000 enregistrements. »
« Mettez au point la fonctionnalité de création de rapports. »	Le terme « terminé » masque le champ d’application ; selon quelle définition, alors ?	« Les responsables peuvent exporter un rapport hebdomadaire de leur équipe au format PDF sans avoir besoin de notre aide. »

Remarquez que les objectifs forts ont 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 en présenter chacun à titre de démonstration et l’assemblée s’accorderait, sans contestation, sur le fait de savoir s’il a été atteint.

Un seul objectif, et non plusieurs

Concentrez-vous sur un seul objectif. C’est 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 dérape un peu ».

Si le travail ne parvient vraiment pas à s’inscrire dans un seul objectif, considérez cela comme un signal plutôt que comme un problème à dissimuler. 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 ne pose pas de problème, 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 engage, le reste de la planification devient plus simple : l’agenda s’en sert comme critère de sélection des tâches, et le scrum quotidien s’en sert comme référence pour mesurer les progrès. L’objectif fixé le lundi est celui qui guide 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 mené : 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 contribuent les éléments sélectionnés du backlog. 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 laisser de côté 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 choix prioritaires, 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 ce qui permet à l’équipe de faire des compromis lorsqu’elle est 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 demande trop, ou que le travail de deux équipes a été regroupé dans un seul sprint.