Dorénavant, je publie mes articles sur mon blog nilslesieur.fr
Je discute de user stories dites techniques avec plusieurs équipes IT, avec plusieurs Product Owners, plusieurs coaches, plusieurs développeurs.
Elles sont souvent sujettes à discussions, comme toutes user stories dignes de ce nom me direz vous. Mais, je sens souvent des tensions, de l’incompréhension due à des points de vue différents entre l’équipe de développement qui fait émerger ces user stories et les POs qui doivent gérer, prioriser leur backlog dit fonctionnel ou métier.
Dans certaines équipes, ces 2 types de user stories ne sont pas “travaillées” de la même façon. Un exemple que j’ai pu observé : les user stories dites métier sont “groomées” en équipe, les user stories dites techniques sont “groomées” entre développeurs. Le PO ne comprenant que très peu le contenu de ces dernières ne vient plus aux réunions de travail et ne les priorisent pas...
Autre cas observé, devant l’incompréhension commune, un manager a décidé qu’au cours du sprint, les développeurs consacreraient 2 jours de leur sprint aux user stories techniques. Parfois, les équipes ont 2 product backlogs : un technique et un métier.
Une priorisation difficile
Les user stories techniques sont très souvent rédigées sous forme de solution et non d’un besoin ou d’une expérience que l’équipe souhaiterait faire vivre à l’utilisateur. Les exemples sont nombreux dans les backlogs : migration de tel langage vers tel autre langage, upgrade de la version de la base de données, APIsation de telle partie du soft, refonte d’une partie de l’application, … (chers lecteurs, chères lectrices, je vous laisse le soin de regarder vos backlogs respectifs pour compléter la liste :)
Comment prioriser entre une solution technique et un besoin métier ? Entre la migration d’une langage vers un autre et filtrer une recherche en tant qu’utilisateur aveugle ? Le travail de priorisation du product backlog (métier) n’est pas un travail facile pour le PO et pour l’équipe ; devoir prioriser entre des solutions et des besoins est encore plus compliqué. Les discussions ne sont pas les mêmes !
Et donc, que fait-on des stories techniques ? Les jeter ? Purement et simplement ? Un peu radical comme solution, non ? Je vous en propose une autre : et si les user stories techniques étaient en fait des user stories métier cachées, dont le besoin resterait non dit ?
Reprenons nos exemples
(les solutions décrites ci-dessous ne sont que des propositions fruits de mon imagination et ne sont en rien exhaustives)
Quel pourrait être le besoin d’une migration d’un langage informatique vers un autre ?
Cette migration pourrait être la réponse à une pénurie de développeurs sur le premier langage, à une limite du premier langage et l’expérience utilisateur serait de voir le logiciel durer dans le temps ou de continuer à voir les bugs corriger dans un temps court.
Pour l’upgrade de la version de la base de données, des amélioriations de sécurité, de performance seront sans doute dans la release note. Le support de l’éditeur sur la version actuelle se termine peut-être bientôt, ce qui pourrait signifier des temps longs de corrections.
Quant à l’APIsation de telle partie du soft, cette solution peut être synoyme d’exposition des données à l’extérieur et de générer un nouveau modèle business.
Enfin, refondre une partie de l’application peut être la solution à l’envie de diminuer les temps de correction de bugs ou de diminuer le nombre de bugs récurrents. Il pourrait s’agir également de permettre des évolutions impossibles avec l’architecture actuelle comme installer plusieurs instances du logiciel sur plusieurs serveurs dans le monde, alors que la version actuelle ne permet pas la scabilité. Ce qui aurait un impact sur des temps de chargement, de réponse, ce qui pourrait ouvrir de nouveaux marchés, …
Si les user stories dites techniques sont rédigées sous forme de solution (prenez le temps de relire cette dernière phrase et constater la dissonance user stories / solution), elles doivent disparaître des backlogs pour être réécrites sous forme de besoins, de user stories cette fois-ci orientées utilisateur. Elles doivent intégrer LE seul et unique backlog : le produit n’est pas composé d’une couche technique et d’une couche métier. Non! Tout est mêlé : la technique sert le produit (le rend plus performant ou lui apporte des nouvelles fonctionnalités) , l’utilisation du produit fait bouger et évoluer l’architecture (un nombre grandissant d’utilisateurs ou le déploiement dans d’autres pays). Une définition des user stories techniques pourrait être des user stories venant des métiers de l’IT et non des utilisateurs ou des experts métiers. Il ne faut pas interdire ni se priver des retours, des idées des départements IT.
Au même titre que les experts métiers, les utilisateurs, le product owner doit écouter les équipes techniques de développements, réseaux, sécurité et intégrer le fruit de ces conversations dans sa vision, dans son impact map, dans son plan de release.
Plus tard, il sera peut-être question de convertir ces conversations en user stories. De les jeter à la poubelle ou de les prioriser. De les implémenter. De les livrer.
Dorénavant, je publie mes articles sur mon blog nilslesieur.fr
