En tant que scrum master, je veux arrêter de parler de « user story » dans le but de réconcilier le business et l’IT

En 1998, Alistair Cockburn (un papa de l’agilité) écrivait « une user story, c’est la promesse d’une conversation ». La user story, sans vouloir refaire sa définition complète, présente un formalisme facile à comprendre « En tant que [rôle]… je veux [action]… afin de [bénéfice attendu]… », et on pourrait donc penser facile à appliquer. Je vous invite d’ailleurs à consulter la RefCard  Ecrire des user stories utiles et efficaces  si vous souhaitez en savoir davantage. Aujourd’hui, je constate que la conversation tourne plus autour de qui rédige les user stories, les EPICs, ce qui est mandatory, le template… Je vous propose donc de faire le point sur la user story en faisant un focus sur nos organisations.

Oganisations agiles

Les entreprises pour lesquelles nous travaillons font face à des changements rapides et brutaux sur leurs marchés, avec notamment des enjeux digitaux et d’intelligence artificielle accrus. Pour autant, elles disposent des mêmes ressources pour accomplir ces challenges, à savoir leur système d’informations, leurs ressources humaines, et leur organisation.

Pour faire face à ces demandes, une réponse apportée a été de rendre les développements « Agiles ». Evidemment, les problématiques viennent toujours de l’IT. Alors, les entreprises ont recruté des scrum masters, et des coachs agiles pour accompagner les équipes à travailler différemment. Ces derniers se sont rapidement rendus compte qu’un des facteurs clé de succès (et d’échec !) est l’organisation au sens large.

D’une part, une transformation ne peut se faire sans impliquer tous les niveaux de management. Ceux-ci sont généralement des piliers dans l’entreprise de part leur expérience et leur connaissance des entreprises dans lesquelles ils agissent. L’accent est mis aujourd’hui sur la posture de ces managers, que l’on pousse aujourd’hui à être 3.0, dans le but de faire grandir à leur tour les collaborateurs qu’ils accompagnement, et d’agir en tant que leader dans leur organisation.


D’autre part, la transformation passe par la culture et les codes de l’entreprise, les valeurs véhiculées par celle-ci, et leur capacité à remettre en question leurs processus, leur manière de travailler, les outils utilisés afin de maîtriser leur chaîne de valeur.

Voici maintenant un petit exemple d’une organisation de projet qui pourrait se penser agile : elle a parfois la chance d’avoir un Product Owner dedié, qui travaille dans un bâtiment assez éloigné de celui de l’IT, et qui est secondé par un Proxy Product Owner (un business analyst ?), dans les locaux de l’IT pour écrire nos fameuses user stories. Les Proxy + Product Owner doivent solliciter d’autres Business Analysts et Chefs de projets, voire des personnes ne travaillant pas sur le projet pour comprendre le besoin et avoir des retours sur sa faisabilité. Ils échangent également avec les UI designers pour ajuster les maquettes à implémenter, même si le SI actuel laisse paraître une incompatibilité pour implémenter le besoin. L’utilisateur est aussi sollicité parfois, et est insatisfait des couleurs choisies pour les interfaces, et préfère les anciens outils car il en avait l’habitude. Et l’IT en profite pour faire quelques refontes techniques. On peut présager de la difficulté du projet (on est loin du produit), et de celle des user stories à écrire. Nous souhaitons du courage aux développeurs, qui peuvent facilement perdre de vue l’essentiel. Pensez-vous vraiment que cette organisation est agile ?

Pour pallier ces contraintes, voici quelques pistes de réflexion :

  • Réalisez un schéma de l’organisation, afin de visualiser les personnes impliquées sur le projet, par type de population (développeurs, managers, analysts…), selon leurs dépendances hiérarchiques, site géographique… Cela peut être utile lorsqu’un grand nombre de personnes intervient sur le projet, notamment pour conduire le changement auprès des managers sur les délais de livraison des fonctionnalités (de l’idée à la mise en production), sensibiliser sur le ratio développeurs / intervenants sur le projet (il peut s’avérer surprenant !), ou simplement pour présenter la structure aux nouveaux arrivants.

  • Initiez une matrice de connaissances, afin d’identifier les sachants, et créer plus facilement des binômes pour transférer les savoirs. Cela permet aussi d’identifier plus simplement les personnes à contacter. Le passage de connaissance peut être réévalué une fois par trimestre par exemple. Il peut aussi s’avérer judicieux d’identifier les personnes ayant des connaissances sur les sujets abordés, même s’ils ne font pas partie de l’équipe projet, afin d’établir au plus tôt un plan de communication au besoin.

  • Capitalisez sur la connaissance de l’équipe en ayant une documentation minimale : j’ai souvent constaté que les applications développées possèdent soit un bottin en guise de documentation, soit des fichiers qui se promènent sur différents espaces de stockage, partagés ou non, soit une absence de documentation. Pour historiser les connaissances, les équipes peuvent utiliser un outil simple comme Confluence de la suite Atlassian et mettre à jour la documentation utile à une fréquence définie. Ce besoin de capitalisation peut d’ailleurs s’inscrire dans la Definition Of Done de l’équipe. Veillez au départ à définir une arborescence claire, ainsi que le contenu utile. La documentation doit servir à l’organisation et il convient à ce titre d’en définir l’objectif dès le départ. Elle doit également être élaborée en fonction du contexte de l’entreprise (organisation multi-sites, turnover…). Enfin, n’oubliez pas, la meilleure documentation, c’est le code 🙂

  • Mettez en place des processus partagés : rapidement, il convient d’identifier par qui doit « transiter » la user story, et quelle est la contribution de chacun. Il peut être intéressant d’organiser un atelier pour coécrire une user story, et capitaliser dessus comme template pour les suivantes. Cela permettra en même temps d’aborder une partie des rôles et des responsabilités. Il conviendra de présenter la user story à l’équipe de développement afin d’obtenir leur feedback sur le format, et s’avoir s’ils disposent de toutes les informations nécessaires pour comprendre le besoin.

Scrum VS la user story

Pour tous ceux qui ont lu le Scrum Guide (je sais que nous sommes très nombreux), le vocabulaire utilisé pour les éléments à réaliser est « item », et non pas user story. Cela signifie que n’importe quel besoin, sujet, élément peut être ajouté au product backlog, quelles que soient sa maturité et sa taille. Il est important de trouver rapidement une harmonie dans la gestion du product backlog, afin de qualifier les éléments de nature, taille et importance différente. Force est de constater que peu d’outils présentent toutes ces fonctionnalités réunies. Si vous avez de la place (des murs !), je vous conseille de représenter votre product backlog à travers des outils de management visuel (story map, iceberg…). Cela permettra d’une part de visualiser les éléments à réaliser, et d’autre part les processus mis en place par l’équipe.

Découper le besoin

Dans les organisations dans lesquelles j’ai eu l’occasion de travailler, dès que l’agilité a été évoquée, la user story aussi. Et par extension, la notion d’Epic, de Feature, de Themes... Quid lorsqu’on travaille sur une refonte technique ? Keep It Simple, Stupid. Mon précieux conseil c’est de partir du besoin ! En langage naturel ! Et donc d’amorcer la conversation autour de cela. D’ailleurs, lorsque les personnes échangent sur certaines user stories, ils parlent uniquement de la partie « je veux », ça montre bien que c’est beaucoup trop long, non ? 
L’idée est d’identifier les macro-étapes que va satisfaire le système et d’approfondir ensuite les détails de chaque étape. Le besoin de découper les items est souvent perceptible lorsque notre interlocuteur énumère des éléments « l’utilisateur doit pouvoir faire … ET … ET … ». Pour en apprendre davantage sur le concept associé, qui est celui de la story map, je vous invite à consulter l'article L'art de manier les exigences agiles. Les regroupements se font ensuite naturellement par thématiques liées.

Gardez donc en tête que c’est bien le besoin qui est à éclaircir et à découper avant le formalisme, et que ces notions de classification sont uniquement une aide pour la lecture du besoin à différente échelle. Un bon titre suffit ! On ne perd pas de temps à écrire le contenu d’une EPIC ou autre.

Pour ce qui est des items purement techniques, le Product Owner communique la vision, l’objectif à réaliser ET fait appel à son équipe pour découper les éléments. C’est un bon moyen pour l’équipe de clarifier le besoin, d’échanger sur la manière d’implémenter les éléments et de ne pas oublier des étapes.

Pour faciliter votre découpage, n’hésitez pas à télécharger notre jeu de cartes, le  Split Poker  !

S’abstraire (parfois) du formalisme

Il faut trouver un équilibre entre l’effort fourni et l’impact produit. Si je prends le cas d’une connexion : en tant que cliente Sarenza fan de sneakers, je veux me connecter à mon compte, dans le but d’acheter une paire de Stan Smooth dorée > mon US est super incomplète :

  • Je me connecte comment ? par mail ? par Facebook ?
  • Je masque le mot de passe ? Je l’ai oublié d’ailleurs.
  • Y a-t-il un captcha ? Lequel ?
  • J’arrive sur quelle page ?
Alors oui ça engendre Card – Conversation – Confirmation, et vous imaginez le temps qu’on y passe ? Pour chaque US ? Sans oublier la description, les maquettes, les critères d’acceptance… Concrètement où se situe la valeur pour l’utilisateur et pour le business dans la connexion ? Pour ce type de cas, je dirais qu'il est important de présenter le sujet à l'équipe dans sa globalité afin de donner une vision.

Pour ce qui est de l’item à implémenter dans le prochain sprint, on peut se contenter de « se connecter avec son mail et mot de passe et arriver sur la page d’accueil», ou de passer un coup de surligneur sur des maquettes si elles existent. La valeur du travail d'équipe se situe dans la compréhension des attendus. 

Vous l'avez compris, la user story est un moyen efficace pour générer des échanges au sein des équipes au sens large. Sa rédaction ne doit pas être un point de douleur, mais plutôt un objet facilitant. L’organisation au sens large y joue un rôle : lorsqu’on ne sait pas qui contribue à sa rédaction et qui détient la connaissance, alors il convient de s’y pencher, afin d’offrir un cadre de travail au projet ou au produit, et au-délà. C’est aussi l’occasion d’impliquer le management afin de le sensibiliser à de telles problématiques, mais aussi de rapprocher le business et l’IT afin de passer du “vous” au “nous” et de construire ensemble l’organisation la plus efficace. Pour finir sur les user stories, en écrire est utile, et il est encore plus important de communiquer et de comprendre le besoin.

Nombre de vue : 694

AJOUTER UN COMMENTAIRE