Dans cet article, nous allons aborder l’importance de l’objectif de sprint, ses liens avec les cérémonies Scrum, comment le définir et comment l’utiliser.
Pizzapido…
Arthur est Product Owner de Pizzapido, une application qui permet de commander une pizza fraîchement cuite pour la retirer dans un automate. Avec son équipe ils terminent le sprint 14 qui met un gros focus sur la redéfinition de l’expérience utilisateur de création de compte. En effet, il s’est rendu compte que certains utilisateurs ne parviennent pas au bout du processus de création de compte et que cela fait donc une perte potentielle de commandes et donc de revenus. Il a donc inclus dans le sprint 14 plusieurs User Stories pour améliorer cette partie de Pizzapido.
Bien entendu, le sprint contient d’autres stories. Ces dernières ont pour but de résorber de la dette technique, fixer des bugs et aussi préparer des briques logicielles qui seront utilisées dans le futur.
Quelques jours avant la revue, l’équipe demande à Arthur de déscoper des stories importantes relatives à la création de compte. En effet, celles-ci ne seront pas terminées à temps. Arthur contient à peine sa frustration. Ces stories étaient les plus importantes à ses yeux et le fait de les enlever du sprint signifie que l’expérience utilisateur relative à l’enregistrement des clients ne sera pas améliorée lors de la livraison à venir.
Il a du mal à comprendre pourquoi l’équipe n’a pas travaillé en priorité sur ces stories, alors qu’elles étaient en haut du backlog, et pourquoi il n’a pas été averti à l’avance du fait qu’elles ne seraient pas terminées à temps.
Cette histoire vous rappelle-t-elle des souvenirs? Peut-être avez-vous vécu cette scène plusieurs fois?
Lors de mes sessions clients, on me fait souvent part des mêmes difficultés rencontrées par les équipes. Celle-ci en fait partie: Le sprint se termine, et certaines stories importantes n’ont pas été terminées.
Si vous faites face à ce challenge, sachez que toutes les équipes agiles passent par là. Moi aussi, quand j’étais Product Owner, j’ai dû chercher pourquoi ce problème apparaissait si régulièrement. Et la réponse réside en partie dans l’objectif de sprint.
Qu’est ce que l’objectif de sprint?
Claude Aubry, dans son livre intitulé « SCRUM: le guide pratique de la méthode agile la plus populaire » définit ainsi l’objectif de sprint : « bénéfice attendu à la fin du sprint, sur lequel s’engage l’équipe et qui détermine le succès du sprint ».
On l’oublie souvent mais un sprint (itération) a toujours un objectif (sprint goal) et un périmètre (sprint backlog). Les changements apportés en cours de sprint* ne doivent jamais remettre en cause l’objectif de sprint. Si c’est le cas, alors le sprint n’a plus de sens (worthless) et il vaut mieux le terminer de manière anticipée.
Un sprint a toujours un objectif (sprint goal) et un périmètre (sprint backlog)
Pourquoi est-ce important?
Les avantages pour l’équipe de dev
L’objectif de sprint aide à rester concentrés, et permet d’annuler le sprint si l’objectif devient obsolète. Lorsqu’un objectif est défini, l’équipe se sent collectivement responsable de l’atteindre et le travail de chacun s’en trouvera amélioré. On sort du schéma « je code mes stories et si chacun fait de même le sprint sera terminé avec succès » pour adopter l’attitude de « Si un membre de l’équipe est en difficulté, je dois prendre le temps de l’aider ». Cela donne une nouvelle dimension au sens de l’engagement. Un autre avantage est que la priorisation du travail à faire est plus cohérente avec les attentes des parties prenantes.
Les avantages pour le product owner
De plus avoir un objectif de sprint rend la communication avec l’extérieur plus claire, logique et transparente. Cela permet de récolter et d’analyser les feedbacks de manière plus efficace.
Enfin, la sensation « d’achievement » est plus franche, tangible. Il est des sprints où l’on s’est beaucoup donné, où l’on a passé des jours à coder des stories, où l’on a mis en production une nouvelle version… mais c’est difficile de résumer clairement les nouvelles fonctionnalités délivrées. C’est un peu un ensemble incohérent de choses (qu’il fallait faire néanmoins). Un sprint dans lequel l’objectif est atteint n’est pas ainsi. C’est plutôt un sprint à l’issue duquel le PO pourra affirmer « Durant le sprint 14, nous avons principalement redéfini et amélioré le parcours utilisateur de création de compte et nous nous attendons maintenant à une meilleure performance des indicateurs x et y. En outre, nous avons aussi pu fixer des bugs critiques et nous avons commencé à installer la nouvelle plateforme de tests automatiques »
Comment définir l’objectif de l’itération ?
Qui définit l’objectif de sprint?
Qui définit l’objectif de sprint? Ce ne peut pas être le Scrummaster, puisqu’il joue le rôle de facilitateur. Ce n’est pas non plus l’équipe de dév, car celle-ci est responsable de déterminer comment l’objectif sera atteint. On serait tenté de dire que c’est le Product Owner qui donne l’objectif à l’équipe de dev. Mais en fait cela ne se passe pas exactement comme ça. Le PO suggère un objectif. L’objectif est validé par la Scrum team dans son intégralité. En effet, le Scrum guide dit:
« During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment. »
Comment définir l’objectif?
Comment le PO va proposer un objectif? C’est là qu’entre en jeu une qualité primordiale du Product Owner: la vision stratégique. Si le PO n’a pas de vision stratégique, il va ordonner son backlog et mettant en haut de la pile un mix de :
– User Stories qui ont le plus de valeur à ses yeux (en ayant pris en compte les informations venant des parties prenantes),
– Bugs urgents à résoudre
– Stories techniques que l’équipe de dév pense devoir réaliser
– Items de dette technique à résorber
Si maintenant le Product Owner a une réelle vision pour son produit, alors la décliner en objectif de sprint sera un jeu d’enfant. En effet, l’objectif de sprint n’est rien d’autre que la déclinaison de la vision produit à l’échelle de l’itération. Un PO visionnaire aura préalablement défini une roadmap produit, avec des jalons (lancement commercial, v1, v2, démo lors d’un salon, démo client important etc). Il aura ensuite décliné la roadmap en release plan, chaque release ayant un objectif de release. Même si l’on ne s’engage pas sur un périmètre, il est utile de préparer un objectif de release (en s’aidant par exemple de carte impact mapping), et de l’adopter au démarrage de celle-ci.
Ensuite, chaque release sera constituée de plusieurs itérations. L’ensemble des objectifs de sprints des itérations d’une release conditionnera l’atteinte de l’objectif de release.
L’objectif de sprint n’est rien d’autre que la déclinaison de la vision produit à l’échelle de l’itération
Pour résumer on a le schéma suivant:
Vision produit > Objectifs de releases > Objectifs de sprints
Comment l’utiliser?
L’objectif de sprint va supporter et promouvoir les 3 pilliers de Scrum:
Transparence
Lorsque l’itération démarre, l’objectif de sprint est clairement affiché sur le « board » et visible de tous, y compris des parties prenantes. Lors de la revue, on fait un rappel de l’objectif et on précise en quoi il a été atteint (si il l’a été). Durant le déroulement du sprint, tout le monde sait vers quel résultat l’effort en cours tend. Il n’y aura donc pas de surprise à la fin du sprint, et personne n’aura à se demander pourquoi telle story n’est pas dans le sprint, ou pourquoi le bug #1234 ne sera pas fixé tout de suite.
Inspection
Lors du déroulement de l’itération, la scrum team va utiliser l’objectif de sprint pour vérifier qu’elle est bien en ligne avec le prévisionnel. Par exemple lors du daily stand up, beaucoup d’équipes utilisent la routine suivante:
- Sur quoi j’ai travaillé hier?
- Sur quoi est ce que je vais travailler aujourd’hui?
- Quelles sont mes difficultés du moment?
C’est très bien, mais je conseille souvent à mes clients d’enrichir les questions de la manière suivante:
- Sur quoi j’ai travaillé hier et qui a contribué à l’atteinte de l’objectif du sprint?
- Sur quoi est ce que je vais travailler aujourd’hui et qui va contribuer à l’atteinte de l’objectif du sprint?
- Quelles sont mes difficultés du moment qui m’empêchent de progresser dans la réalisation de l’objectif de sprint?
Adaptation
Tout changement dans le périmètre du sprint ne doit pas mettre en danger l’objectif. Si cela devait être le cas, le Product Owner décidera dans la majorité des cas d’interrompre le sprint en cours pour en démarrer un nouveau. L’objectif du sprint aidera donc la Scrum Team à continuer de travailler sur quelque chose d’utile, qui a du sens et qui contribue à la progression vers la réalisation de la vision du produit.
Pour conclure
Pour illustrer l’importance de l’objectif de sprint, je fais souvent l’analogie avec des rameurs qui pratiquent l’aviron. Plus que la force, c’est la coordination qui est importante dans ce sport. En équipage, la synchronisation se doit d’être parfaite pour que la poussée soit maximale.
Dans une équipe Scrum, la coordination des efforts vers un objectif commun va maximiser la valeur qui sera délivrée à la fin de l’itération. Et vous? Utilisez-vous les objectifs de sprint? Pourquoi ne pas rajouter « Objectif de sprint défini » dans votre checklist de points à vérifier avant de démarrer le sprint?
*Scrum guide: If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner.