Ce billet de blog a été rédigé par Nick Muldoon, ancien employé de Atlassian et Twitter et créateur de Easy Agile User Story Maps for JIRA. Dans cet article, Nick explique la façon dont JIRA user story mapping a permis à Twitter de mieux comprendre les attentes de ses clients en facilitant la gestion du backlog tout en adoptant une vue plus globale des produits.
Tweeps dans le besoin
A peine devenu un Tweep (nom donné aux employés de Twitter), je rencontre un manager en détresse. Son équipe avait besoin d’éclaircissements sur les sujets suivants :
– Qui sont leurs clients ?
– Quels sont les problèmes rencontrés par leurs clients ?
– Quelles sont les solutions possibles ?
– A quoi peut ressembler la feuille de route de livraison de ces solutions ?
Cette équipe était extrêmement compétente. Leur produit était très utilisé. De plus en plus de clients se pressaient pour demander des nouvelles fonctionnalités et améliorations, et par conséquent, le nombre de demandes en attente a très vite explosé, vraiment très vite !
Le manager de l’équipe se trouvait confronté à un challenge: faire en sorte que l’équipe puisse se concentrer sur les besoins des clients. Car le backlog continuait de s’alourdir, les distractions devenaient de plus en plus nombreuses. C’est la raison pour laquelle nous avons adopté JIRA user story mapping ; pour aider cette équipe à mieux identifier les véritables besoins des clients.
JIRA user story mapping
Le story mapping est une technique utilisée par les équipes agiles pour créer une représentation visuelle de l’expérience utilisateur d’un produit. Dans ce cas précis, le produit est un système de gestion de contenu qui propose une interface sur mesure pour un large panel d’utilisateurs. Bien que les configurations communes pouvaient être facilement identifiées, chacun des clients exprimait ses propres besoins et jalons.
Nous avons commencé par créer des Epics dans JIRA pour toutes les fonctionnalités importantes demandées par les clients clés. À cet égard, il s’agissait d’un story mapping un peu original puisqu’habituellement, on suit les demandes clés des clients par ordre chronologique.
Epics et User stories
Sous chaque Epic, l’équipe insérait par cliquer/déplacer les stories, les tâches et les bugs. Cette façon de grouper a aidé l’équipe à constater la quantité de travail nécessaire par client et par fonctionnalité. Tous ces travaux rassemblaient des demandes de nouvelles fonctionnalités, des améliorations ainsi que des travaux de maintenance. L’équipe a pu se créer une vue globale en organisant ses stories sous leurs Epics.
Estimation des story points
On attribue à chaque story un nombre de points afin d’estimer la quantité de travail qu’elle requiert. Toutes celles dépassant cinq points sont affectées et découpées en tâches plus petites afin de minimiser les risques. L’équipe ne voulait pas remettre en question ses workflows. Ils ont donc continué à travailler sur des petits éléments pour pouvoir réagir rapidement lors de la revue de code. Plus le commit est petit, moins on prend de risque lors du déploiement en production, c’est du gagnant-gagnant.
Planification du sprint
Comme l’équipe fonctionnait au rythme d’un sprint par semaine, les petites stories étaient essentielles. Le déploiement en production pouvait avoir lieu tous les jours à 14h30 du lundi au jeudi. Il pouvait être décidé le jour-même, aussitôt que l’équipe était prête à implémenter les changements dans le produit, sinon il fallait attendre 14h30 le lendemain. Encore une fois, cette équipe était disciplinée et cela se voyait dans son rythme de travail. Cette contrainte leur a permis de proposer de nouvelles choses très rapidement.
Vendredi était le jour où tout était organisé, de la planification de la semaine suivante à l’étude rétrospective du produit. Afin de les aider à planifier la semaine suivante, il leur était demandé de travailler sur leur story mapping en insérant les stories du backlog dans le sprint à venir. Ils avaient atteint un tel niveau d’efficacité qu’ils leur arrivait parfois de planifier leur travail huit semaines à l’avance.
Du résultat plus que du rendement
JIRA user story mapping a permis aux membres de l’équipe de se concentrer sur leur travail tout en conservant un œil sur le futur de leur produit. Cela a permis de minimiser les interférences et de livrer plus de valeur aux clients, tout cela de manière très rapide.
Pour conclure, le story mapping donne la possibilité à toutes les équipes agiles de mieux comprendre leurs clients et d’imaginer des solutions. C’est la meilleure technique à adopter pour s’assurer que l’équipe comprend ses clients, met en place des solutions adaptées et reste concentrée sur les livraisons.