Quelle est la différence entre les histoires d’utilisateurs et les exigences ?

Bien que la plupart des nouvelles fonctionnalités devraient être définies du point de vue de l’utilisateur, en pratique, lors de la définition des exigences que les équipes de développement doivent implémenter, nous oublions souvent le « pourquoi » du point de vue de l’utilisateur. L’accent d’une histoire d’utilisateur porte sur l’expérience — ce que la personne utilisant le produit souhaite accomplir. Les exigences traditionnelles mettent l’accent sur la fonctionnalité — ce que le produit doit faire. Les différences restantes résident dans les listes subtiles mais cruciales du « qui », du « comment » et du « quand ».

Les histoires d’utilisateurs doivent être rédigées en une ou deux phrases, en capturant qui est l’utilisateur, ce qu’il souhaite et pourquoi. Une structure simple pour définir des fonctionnalités ou des histoires d’utilisateurs est la suivante :

En tant que ______, je veux ______, afin de pouvoir ______.

Exemple :

En tant qu’utilisateur, je veux réinitialiser mon mot de passe afin de pouvoir récupérer l’accès au système si je l’oublie.

Malgré des objectifs différents, les histoires d’utilisateurs et les exigences visent toutes deux à créer un produit que les clients aiment.

Qu’est-ce qu’une histoire d’utilisateur ?

Les histoires d’utilisateurssont des exigences exprimées du point de vue de l’utilisateur final. Les histoires d’utilisateurs peuvent également être appelées épisodes, thèmes ou fonctionnalités, mais elles suivent toutes le même format.

Essentiellement, une histoire d’utilisateur est une exigence clairement exprimée. Pour plusieurs raisons, le format d’histoire d’utilisateur est devenu la méthode la plus populaire pour exprimer les exigences en Agile :

• Elle se concentre sur le point de vue de la personne qui utilise ou est affectée par la solution.
• Elle définit les exigences dans un langage significatif pour ce rôle.
• Elle aide à clarifier le véritable objectif derrière l’exigence.
• Elle aide à définir les exigences de haut niveau sans plonger trop tôt dans les détails de bas niveau.

Identifiez les objectifs de l’utilisateur et considérez immédiatement la valeur commerciale de chaque exigence dans l’histoire d’utilisateur.

Les histoires d’utilisateurs sont généralement considérées comme contenant trois éléments — le 3C:

• CARD – Doit être écrit sur une carte de note ou un post-it.
• Cconversation – Obtenir des informations détaillées auprès du propriétaire du produit (Propriétaire du produit).
• Cconfirmation – S’assurer qu’elle est correctement implémentée. Doit satisfaire les critères d’acceptation utilisateur.

Format de l’histoire d’utilisateur

Le format d’une histoire d’utilisateur est le suivant :

En tant que <rôle>, Je veux <objectif>, afin que <avantage>

Ces deux exemples illustrent des histoires d’utilisateurs à différents niveaux, mais en utilisant le même format :

Au niveau du projet :

En tant que <Directeur marketing>, Je veux <améliorer le service client>, afin que <nous conservons nos clients>.

• Écrire des objectifs SMART et INVEST pour les histoires d’utilisateurs
• Thème vs Épique vs Histoire d’utilisateur vs Tâche
• Qu’est-ce que DEEP dans le backlog produit ?
• Comment rédiger la vision produit pour un projet Scrum ?
• Comment utiliser le tableau Scrum pour le développement agile ?
• Qui crée les éléments du backlog produit ou les histoires d’utilisateurs dans Scrum ?
• Qu’est-ce que l’estimation agile ?
• Qu’est-ce qu’un point d’histoire en agile ? Comment estimer une histoire d’utilisateur ?
• Découpage des histoires d’utilisateurs – Tranche verticale vs tranche horizontale