User story technique

Il n’est pas rare de rencontrer le concept de user story technique. Mais qu’est-ce que c’est ? Est-ce une bonne idée ? Cet article devrait répondre à l’ensemble de vos questions

Qu’est-ce une user story technique ?

Nous pouvons représenter une user story technique de plusieurs manières.

Une demande 100% technique

Certaines équipes utilisent les user story technique pour faire des blocs techniques toujours séparés des user story normale. Du coup les équipes écrivent souvent celles-ci de cette façon :

« En tant que développeur, je souhaite avoir la modèle de données du panier »

User story technique 

Est-ce interdit de fonctionner comme ça ? Non
Est-ce recommandé en général ? Non

En effet, scrum parle d’items et ne dit pas comment et quels types d’items doivent être utilisés. La user-story très installée dans les équipes scrum n’est pas une pratique scrum.

Quand on utilise ce type de user story technique , c’est souvent parce qu’on utilise les user-stories (fonctionnelle). Mais les user-stories sont définies par l’acronyme INVEST qui détermine avec le I que chacune d’entre elles doivent être indépendantes dans le sprint qu’elles intègrent.

Le fait de sortir la partie technique de celle-ci va la rendre dépendante de cette user story technique. Bien que cela est gérable, ça complexifie souvent inutilement la priorisation du backlog pour le product owner.

Un pré-requis technique

Quand les équipes utilisent réellement les estimations, elles vont parfois utiliser les NFR (Non-Functional Requirements).

Sachez qu’il existe 3 définitions différentes des NFR :

• des items techniques
• des critères du definition of done
• des critères dans les items

Comme vous l’aurez compris, nous prendrons ici la définition qui définit un NFR comme un item technique.

Ces items permettent de mettre en sous-tâche les pré-requis techniques qui sont essentiels pour lancer le projet.

Est-ce interdit de fonctionner comme ça ? Non
Est-ce recommandé en général ? Ca dépend

Pour les équipes qui veulent démarrer un projet, ces NFR sont très pratiques. Elles permettent de laisser toute indépendance technique aux user-stories. Si le sprint contient 5 user stories nécessitant une base de données, un NFR base de données sera d’une grande aide. En effet, les équipes sont vite perturber en ne sachant pas sur quelle user-story estimée l’effort pour l’installation de la base de données.

Bien que le scrum rappelle que les items doivent être estimés, certaines équipes ont abandonné volontairement les estimations (mouvement #NoEstimate). Et dans ce cas, il n’y a plus réellement de soucis ; ce cas amènerait l’utilisation des NFR quasiment inutile.

N’hésitez pas à lire notre article complet sur les NFR.

Article : NFR (Nonfunctional Requirements) en Scrum ?

Conclusion user story technique

Ce type d’items se rencontrent fréquemment. Cependant, si rien ne vous interdit de les utiliser, tentez de le faire pour de bonnes raisons. Certaines pratiques comme nous avons vu vont à l’encontre même des user-stories elles mêmes.

Pour conclure, réfléchissez bien à leurs utilisations et évitez de complexifié inutilement la gestion du backlog. Utilisez vous ce type d’items dans vos backlog ? N’hésitez pas à partager vos expériences en commentaire et à partager vos avis positifs et négatifs.

Lien utile : Product Backlog – scrum.sg (en)