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é. Il s’agit du 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 privilégier et lesquelles abandonner.

La plupart des équipes considèrent l’objectif comme un simple 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 s’avèrent inutiles.

L’objectif prime sur la portée

Fixez-vous d’abord un objectif, puis choisissez les tâches qui vous permettront de l’atteindre. Un objectif dérivé 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 reflète pas 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 — sinon, il attendra. 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érape.

Ce qu’un objectif solide apporte

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 service d’assistance » vous indique ce qui a changé dans la réalité. « Mener à bien l’épopée de réinitialisation du mot de passe » vous indique quel tableau Jira consulter.
• Cela vous évite d’avoir à 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 activité plutôt qu’un résultat.

But peu convaincant	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. »
« Mettez au point 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 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 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 peut véritablement pas s’inscrire 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 ne pose pas de problème, tant que tout le monde 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 : 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é — c’est-à-dire le résultat unique 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 sélectionnés du backlog 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 apporte l’intention — la raison métier pour laquelle ce sprint est important — et toute l’équipe 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é regroupé en un seul sprint.