Reconsidérer le S de INVEST
Auteur : Mike Cohn
Source : Rethinking the S in INVEST
Date : 18/05/2017
Traducteur : Fabrice Aimetti
Date : 21/05/2017
Traduction :
L'acronyme INVEST est fréquemment utilisé pour décrire les 6 attributs d'une bonne user story. Cela comprend Indépendant, Négociable, Valorisable, Estimable, S--- et Testable.
Mais que signifie le S ? Sexy ? Spécial ? Suffisant ? Sensé ? Significatif ?
Bill Wake a créé l'acronyme INVEST en 2003. A cette époque, nous avons discutés ensemble des lettres, y compris le S qu'il définissait comme Petit (Small).
Même si j'aime disposer d'un acronyme qui décrit succinctement les 6 attributs d'une super user story, je ne me suis jamais senti 100% à l'aise en disant "qu'une bonne story devrait être petite."
Mais Bill l'a défini ainsi et a écrit là-dessus sur son blog (fr), et j'ai donc écrit sur le sujet de la même manière dans mon livre User Stories Applied.
Ensuite, au fur et à mesure que je consacrais de plus en plus de temps à mentorer les équipes sur les user stories et à apprendre moi-même à travailler avec, j'en suis venu à me convaincre plus que jamais que Petit (Small) n'était pas le bon terme pour le S de INVEST.
Petit, c'est super pour les user stories sur lesquelles l'équipe va travailler dans la ou les deux prochaines itérations. Mais parfois, un backlog produit comprend des éléments sur lesquels l'équipe travaillera plus tard que cela.
Ces éléments sont souvent ajoutés au backlog produit en tant que simples rappels sur le travail à réaliser dans le futur. Et il est probable que personne dans l'équipe n'en sait assez sur la fonctionnalité pour créer de petites user stories sur le moment. Une personne de l'équipe devra en apprendre plus sur le sujet un peu plus tard, mais ce n'est pas important à l'instant t.
Et donc ces user stories sont dans le backlog produit mais ne sont pas encore petites.
Est-ce que ça en fait de mauvaises user stories ?
Non, je ne pense pas. Les user stories qui sont dans le backlog produit, mais qui ne seront pas implémentées sur le court terme, ne doivent pas être petites. Créer de petites user stories prend davantage de temps, rend plus difficile le travail avec le backlog produit, et donne l'illusion que la fonctionnalité a été complètement examinée.
Les user stories qui ne ne seront pas implémentées prochainement doivent vraiment conserver une taille plus grande et être moins détaillées.
Et cela signifie qu'une bonne user story est Indépendante, Négociable, Valorisable, Estimable, Scalable (de taille appropriée) et Testable.
La taille idéale d'une user story est influencée par le fait qu'elle sera prochainement ou non implémentée. Considérer qu'une bonne user story est Scalable plutôt que toujours Petite (small) aidera votre équipe à réussir.
Mike
P.S. : en plus d'écrire ceci, j'ai pris contact avec Bill Wake, créateur de l'acronyme INVEST et un bon ami, pour connaître ses réflexions du moment sur le S. Cliquez ici et je vous enverrai un mail avec les réflexions de Bill sur le débat Petit vs Scalable.
