3 Amigos : Est-ce encore le moment pour découper une Userstory ?
Vous avez peut être entendu cette phrase dans votre carrière.
“Non, on ne peut pas découper cette Userstory, j’ai tellement travaillé sur le découpage du besoin, qu’on ne peut pas faire plus. Elle est trop grosse ? Tant pis, on la développe comme cela !” — Le Product Owner de l’équipe John Doo.
Mais, savez-vous à quel moment il est légitime de découper une Userstory ?
Le découpage collaboratif d’une Userstory
Contrairement à ce que fait le Product Owner cité précédemment, pour être efficace, le découpage d’une Userstory doit se faire de manière collaborative, avec toute l’équipe car ce sera leur matière première pour développer et tester. Aussi, autant les impliquer au plus tôt pour qu’ils donnent leur avis.
Si vous utilisez l’Event Modeling, ce découpage se fait au moment de sa dernière étape, lorsque l’équipe décide de rassembler les évènements (en orange) de façon cohérente pour créer des Userstories.
Pour en savoir plus : Co-construction : l’Event-Modeling l’outil miracle | by Benjamin Seillier | Just-Tech-IT | Jul, 2022 | Medium
Le découpage affiné en 3 Amigos
Evidemment qu’il n’est pas trop tard pour découper une Userstory en 3 Amigos ! C’est, au contraire, le bon moment pour faire les ultimes “réglages” et préparer le développement. Mais, attention, une fois le 3 Amigos passé, il n’est plus question de toucher à ses règles !
Qu’est-ce que le 3 Amigos ?
L’objectif de l’atelier 3 amigos est de partager ensemble (Product Owner, Développeur, Testeur) la description fonctionnelle d’une Userstory en utilisant l’outil “Example Mapping” pour décrire les exemples nécessaires pour détailler et préciser les règles fonctionnelles, sans oublier de préciser les scenarii à automatiser, les cas aux limites et la Résilience.
Pour en savoir plus : Introduction to BDD Example Mapping | Cucumber Blog
Comment savoir que l’on doit découper une Userstory ?
- Il reste des questions en suspend ? Découpez la Userstory en ne traitant en 3 Amigos que le périmètre certain. Vous vous occuperez ce qui est incertain dans un second temps une fois que vous aurez les réponses,
- Impossible de trouver un exemple ? … Vous êtes sûr.e qu’il s’agit d’une règle fonctionnelle ?
- Trop d’exemples pour une règle ? Attention, vous avez le risque d’une livraison tardive de votre Userstory du fait du volume de développements et de tests. Comment pourriez-vous découper la règle ?
- Des ajustements de dernière minute, alors que le développement est en cours ? Bien sûr, tout dépendra les ajustements. Mais en théorie, vous avez le choix entre :
Des ajustements de forme ? (ex : le changement d’un libellé …)
- Ajoutez ces nouveautés dans la Userstory en cours de développement,
- Faites un 3 Amigos rapide pour expliquer les changements.
Des ajustements plus lourds ? (ex: un changement de règle fonctionnelle …)
- Bloquez la Userstory en cours de développement dans le Kanban, ne conservez que les règles qui n’ont pas été impactées et refaites-lui passer un 3 Amigos,
- Rédigez une nouvelle Userstory qui ne contiendra que les nouveautés, et faites lui passer un 3 Amigos.
Ne vous inquiétez pas. A force d’expérience, l’équipe saura de mieux en mieux découper une Userstory … Cela s’appelle l’amélioration continue !
Et le métier, qu’en dit-il ?
Vous avez indiqué à votre Métier que vous pouviez prendre entre 10 et 14 Userstories pour l’itération (suite à analyse des indicateurs de l’équipe).
Pour en savoir plus : Série “Les indicateurs d’équipe” : la prédictibilité | by Silvere Duval | Just-Tech-IT | Jun, 2022 | Medium
Cependant, voilà que, en cours de cette même itération, vous avez dû découper certaines Userstories en 3 Amigos et vous vous retrouvez avec plus de 16 Userstories dans votre Kanban ! Mais, comment faire ?
Tout d’abord, évitez de mettre sous pression l’équipe en les forçant à développer plus ! Résolvez ce risque au plus tôt avec votre Métier. En vous reposant sur votre indicateur de Prédictibilité, informez-le du risque de ne pouvoir prendre en compte toutes les évolutions initialement prévues. Prévoyez, avec eux, un plan de mitigation en analysant ce qui pourrait être déplacé pour une prochaine version et qui pourrait avoir le moins d’impact sur les objectifs fonctionnels de l’itération en cours.
Et s’ils refusent ? Soyez factuels. Informez-le des risques de problèmes de qualité (par exemple, augmentation de bugs de Production) car l’équipe se concentrera plus sur un développement rapide que sur les tests. D’autre part, cela impactera l’itération suivante puisque l’équipe devra corriger ces bugs au détriment d’évolutions fonctionnelles.
Ce n’est pas simple à faire, mais il est essentiel d’être transparent avec votre Métier.
