Comment, quand et pourquoi identifier les trop grosses histoires utilisateur ? Partie 1

Comment identifier facilement, en quelques secondes, les histoires utilisateur, trop grosses ou grossièrement spécifiées, avant qu’il ne soit trop tard ?
Cette technique n’est évidement pas la seule, ni même suffisante, et je recommande vivement d’utiliser l’acronyme I.N.V.E.S.T., par exemple, en complément. Cependant, l’intérêt de cette technique tient au fait d’être rapide et très efficace en tant que premier filtre.

La première chose à faire est de rechercher les histoires utilisateur qui contiennent les occurrences de termes qui introduisent du flou comme « tous », « tout », « toute », « l’ensemble », « chaque », etc.
Une fois cette liste entre vos mains, vous aurez très certainement de très bons candidats au découpage.

Prenons un exemple :
EN TANT QU’utilisateur
JE SOUHAITE QUE tous les moyens de paiement soient disponibles
AFIN DE finaliser ma commande

On voit bien le flou qu’introduit cette histoire utilisateur. C’est peut-être très précis dans la tête de l’auteur, mais c’est l’inverse dans l’intention qu’il transmet à l’équipe de développement.
Une bonne session d’affinage devrait soulever les questions suivantes :

• De quels moyens de paiement parle-t-on exactement ? Carte bancaire, PayPal, chèque, cryptomonnaie ?
• A-t-on une liste exhaustive ?
• Ces choix sont-ils conditionnés par un ou des contextes comme la localisation de l’utilisateur ou de sa banque, etc.

Découper cette histoire utilisateur, fourre tout, en de multiples histoires utilisateurs, plus claires, compréhensibles et requérant moins d’efforts pour être achevées, c’est se donner la chance de pouvoir travailler de manière itérative et incrémentale et ainsi produire de la valeur à chaque itération, démonter que le paiement fonctionne même s’il ne gère pas au début l’ensemble des scenarii.

Si vous utilisez JIRA, comme la majorité d’entre nous, voilà une requête à adapter qui fera l’affaire :

...
AND issuetype in(Story) 
AND ("Story Description"~ "\" tous \"")
OR ("Story Description"~ "\" tout \"")
OR ("Story Description"~ "\" toutes \"")
OR ("Story Description"~ "\" ensemble \"")
OR ("Story Description"~ "\" chaque \"")
...

Petite précision, cet article n’est pas du tout à destination unique des product owner ou product manager. Jouer cette requête jira est à la portée de tous les membres de l’équipe (si ce n’est pas le cas, une petite formation pour maitriser votre outil est urgemment nécessaire).

Quand vérifier le niveau d’ambigüité des histoires utilisateur ?

Attaquer le développement d’une énorme histoire utilisateur, risque d’être plus stressant et démoralisant.
En dernier recours, je vous conseille de faire cela durant votre sprint planning pour éviter de planifier du travail qui a peu de chance d’être terminé durant l’itération. Il est tout de même plus judicieux d’utiliser cet outil régulièrement pour sélectionner des candidats à raffiner dans le top de votre backlog.

Quels bénéfices pour l’équipe

Travailler sur de plus petites tâches va faciliter la compréhension et les tests. Cela va également vous permettre de mettre votre nouvelle fonctionnalité plus rapidement dans les mains de vos utilisateurs et d’avoir des retours plus rapidement. Cela vous procurera aussi l’opportunité de déployer cette nouvelle fonctionnalité sans attendre que l’ensemble du chantier soit terminé et ainsi de capitaliser plus rapidement sur le travail accomplit.

L’étape suivante consistera à découper cette histoire utilisateur en de plus petites histoires utilisateur tout en gardant de la valeur fonctionnelle, technique que nous aborderons dans un prochain article.