Press "Enter" to skip to content

Ça veut dire quoi “Indépendant” dans INVEST ?

Photo by Linh Pham on Unsplash

Ça veut dire quoi “Indépendant” dans INVEST ?

Indépendant au niveau produit ou au niveau technique ?

On m’a challengé sur le découpage des User Stories, et en particulier sur le côté indépendant recommandé par l’acronyme INVEST. C’était Loïc Brayat qui rebondissait sur un des épisodes de Scrum Life (liens en fin d’article) :

J’aurai une remarque par rapport à l’épisode 12 sur la découpe des User Stories : dans certains cas elles ne sont plus INVEST, notamment par rapport au I. Cela risque de poser des problèmes, non ?

On peut apporter diverses réponses à cette questions…

Que veut dire ce “Indépendant” ?

Que veut dire exactement ce Indépendant ? D’une discussion à une autre, on peut voir des divergences sur ce qu’on entend par Indépendant.

Indépendant au sens technique, pas au sens produit

Pour moi, Indépendant veut dire indépendant au sens technique du terme, pas au sens produit.

Selon cette définition on peut tout à fait avoir des User Stories qui ont du sens uniquement ensemble, avec une dépendance claire. On pourrait dire que ces User Stories se construisent les unes par dessus les autres.

C’est comme si on avait la User Story pouvoir se connecter et la User Story accéder à mon compte :

  • Techniquement on peut faire l’une ou l’autre indépendamment et dans n’importe quel ordre
  • Fonctionnellement cela ne fait pas de sens d’accéder à son compte sans pouvoir se connecter, ou du moins, ça ne serait pas un produit que l’on donnerait au client
  • Malgré tout, construire ces deux User Stories à l’envers pourrait être très utile comme étape intermédiaire de développement pour dé-risquer les éléments identifiés comme les plus à risque

“Ça ne marche que si c’est dans le même Sprint !”

Loïc Brayat continue de me challenger. Selon lui, l’approche que je propose pour ce Indépendant pose deux problèmes :

  • Soit les User Stories sont dans le même Sprint et donc, l’ordre à respecter entraîne des contraintes d’organisation et des risques
  • Soit les User Stories ne sont pas dans le même Sprint et dans ce cas la fonctionnalité complète ne sera pas disponible avant longtemps

Dit autrement, on risque de créer des User Stories sans valeur ajoutée pour le client.

Le client verra la mise en place de l’interface utilisateur. Il verra aussi l’interface utilisateur bouger quand tout sera fini. Mais rien ne se voit pour toutes les autres étapes intermédiaires !

Serait-on en train de confondre tâches techniques et User Stories ? Il faut bien découper pour faire rentrer dans le Sprint, mais est-ce que le découpage en tâches ne serait pas plus pertinent ?

Cela m’amène à votre définition sur le “indépendant techniquement”. Pour moi, une User Story doit être indépendante, selon INVEST, pour le produit. Pour la notion d’indépendance technique, cela ne serait pas du niveau des tâches ?

Un découpage technique ?

Je suis obligé de concéder des points à Loïc. Effectivement, l’exemple que je donne dans Scrum Life #12 est technique — ou plutôt, on est dans le cas de figure où un petit changement fonctionnel nécessite une refonte technique en profondeur.

Arrêtons de parler de User Story, vive les Product Backlog Items

Finalement, c’est ce que met en valeur ce découpage, et le terme User Story est utilisé à tort et à travers dans cet épisode. Honte à moi ! Il s’agit là plutôt d’éléments de backlog produit (PBI, Product Backlog Items) qui ne sont pas des User Stories.

Il n’y a aucun problème à ça, et effectivement on constate dans le découpage que chaque PBI résultant apporte beaucoup de valeur :

  • Dé-risquage technique : plutôt que d’attendre d’avoir tout fait pour intégrer et voir si tout marche
  • Dé-risquage d’interface ou de compréhension du besoin utilisateur : en pouvant tester à chaque fois avec les utilisateurs si l’interface est la bonne, si les données sont bien utilisées, etc.

Avec le découpage, le système est à chaque instant utilisable et on peut collecter du feedback dessus.

Cela ne veut pas dire pour autant que l’on se permettrait de le mettre en production, face aux vrais clients qui essaient d’accomplir leurs propres besoins.

Être en permanence dans un état stable

Ce qui nous amène à une autre réflexion : à chaque fin de Sprint, et finalement après le développement de chaque User Story si on est dans une logique d’intégration continue, le logiciel doit être dans un état dit potentiellement livrable.

Techniquement, tout doit être fini, propre, vérifié, prêt à sortir en production.

Mais d’un point de vue utilisateur, d’un point de vue produit, on n’est pas nécessairement dans une situation propice à sortir en production — c’est le potentiellement.

Donc si on reprend l’exemple je veux accéder à mon compte vs. je veux me connecter :

  • Les deux sont indépendantes dans le sens d’avoir un incrément produit potentiellement livrable et on peut les utiliser indépendamment pour challenger aussi bien les besoins utilisateurs que les solutions apportées
  • Les deux sont dépendantes dans le sens du Release Planning : on ne conçoit pas de livrer l’une sans l’autre

Pour aller plus loin

Scrum Life

Episode #12 de Scrum Life qui a mené à cet article

Photo by Linh Pham on Unsplash

L’épisode #59 de Scrum Life explique le principe d’INVEST

Photo by Linh Pham on Unsplash

L’épisode #88 de Scum Life aborde la question du découpage sous un angle différent

Photo by Linh Pham on Unsplash

L’épisode #58 de Scrum Life explicite le principe d’avoir un incrément potentiellement livrable à chaque fin de Sprint

Photo by Linh Pham on Unsplash

Que pensez-vous de cet article ?

Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !

Et pensez à souscrire à ma future newsletter : je prévois de quitter Medium, et cela sera le meilleur moyen de rester en contact.

À bientôt 😊

Top