Dans la méthodologie agile, les histoires d’utilisateurs sont des outils essentiels pour transformer les idées en résultats concrets à fort impact. Mais qu’est-ce qui rend ces histoires si puissantes et, surtout, comment créer des histoires d’utilisateurs qui ont un impact ?
Dans cet article, nous expliquons comment les structurer à l’aide d’exemples pratiques et de leur intégration dans des cadres tels que Scrum et Kanban. Commençons par le commencement.

Qu’est-ce qu’une histoire d’utilisateur dans la méthodologie Agile ?

A histoire d’utilisateur est une description courte et simple d’une fonctionnalité dont un utilisateur a besoin, rédigée du point de vue de l’utilisateur. Elle est le plus souvent structurée en répondant à ces trois questions essentielles :

• Qui ?Qui est l’utilisateur qui a besoin de cette fonctionnalité ?
  
• Quoi ?Quels sont vos objectifs ? En d’autres termes, de quelle fonctionnalité avez-vous besoin ?
• Pourquoi ?Quel est l’intérêt de répondre à cette exigence ? Quels sont les avantages de cette nouvelle fonctionnalité pour l’utilisateur/le produit ?

Prenons l’exemple d’une application de commande en ligne :

« En tant que client, je souhaite recevoir des notifications concernant mes commandes afin de pouvoir suivre leur état d’avancement.

• Qui ? Le client (l’utilisateur)
• Quoi ?Les services d’aide à la décision : Recevoir des notifications sur les commandes que j’ai passées
• Pourquoi ?Pour connaître l’état de mes commandes (par exemple, quand elles arriveront).

Les récits d’utilisateurs sont essentiels pour favoriser la collaboration, car ils servent de pont entre les équipes de développement et les parties prenantes. Les récits d’utilisateurs sont un lien entre les équipes de développement et les parties prenantes, en veillant à ce que tout le monde comprenne les besoins et travaille dans le même sens.

Différence entre User Story et Epic dans Agile

Maintenant que nous savons ce qu’est une histoire d’utilisateur, voyons ce que sont les épopées et les différences entre les deux dans les environnements agiles. Elles ont des objectifs différents :

• Histoire d’utilisateurHistoire d’utilisateur : une petite unité actionnable, qui s’inscrit dans un sprint. Elle répond à un besoin spécifique de l’utilisateur.
• ÉpiqueIl s’agit d’un niveau supérieur qui regroupe des fonctionnalités plus importantes (ou sections), au service d’un thème général. Il contient plusieurs histoires d’utilisateurs ainsi que d’autres artefacts (tâches, pointes…).

Prenons un exemple :

• • ÉpopéeOptimiser l’expérience d’achat en ligne ».
  • Histoires d’utilisateurs
    • US-1 : « En tant que client, je souhaite recevoir des notifications concernant mes commandes afin de connaître leur état d’avancement ».
    • US-2 : « Permettre aux utilisateurs d’enregistrer des produits dans une liste de souhaits ».
    • US-3 : …

Et voici un exemple visuel

Éléments clés et format d’une histoire d’utilisateur

Nous avons déjà vu qu’une histoire d’utilisateur (US) nécessite au moins un titre dans le format suivant :

« Comment [rôle de l’utilisateur], je veux [action ou besoin] pour [bénéfice ou objectif] ».

Il s’agit d’une structure très courante, mais non obligatoire. Vous pouvez la faire évoluer en fonction de vos besoins pour la rendre plus utile. Ce qu’une histoire d’utilisateur devrait avoir, en dehors d’un titreIl y a plusieurs éléments clés pour en faire un succès.

1. Description : Cette fonctionnalité permettra aux clients de recevoir des notifications automatiques (par courriel, SMS ou application) sur l’état d’avancement de leurs commandes, ce qui améliorera la transparence et l’expérience des utilisateurs.
   
2. Critères d’acceptation (ou critères d’acceptation) : Ils détaillent comment savoir si l’histoire de l’utilisateur est complète. Exemple de critères d’acceptation : ils précisent comment savoir si l’histoire de l’utilisateur est complète :
   1. Les utilisateurs peuvent activer la recherche vocale.
   2. Le système reconnaît les commandes de base telles que « chercher des chaussures rouges ».
3. Définition de Done (DoD) : définit les exigences minimales pour l’achèvement, telles que les tests fonctionnels et la documentation.
4. Autres éléments : En fonction de la casuistique de l’histoire, des éléments tels que :
   1. Modèles : Images, diagrammes d’écran, mises en page UX… tout le matériel visuel qui aide à mieux comprendre (et à développer) l’histoire de l’utilisateur.
   2. Exigences techniques : détails des éléments techniques auxquels les États-Unis doivent satisfaire.

Ces éléments clés aideront tous ceux qui examinent l’histoire de l’utilisateur à comprendre clairement et spécifiquement quelle fonctionnalité doit être réalisée, la valeur immédiate pour l’utilisateur final et ce qu’il doit accomplir pour être achevé (et utile à l’utilisateur).

Examinons l’exemple sur lequel nous travaillons :

« En tant que client, je souhaite recevoir des notifications concernant mes commandes afin de pouvoir suivre leur état d’avancement.

1. 1. Description de la fonctionnalitéCette fonctionnalité permettra aux clients de recevoir des notifications automatiques (par courriel, SMS ou application) sur l’état d’avancement de leurs commandes, améliorant ainsi la transparence et l’expérience utilisateur.
   2. Critères d’acceptation:
      1. Les utilisateurs doivent pouvoir activer ou désactiver les notifications à partir des paramètres de leur compte.
      2. Les notifications doivent être envoyées dans les cas suivants :
         1. Commande confirmée.
         2. Commande en cours d’acheminement.
         3. Commande livrée
      3. Le contenu des notifications doit inclure le numéro de la commande, l’état actuel et un lien vers des détails supplémentaires.
      4. En cas d’erreur dans la soumission, le système doit enregistrer l’incident pour examen.
   3. Définition de « Done » (DoD)
      1. La fonctionnalité a été développée et testée dans un environnement d’essai.
      2. Les notifications s’affichent correctement sur les trois plateformes (courriel, SMS et application).
      3. La documentation technique et utilisateur a été mise à jour.
      4. L’équipe d’assurance qualité a validé tous les critères d’acceptation.
   4. Autres éléments
      1. DesignsMaquettes des courriels et des notifications dans l’application.
      2. Exigences UX :
         1. Les notifications doivent être visuellement attrayantes, avec un design clair et lisible.
         2. Boutons transparents permettant à l’utilisateur de « voir les détails » ou de « désactiver les notifications ».
      3. Exigences techniques :
         1. Intégration avec un service de messagerie (tel que Twilio pour les SMS ou Firebase pour les notifications push).
         2. Enregistrement des journaux d’expédition à des fins de diagnostic.

Histoires d’utilisateurs dans Scrum et Kanban

Intégration du flux de travail

Dans Scrum, les histoires d’utilisateurs sont ajoutées au carnet de commandes du produit, où le propriétaire du produit les classe par ordre de priorité en fonction de la valeur qu’elles apportent à l’utilisateur et à l’entreprise. Lors de la planification du sprint, l’équipe sélectionne les histoires qui peuvent être mises en œuvre et réalisées au cours du sprint. Ces histoires doivent être bien définies, avec des critères d’acceptation clairs et une taille gérable. Si vous souhaitez en savoir plus sur la manière de gérer le carnet de commandes, je vous recommande cet article Gestion du carnet de commandes

Dans le système Kanban, les histoires des utilisateurs circulent en continu sur un tableau divisé en colonnes telles que « À faire », « En cours » et « Terminé ». Cette approche permet de visualiser le travail en cours et de mieux gérer les goulets d’étranglement. Les histoires d’utilisateurs doivent circuler de manière fluide, en veillant à ce que chaque colonne ait une limite de travail en cours (WIP) afin de maintenir l’efficacité.

Attribuer des points de récit en Agile

L’histoire points de l’histoire sont une mesure clé dans la méthode Agile pour estimer l’effort nécessaire à la réalisation d’une histoire d’utilisateur. Ils ne représentent pas le temps, mais la complexité, l’incertitude et la quantité de travail nécessaire. Par exemple, une histoire simple peut valoir 2 points, tandis qu’une histoire plus complexe telle que « Intégrer le paiement par carte » peut se voir attribuer 8 points. Les points d’histoire sont attribués sur une échelle de Fibonacci. Vous souhaitez améliorer votre technique d’estimation des points d’histoire ? Voici quelques conseils utiles pour les équipes agiles. Les points de récit permettent non seulement de mieux planifier les sprints, mais aussi de favoriser des discussions importantes au sein de l’équipe, en alignant les attentes sur l’étendue et la complexité du travail.

Outils et bonnes pratiques

Il existe de nombreux outils qui facilitent le travail avec les histoires d’utilisateurs, tels que Jira, Trello o ClickUp. Ces plateformes permettent d’organiser les histoires, d’assigner des tâches et de suivre les progrès de manière visuelle et efficace.

Importance de la conversation et du retour d’information avec les parties prenantes

Une bonne histoire d’utilisateur ne s’arrête pas à sa rédaction ; sa véritable valeur réside dans les conversations qu’elle génère. Ces interactions sont essentielles pour garantir que les histoires reflètent les besoins réels et donnent la priorité à ce qui apporte le plus de valeur à l’utilisateur et à l’entreprise.

Pourquoi la participation des parties prenantes est-elle essentielle ?

• Assurer l’alignement : Les parties prenantes (clients, utilisateurs clés ou parties intéressées) sont celles qui connaissent le mieux le contexte et les besoins de l’utilisateur. Les inclure dans le processus permet de s’assurer que les histoires d’utilisateurs abordent les bonnes questions.
• Évitez les malentendus : Une histoire peut sembler claire sur le papier, mais en l’absence de conversations, les attentes peuvent diverger. Un bon dialogue permet de clarifier les choses avant de commencer le développement.
• Fixer des priorités : Les besoins du marché évoluent. Écouter les parties prenantes vous permet d’identifier les ajustements nécessaires avant de consacrer du temps à des tâches à faible impact.

Exemple pratique de retour d’information

Supposons que l’équipe technique suggère de simplifier une fonctionnalité pour accélérer le développement, par exemple en limitant les notifications de commande à l’envoi d’un courrier électronique.

• Retour d’information des parties prenantes : La partie prenante peut souligner que 60 % des utilisateurs préfèrent les notifications push sur leur téléphone portable, ce qui fait que la suppression de cette option a une incidence négative sur l’expérience de l’utilisateur.
• Résultat : Grâce à la conversation, l’équipe ajuste l’histoire pour inclure les notifications push comme une priorité, en s’assurant que la fonctionnalité répond aux attentes de l’utilisateur final.

La conversation comme un cycle continu

Les récits d’utilisateurs sont un point de départ, pas un contrat rigide. Grâce à un retour d’information constant :

• Les détails et les critères d’acceptation sont clarifiés.
• Les dépendances ou blocages éventuels sont identifiés avant le début des travaux.
• Les résultats sont validés une fois l’histoire terminée.

Cette approche itérative favorise une meilleure collaboration, réduit le risque d’erreurs et garantit que le produit final répond aux besoins réels du marché.

Conclusion

Les histoires d’utilisateurs sont un outil essentiel de la méthodologie agile pour relier l’équipe aux besoins réels de l’utilisateur. En les structurant correctement et en les intégrant dans des cadres tels que Scrum ou Kanban, ils facilitent la planification et garantissent une concentration sur la valeur.

Au-delà de leur rédaction, leur véritable impact réside dans les conversations qu’ils suscitent. L’implication des parties prenantes permet de s’assurer que chaque histoire reflète des priorités claires et s’aligne sur les objectifs de l’entreprise.

Commencez par appliquer ces techniques et adaptez les récits d’utilisateurs aux besoins de votre équipe. Grâce à une approche collaborative et agile, vous transformerez vos idées en fonctionnalités qui feront la différence.