Histoire d'utilisateur

Qu'est-ce qu'une user story ?

Une user story fait partie d'un cadre de gestion de projet agile. Elle décrit les fonctionnalités que les utilisateurs finaux souhaitent pour optimiser leur satisfaction avec un produit et en tirer le maximum de valeur possible.

La déclaration de la user story se réfère généralement à un objectif spécifique et à la raison pour laquelle une fonctionnalité séduit l'utilisateur. Par exemple, « En tant que visiteur du site, je veux voir un menu ou une liste de cours disponibles pour m'aider à trouver le meilleur à suivre » serait une user story pour quelqu'un qui consulte un site web d'éducation en ligne.

Les user stories sont toujours du point de vue de l'utilisateur, bien que ce soit l'équipe interne qui les rédige. Elles sont généralement stockées dans un logiciel de gestion de projet pour que l'équipe de projet puisse les consulter lors du développement de nouveaux produits et services.

Types de user stories

Les user stories créées pour chaque projet seront conservées dans le backlog produit pour une référence facile pendant le développement du produit. Les équipes agiles peuvent utiliser trois types de user stories.

• Les user stories cibles sont le type le plus courant. Elles sont formulées du point de vue du client cible du produit pour créer une déclaration facile à comprendre que l'équipe peut utiliser pour construire des fonctionnalités autour des désirs et des besoins des clients.
• Les non-user stories sont efficaces lorsque les fonctionnalités d'un produit n'ont pas de corrélation directe avec l'utilisateur, mais peuvent néanmoins être utiles pour l'équipe de développement. Dans ces situations, une déclaration non-utilisateur aide à construire un meilleur produit global.
• Les spikes sont de brèves déclarations qui indiquent à l'équipe qu'une recherche plus approfondie est nécessaire sur un ou deux problèmes, qui peuvent ensuite être testés pour éviter d'autres problèmes à l'avenir. Des problèmes peuvent survenir en fonction des user stories et des non-user stories qui doivent être abordés.

Éléments de base des user stories

Les user stories diffèrent selon le projet et le type d'utilisateur. Mais leur composition de base devrait être similaire, en utilisant les quatre éléments :

• La carte. Chaque user story doit suivre le format « en tant que [qui], je veux [quoi] afin que [pourquoi] ». Nommé la carte pour aider à limiter l'espace, cet élément doit être aussi général que possible pour garder la déclaration simple.
• La conversation. Comme les membres de l'équipe interne sont ceux qui rédigent les user stories, la partie conversation du développement de celles-ci consiste à reproduire les sujets qu'un utilisateur cible pourrait discuter lors de l'utilisation du produit. Cela devrait être un processus collaboratif entre les parties prenantes et les développeurs.
• La confirmation. Avant que les user stories puissent informer le développement du produit, l'équipe interne doit s'accorder sur les critères d'acceptation. Tous les utilisateurs n'auront pas des suggestions qui se transforment en fonctionnalités de produit.
• Le contexte. Les histoires individuelles sont utiles pour développer des fonctionnalités, mais elles doivent se rapporter au concept plus large du produit.

Avantages des user stories

De nombreuses user stories informent l'équipe de développement sur des besoins ou des désirs similaires qu'ils recherchent dans un produit. Les développeurs peuvent ensuite prendre en compte ces informations dans leur travail. Certains des autres avantages de l'engagement avec les user stories incluent :

• Améliorer le produit final. Bien que les retours ne proviennent pas nécessairement de l'utilisateur final, les user stories obligent l'équipe interne à penser comme tel. Cela encourage la conversation autour de ce qu'un utilisateur veut du produit.
• Travailler avec les parties prenantes clés. Les utilisateurs seront la principale pensée derrière les user stories, mais d'autres parties prenantes clés peuvent avoir besoin d'une contribution interne aux changements de produit. Les user stories aident à fusionner ces retours avec les besoins de l'utilisateur final d'une manière qui fonctionne pour tout le monde.
• Prévenir les problèmes avant qu'ils ne surviennent. En pensant comme un utilisateur, l'équipe de développement pourrait localiser des problèmes qui ont été initialement négligés. Cela leur donne l'occasion de les corriger avant que le produit ne soit trop développé.

Meilleures pratiques pour les user stories

Bien que le format d'écriture d'une user story soit assez simple, il est important de considérer plusieurs meilleures pratiques lors de leur élaboration.

• Se concentrer sur le pourquoi, pas le quoi. La fonctionnalité elle-même est importante dans le développement de produit, mais la raison dans la user story doit rester le moteur principal derrière toute décision. Clarifiez les fonctionnalités concernant les différents besoins des utilisateurs, plutôt que la fonctionnalité spécifique du produit.
• Développer une meilleure compréhension des utilisateurs. Pour rédiger des user stories efficaces, les équipes devraient envisager de construire des personas utilisateurs à partir de recherches et d'informations clients. Cela rend les user stories plus précises par rapport à l'expérience vécue.
• Prioriser et revisiter d'autres histoires. Même si certaines user stories ne sont pas initialement utiles, il est bon de garder le reste pour l'avenir, surtout avec de nouveaux produits qui peuvent subir des refontes. C'est particulièrement utile lorsque les équipes produit peuvent comparer des données clients réelles aux user stories.

Recueillez des données produit et des retours directement de vos clients, puis organisez-les pour votre équipe interne en utilisant un logiciel de gestion des retours d'entreprise dédié.