Préparation des User Stories

Une User Story décrit comment un utilisateur final parvient à un résultat donné grâce à une application. Il s’agit d’un moyen centré sur l’humain, permettant de documenter des exigences métier sous une forme simple et concise. Une User Story constitue la plus petite unité d'œuvre à développer au sein de l’application.  

L’objectif principal des User Stories en tant qu’artéfacts de projet consiste à aider l’équipe de développement à effectuer le suivi (dans le backlog du projet) de toutes les fonctionnalités nécessaires au développement et à l’implémentation pour le compte du client. Les User Stories décrivent les spécifications requises, de manière à pouvoir concevoir des fonctionnalités qui satisferont le Product Owner et, au final, l’utilisateur métier. Une équipe crée une User Story en s’appuyant sur son expérience et ses connaissances collectives. 

Les User Stories se caractérisent essentiellement par les points suivants :

• Elles sont centrées sur l’humain
• Elles sont faciles à comprendre
• Elles reflètent fidèlement la valeur métier que reçoit le client
• Elles peuvent être testées

Pour commencer, vous devez documenter deux éléments importants dans une User Story. Ces éléments clarifient les aspects à développer et les critères à satisfaire pour considérer la User Story comme complète.   

Ces deux éléments sont :

• Description de User Story
• Critères d’acceptation 

Vous pouvez également ajouter dans chaque User Story des éléments optionnels (pièces jointes, notes techniques) destinés à clarifier les détails du besoin à satisfaire. 

Toutes les User Stories possèdent une taille et un statut permettant de faciliter leur gestion. Vous devez mettre à jour ces paramètres à mesure de l’avancement de la User Story dans son cycle de vie, depuis sa forme initiale jusqu’à son achèvement.

La description de la User Story a pour objet de synthétiser les exigences métier du client. Elle permet de vérifier que vous avez bien répondu aux questions « qui » (les utilisateurs qui ont besoin de la fonctionnalité ou de la fonction), « quoi » (la nature de ce besoin) et « pourquoi » (les raisons de ce besoin). Une User Story doit être brève, rédigée dans un langage adapté aux utilisateurs et elle doit identifier clairement la valeur métier.  

La formulation classique d’une User Story respecte la structure simple suivante :

• En tant que… [Qui ? - Insérer l’utilisateur]  
• je souhaite… [Quoi ? - Insérer ce que l’utilisateur souhaite faire]    
• pour que… [Pourquoi ? – Insérer la valeur métier]

La préparation des User Stories et les discussions à leur sujet sont des aspects extrêmement importants. C’est uniquement par le dialogue que vous pouvez acquérir une compréhension collective des enjeux. Ne cédez pas à la tentation de transcrire cette compréhension collective dans une documentation complexe. Concentrez-vous sur les fondements de la User Story, et complétez-en les détails avec des pièces jointes.

Dans l’exemple suivant, la description est rédigée dans un langage métier définissant clairement l’utilisateur, le besoin et la valeur métier associée à l'implémentation de la User Story. Veillez également à ce que la description soit brève.

Les critères d’acceptation affinent la User Story, de sorte que les développeurs comprennent les objectifs de l’application et que les testeurs identifient clairement les éléments à tester. Le Product Owner est tenu de définir l’expérience métier attendue de la User Story et d’en approuver les critères d’acceptation. Les critères d’acceptation d’une User Story doivent être rédigés en termes non ambigus, faciles à comprendre par les utilisateurs métier (et par les membres non techniques de l’équipe). 

Ils doivent être formulés en termes de résultat, et non sous forme d’instructions techniques destinées à l’équipe de développement. Ils doivent être délibérément négociables, et préserver ainsi pour l’équipe de développement une marge de manœuvre lui permettant de réaliser la solution en coopération avec les utilisateurs métier. Mais, même négociables, les critères d’acceptation doivent être suffisamment précis pour pouvoir être testés. 

Dans l’exemple suivant, les critères d’acceptation sont rédigés sous forme d’objectifs spécifiques et testables :

La User Story fournie en exemple illustre une manière de formuler vos critères d’acceptation. Il existe toute une gamme de styles permettant de documenter les critères d’acceptation, notamment l’acquisition de critères basés sur des scénarios. Par exemple, votre équipe peut opter pour l’utilisation de l’approche « Étant donné, Quand, Alors », organisée comme suit :

• Étant donné (Given)...{pré-condition} : Exemple : « Un membre Premium est éligible à des offres promotionnelles... »
• Quand (When)...{quelque chose est réalisé}. Exemple : « ils ont sélectionné leurs catégories d'offres favorites et complété le processus d'inscription... »
• Alors (Then)…{résultat attendu} Exemple : « ...le système ajoutera automatiquement le membre aux promotions sélectionnées à venir. »

Au début du projet, votre équipe établit ce que signifie pour elle la « Definition of Ready » (DoR). L’équipe s’accorde sur une DoR lors de la phase de préparation pour établir une référence en matière de contrôle qualité de la User Story. Chaque projet parvient à un tel accord avec les différents intervenants métier et techniques de l’équipe. La DoR établit la liste des critères à satisfaire impérativement avant que la User Story soit prête à être créée. Une fois la User Story prête (conformément à la DoR), vous pouvez la marquer comme admissible à la planification de sprint. 

En général, la DoR consiste en une checklist de critères. Ces critères définissent les contenus qui doivent être présents dans la User Story, les processus de contrôle ou les approbations qui ont dû avoir lieu ainsi que les artéfacts qui doivent être collectés ou joints. La feuille de calcul suivante représente une User Story comportant 12 critères à satisfaire.

Une DoR prédéfinie permet de s’assurer que tous les membres de l’équipe connaissent les spécifications minimales d’une User Story. Elle permet également de confirmer que toutes les User Stories placées dans un sprint ont été soumises à un contrôle qualité et peuvent être correctement livrées dans le sprint.

L’affinement d’une User Story a pour but de vérifier que votre équipe comprend parfaitement l’intention et la portée de celle-ci. Il s’agit d’un processus itératif qui fait évoluer le contenu d’une User Story de manière à répondre à la DoR. L'approche Pega Express^™ delivery met en avant la prise en compte directe des objectifs (Direct Capture of Objectives ou DCO) afin d’assurer la collaboration avec tous les acteurs concernés. La DCO est utilisée tout au long du processus d’affinement afin de vérifier que chaque User Story contient toutes les informations nécessaires, quel que soit le point de vue. 

L’affinement d’une User Story commence avec une ébauche qui peut contenir à peine plus qu’une brève description. L’affinement se termine lorsque vous livrez la User Story à l’équipe technique pour la dimensionner. 

Ébauche de User Stories

Le Business Architect, le Product Owner et les autres intervenants concernés débattent de la User Story afin de clarifier les objectifs métier et les exigences des utilisateurs. Une fois cette étape franchie, ces acteurs partagent la User Story avec l’équipe technique pour que celle-ci poursuivre l’affinement (refinement).

Affinement

Les équipes métier et techniques travaillent de manière coordonnée. Cette collaboration englobe le product owner, les experts (SME), les UX designers, les spécialistes des tests, les Business Architects, les System Architects et les spécialistes IT. Les équipes analysent la User Story et en clarifient les détails. Ce processus d’affinement peut s’étaler sur plusieurs sessions de DCO, avant que l’équipe ne considère que la User Story ait été débattue en détail et documentée correctement. 

Suivant la nature de la User Story, vous devrez peut-être ajouter des artéfacts tels que : 

• Des e-mails d’approbation
• Des wireframes d’interface utilisateur
• Des process maps et des règles métier
• Des diagrammes de logique de décision

Dans le cadre des sessions d’affinement, l’équipe technique interprète les critères d’acceptation et traduit les résultats sous forme de composants à configurer au sein de l’application. L’équipe technique identifie également toutes les dépendances éventuelles de la Story par rapport aux autres User Stories ainsi que les impacts qu’elle peut avoir sur les fonctionnalités existantes et sur les domaines particulièrement complexes.

Il est possible que l’équipe technique doive prendre en compte des spécifications non fonctionnelles (exigences d’accessibilité spécifiques à certains utilisateurs, par exemple). Ces spécifications peuvent être perdues si elles ne sont pas documentées dans la User Story. Au cours du processus d’affinement, l’équipe documente ces détails dans la User Story à l’aide de pièces jointes supplémentaires ou de critères d’acceptation spécifiques. 

À mesure que l’affinement de la User Story progresse, vous pouvez vous rendre compte que celle-ci est trop longue ou trop complexe. Dans ce cas, décomposez-la en plusieurs User Stories.  Il se peut également que votre travail révèle une lacune dans les exigences et rende nécessaire l’ajout de User Stories supplémentaires dans votre backlog.

Après l’affinement des User Stories

Le processus d’affinement se termine lorsque :

• L’équipe s’accorde sur le fait d’avoir bien saisi les enjeux de la User Story
• Toutes les informations supplémentaires venant compléter la User Story ont été ajoutées à celle-ci
• Le Product Owner approuve les critères d’acceptation  

À l’issue du processus d’affinement, l’équipe technique est en mesure de dimensionner la User Story. Ce dimensionnement marque la fin du processus d’affinement.

Dans le cadre du processus d’affinement, l’équipe technique identifie les tâches techniques à effectuer pour remplir les critères d’acceptation d’une User Story. Certaines configurations techniques nécessitent une attention particulière. L’équipe peut distinguer ces tâches des opérations de configuration. Pour faciliter l’affectation des tâches dans le cadre de Scrum et pour veiller à ce que les composants réutilisables soient développés avec les critères d’acceptation appropriés, l’équipe Scrum peut décider de créer une Story technique composée uniquement d’éléments techniques.  

En général, les exemples de Stories techniques contiennent :

• La configuration des connecteurs d’interface
• Des harness de test
• Un référentiel DevOps
• De nouveaux environnements
• D’autres éléments techniques requis pour prendre en charge plusieurs User Stories

Lors du processus d’affinement, la Story technique est considérée comme dépendance de toute User Story pour laquelle ces composants techniques génériques sont requis. Les Stories techniques permettent aux membres de l’équipe de travailler en parallèle pour livrer dans le même sprint les User Stories associées. L’équipe distingue également les tâches liées à la création des ressources techniques des tâches de développement de solutions métier.

Les Stories techniques sont soumises aux mêmes règles que les User Stories dans la mesure où :

• Elles doivent vérifier que la Definition of Ready est affectée à un sprint
• Elles sont dimensionnées de la même manière que les User Stories non techniques

Il existe plusieurs manières de refléter la taille d’une Story. Le Story pointing, qui consiste en l'attribution de points à chaque Story, est une activité menée à la fin du processus d’affinement. Cette activité a pour but de dimensionner la complexité d’une Story. Le nombre de points attribués est proportionnel à la complexité de la Story et aux efforts requis pour configurer, tester et implémenter celle-ci. Une approche courante consiste à utiliser la suite des nombres de Fibonacci. Cette suite permet à l’équipe de classer les Stories en termes de complexité relative.

L’échelle de Fibonacci suivante détermine les points de la Story :

• 1 point = Story de très petite taille
• 2 points = Story de petite taille
• 3 points = Story de taille moyenne
• 5 points = Story de taille moyenne à grande
• 8 points = Story de grande taille
• 13 points = Story de très grande taille
• 21 points et plus = la Story doit être considérée comme un EPIC et décomposée en Stories plus petites.

Estimation avec des catégories de complexité (complexity buckets)

Il peut s’avérer difficile d’évaluer la complexité d’une Story de manière cohérente car chaque membre de l’équipe a sa propre conception de la complexité. On peut estimer la complexité d’une Story à l’aide de catégories (buckets) de complexité : l’équipe peut dimensionner les Stories de manière cohérente en analysant chacune d’entre elles en termes de catégories de complexité prédéfinies avant d’attribuer une note finale.   

Lors de la phase de préparation, l’équipe doit s’accorder sur les critères les plus appropriés pour évaluer la complexité de la Story. Chaque critère devient une catégorie de complexité. Pour chacune de ces catégories, l’équipe doit s’accorder sur une échelle de complexité allant de Faible à Moyenne, Élevée ou Très élevée. Par exemple, les développeurs doivent prendre en compte les implications de la User Story sur le plan de l’interface utilisateur, les volumes de tests, la configuration, le nombre de règles métier et les intégrations de données, lorsqu’ils décident de leur niveau de dimensionnement. Pour chaque niveau de complexité, on attribue un nombre de points. 

Les catégories de complexité comprennent habituellement les éléments suivants :

• Interface utilisateur
• Logique métier
• Donnée
• Aspects d’intégration
• Tests   

Lors de la session de dimensionnement, l’équipe analyse chaque Story par rapport à l’ensemble des critères et calcule le nombre total de points de la Story en fonction du degré de complexité de chaque catégorie. Ce total est alors rapproché du nombre de Fibonacci approprié. Lorsque ce total ne correspond pas exactement et se trouve dans un intervalle entre deux nombres de Fibonacci, l’équipe décide du nombre de Fibonacci supérieur ou inférieur qui représente le mieux la complexité et attribue cette valeur à la Story.

Une fois estimée, la User Story est prête à être examinée par le project owner lors de la prochaine session de planification de sprint. 

L’une des questions les plus fréquemment posées à propos d’un projet Agile est la suivante : « Comment caractériser une User Story réussie ? » Il n’existe pas de modèle universel pour une User Story, mais un modèle propre à chaque équipe. Les spécifications collectives d’une User Story varient en fonction d’un ensemble d’expériences et de contextes sectoriels.   

L’exemple suivant illustre les caractéristiques d’une Story réussie, une fois celle-ci entièrement élaborée, affinée avec l’équipe technique, examinée par rapport à la Definition of Done et déclarée prête à être développée. Dans cet exemple, recherchez les éléments suivants :

• Nom de la story
• Description 
• Critères d'acceptation
• Taille de la Story  
• Statut de la Story
• Informations supplémentaires 

Vérifiez vos connaissances avec l’interaction suivante.