Faire des user-story de différents storyotypes

Ecrit par << Paquet Judicaël >>

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 refactoring 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.

storyotype
storyotype

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 « refactoring » car nous sommes en présence d’une application qui vieilli et qui a beaucoup de Legacy, 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 défendre 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.

7 réponses sur “Faire des user-story de différents storyotypes”

  1. Bonjour,
    Sans parler de « storyotype », Scrum identifie déjà 4 types de stories.
    – Les stories fonctionnelles (user stories)
    – Les stories techniques (comme installer RabbitMQ)
    – Les stories de correction de bug
    – Les stories de remboursement de dette technique

    On adapte donc pas Scrum. On fait du Scrum 🙂

    L’erreur courante est en effet de ne faire figurer que les US au tableau.
    La deuxième erreur est de ne pas prendre le temps d’identifier ces stories et de les noyer dans les US.
    Fatalement, l’US se retrouve bloquée et on ne comprend pas pourquoi une US estimée à 3 points prend plus de temps qu’une US estimée à 8 points …
    Si l’US est critique pour l’objectif du Sprint … c’est la cata

    J’aime l’idée que le backlog soit accessible à tous et que chacun puisse y mettre ses idées dans un « bac à sable ».
    Cela permet à l’équipe de proposer au PO certaines stories et de lui faire prendre conscience qu’il y a encore « beaucoup plus à faire » qu’il ne s’imagine et que ces stories doivent être confrontées aux US dans leur priorisation.

    Merci d’avoir rappelé ce point.
    Oui les développeurs peuvent écrire des stories.
    Oui ils peuvent les défendre, les estimer, les confronter et donner encore plus de transparence au projet.
    Et oui, c’est du Scrum !

    1. Le Scrum ne précise rien, il parle d’item en fait. C’est l’application du Scrum qui a amené les US voire pour certains les storyotypes.
      Merci pour ton intervention 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.