Faire des user-story de différents storyotypes

Le terme de storyotype n’est pas très connu en France et pourtant le concept pourrait aider certaines équipes qui ont le soucis de ne pas pouvoir toujours faire une user-story classique.

Origine des user-story ?

Aujourd’hui, la user-story est liée au Scrum comme ci elle faisait partie de son ADN ; pourtant la user-story n’est pas du Scrum à la base mais de l’Extreme Programming.

Est-ce que je fais du Scrum si j’utilise des user-story ? Oui, la user-story est un item (terme utilisé à la base dans le Scrum Guide) plus structuré qui amène encore plus de qualité au travail réalisé.

En fait le Scrum évolue et la user-story s’est imposée en Scrum car elle répond parfaitement à de nombreux projets. Cependant, si sur certains projets on peut utiliser des user-story, ce n’est pas toujours le cas.

Certains utiliseront par exemple les Spike pour faire de la recherche car le concept s’adapte très bien à certaines situations ; les équipes qui l’utilisent en sont en générale très contentes.

Article sur le concept des spike

Cependant cela ne répondra pas à tout. Sur des projets très techniques, la user-story est impossible et le spike n’est pas forcément toujours adapté.

Le storyotype apparait à ce moment là

Ce concept est de se dire qu’il existe plusieurs types d’items différents ; par exemple, nous pourrions avoir des user-story, des taches techniques, des bugs…

Quand on utilise ce concept, on change un peu la donne car on va également réaliser un Definition of Done (et Ready) par type d’item ; l’idée est intéressante car en effet dire que le test fonctionnel doit valider sur une tâche technique comme du l’installation d’un moteur d’indexation n’a pas trop de sens.

Donc en réalisant un Definition of Done par type d’item permet d’optimiser au maximum la qualité générale des travaux rendus et de ne pas avoir de confusion entre les différentes demandes.

Cette évolution est évidement à utiliser que si le besoin s’en fait ressentir car ce concept de storyotype peut complexifier un peu l’ensemble ; par contre, il est préférable d’utiliser ce type de concept que de se forcer à faire des user-story de tâches techniques.

Certains crieront : « Ce n’est pas Scrum !!! ». En fait c’est complètement Scrum car vous adaptez la méthode à votre contexte. Exactement comme les 99% de projets Scrum aujourd’hui qui utilisent les user-story.

En mettant une couleur par type d’item, il est plus facile de les reconnaitre. N’hésitez pas à mettre une petite légende sur le board mural pour rappeler le type d’item représenté par chaque couleur.

Dans les applications de la méthode Kanban, on utilise également ce concept de carte appelé des « classes de services ».

Quels changements pour le Product Owner ?

En utilisant cette méthode, on peut responsabiliser une autre personne que le Product Owner.

Par exemple si nous avons un type de story « technique » où il est nécessaire d’installer une nouvelle brique technique nécessaire pour des dizaines de user-stories futures, il est logique que ce soit les développeurs qui écrivent ce type d’items techniques et qui valident leur passage en « Done ».

Par contre, les développeurs vont devoir négocier leurs tickets face au Product Owner car il sera le seul à prioriser l’ensemble du Backlog.

Conclusion

Cette méthode peu connue peut être très utile pour améliorer votre Scrum voire pour l’adapter à des situations impossibles à gérer correctement en s’obligeant de travailler avec des user-story.

J’espère qu’elle vous sera utile le jour où vous serez dans cette problématique de ne pas qu’avoir des user-story classiques.

N’hésitez pas à partager vos expériences sur le sujet et d’éventuelles autres méthodes que vous avez eu la chance de pouvoir appliquer.