“Pourquoi on doit faire cette fonctionnalité ou faire telle ou telle modification ?”
“Qu’est-ce qu’on attend du sprint ?”
“Est-ce qu’on a réussi ?”
Ce sont des questions que devraient se poser n’importe quelle équipe et surtout, elle devrait savoir y répondre !
Dans cet article, nous allons voir comment l’impact permet à une équipe agile de justifier des décisions sur le backlog et sur le produit, mais aussi de suivre les résultats de ces décisions.
Note : cet article reprends en grande partie le script que j’ai écris sur le sujet pour Scrum Life et dont vous trouverez la vidéo plus bas, mais apporte aussi de nouveaux éléments.
L’impact de l’objectif
Que ce soit pour les User Stories (j’en parlais dans un précédent article dont vous trouverez le lien en fin d’article) ou les objectifs de sprints, le but n’est jamais réaliser un logiciel ou une fonctionnalité, mais de changer la vie de l’utilisateur — en bien tant qu’à faire.
Mais il ne suffit pas de décréter qu’on va changer la vie de l’utilisateur, il faut exprimer clairement en quoi, quand et mesurer cet impact.
Comment pouvons-nous être sûr que ce que l’équipe va réaliser va être une réussite ?
Quels sont les critères de succès ?
Ces questions sont légitimes pour toute l’équipe, il est de votre responsabilité, en tant que Product Owner, de pouvoir y répondre et de définir, avec son objectif de sprint, l’impact attendu de celui-ci.
C’est le pourquoi du pourquoi (du pourquoi).
Par exemple, un objectif de sprint pourrait être : “donner plus de détails sur le produit aux utilisateurs”
Et l’impact attendu de ce sprint serait s’améliorer le taux de conversion de +5% sur le prochain trimestre. C’est un engagement que le Product Owner prend auprès du reste de l’équipe Scrum toute entière.
Et cet engagement doit être mesuré et vérifié. C’est votre rôle de Product Owner de permettre à l’équipe de connaître les résultats de leur travail.
Par exemple, en incluant dans votre backlog un dashboard permettant de voir les résultats des mesures ou au pire, en partageant avec eux les chiffres.
Output vs outcome
L’output, c’est ce que l’équipe à réalisé. C’est un produit, une fonctionnalité. C’est par exemple l’incrément du logiciel.
L’outcome, c’est le bénéfice que l’utilisateur ou le business à retiré de notre travail.
Par exemple, pour un fabricant de maisons, l’output est un tas de briques empilées correctement avec quelques fenêtres, mais pour l’utilisateur de cette maison, c’est un foyer et une protection pour sa famille.
Quand Scrum décrit dans le Scrum Guide le rôle du PO comme celui qui doit maximiser la valeur produite par l’équipe de développement, on ne parle pas des lignes de codes qui s’empilent, mais d’un produit qui change la vie de l’utilisateur : l’outcome.
L’impact sur le backlog
Une fois que vous avez pu définir l’impact attendu, vous devrez accepté en atant que PO que cet impact produit attendu, aura un… impact sur le backlog.
Car pour mesurer l’impact d’un sprint, pour savoir si celui-ci est un succès, il vous faudra du feedback et le mieux est d’automatiser au maximum du possible l’obtention de ces retours.
Donc, je vous conseille de réfléchir avec l’équipe sur la façon de mesurer l’impact attendu, il se pourrait bien que du code doivent être créé pour ajouter des sondes, du tracking ou de l’analytics.
Vous trouverez en fin d’article un lien vers mon article “Ce qui n’est pas mesuré ne peut être amélioré” pour plus de précision à ce sujet.
Et c’est pareil pour les bug, on attend une amélioration de l’utilisation du produit, pourquoi ne pas la mesurer ?
La priorisation du backlog
Une fois que vous connaissez l’impact attendu d’un élément du backlog, c’est plus simple pour vous de prioriser entre une fonctionnalité qui va faire gagner ou économiser 1000 € à l’entreprise et une autre qui va en faire gagner 10 000 €, le choix est plutôt simple.
L’impact peut prendre plusieurs forme : argent gagné / économisé, temps gagné pour les utilisateurs, donner une meilleure image de l’entreprise, etc.
Pour les développeurs
L’impact, c’est aussi un moyen pour les développeurs de faire passer en priorité leurs besoins ou envies techniques.
Si une refonte du schéma de la base de données doit être faite, ils doivent être en mesure de vous dire l’impact attendu sur le produit (meilleure performance, maintenabilité du code, etc.) mais aussi de comment cela va être mesuré.
L’impact, comme filtre
C’est aussi un bon filtre pour le backlog. Si aucun impact sur le produit ou les utilisateurs ne peut être trouvé, c’est sûrement qu’on ne devrait pas faire cette fonctionnalité, non ?
L’engagement
Savoir pourquoi, concrètement, l’équipe réalise un incrément produit aide à donner un sens à l’équipe de développement.
Mesurer et vérifier cet impact, encore plus !
Ces résultats aident aussi à tous à comprendre d’éventuels changement de stratégie, etc.
“Si tu veux construire un bateau, fais naître dans le coeur de tes hommes et femmes le désir de la mer”
St Exupéry
Quand l’impact est raté, on fait quoi ?
C’est possible que vous vous soyez trompé dans votre hypothèse. Ça peut même être fréquent, c’est la preuve de votre audace et de votre créativité. C’est aussi un bon signe que l’entreprise tente d’innover.
Mais il faut en venir à l’évidence et… tuer la feature ! Ce code devenu inutile est dangereux, toxique, contagieux. Plus le temps passe, plus il sera difficile de s’en débarrasser suivant les choix techniques qui ont été fait.
Les bonnes pratiques de développement (comme le TDD) permet de limiter considérablement les risques.
Voici l’épisode de Scrum Life que j’ai écris sur le sujet :
Je vous invite à lire cet article pour améliorer vos User Stories : https://const.fr/blog/agile/une-astuce-pour-ecrire-de-meilleurs-user-stories/ et aussi “Ce qui n’est pas mesuré ne peut être amélioré” pour en savoir plus sur les sondes et de l’Art de jeter son travail à la poubelle.
Photo by Jordan McDonald on Unsplash