Les récits utilisateurs, initialement proposés dans la gestion agile de projets informatiques, trouvent tout leur intérêt dans le domaine de la Business Intelligence.

Définition

Un récit utilisateur, ou user story en anglais, est une description simple d’un besoin ou d’une attente exprimée par un utilisateur et utilisée dans le domaine du développement de logiciels et de la conception de nouveaux produits pour déterminer les fonctionnalités à développer. Source : Récit utilisateur, Wikipedia

La notion de récit utilisateur est apparue la première fois dans le contexte de la mise oeuvre d’une approche de génie logiciel nommée extreme programming (XP). Elle est désormais couramment utilisée dans les approches agiles. La page Mener un projet de Business Intelligence en mode agile explique quel est l’intérêt de ce type de méthode de gestion de projet dans le contexte de la Business Intelligence.

Indépendamment du choix de la méthode de gestion de projet, qui n’est pas l’objet de cette page, la notion de récit utilisateur a un intérêt majeur pour formuler les besoins fonctionnels. Nous vous proposons de découvrir maintenant pourquoi.

Structure d’un récit utilisateur

La structure d’un récit utilisateur est la suivante :

En tant que [utilisateur-type], je désire [une fonctionnalité] afin de [finalité].

où :

  • utilisateur-type : il doit correspondre à un rôle / une fonction clairement identifiable (le responsable marketing, le directeur des ressources humaines, un responsable des ventes, etc.). La description de l’utilisateur-type doit être cohérente avec la fonctionnalité spécifiée et la nature des décisions pouvant être prises.
  • fonctionnalité : il s’agit d’un besoin en terme d’analyse d’un phénomène ou d’analyse de la performance d’un processus (la satisfaction client, les performances des ventes, etc.). Ce n’est pas le lieu de lister les indicateurs possibles ou nécessaires, mais prenez en note et mettez les en annexes pour la phase de construction des indicateurs.
  • finalité : il s’agit d’expliciter en quoi le besoin énoncé vient accompagner l’utilisateur-type pour prendre des décisions afin d’atteindre les objectifs fixés par la stratégie de son entreprise.

Les 8 erreurs à éviter

Une première approche pour rédiger de bons récits utilisateurs est d’éviter les erreurs communes suivantes.

La fonctionnalité doit aider à la conception du tableau de bord

  1. Éviter les fonctionnalités non liées à l’analyse de tableaux de bord :
    • réaliser une étude de marché
    • réaliser une étude financière
    • développer une application mobile
    • adapter mes campagnes publicitaires
  2. Éviter les fonctionnalités hors du contexte de la Business Intelligence :
    • comparer [mes produits] à ceux des autres chaînes
  3. Éviter les fonctionnalité sous forme d’outil :
    • je souhaite obtenir un outil de mesure de la satisfaction client
  4. Éviter les fonctionnalités multiples dans le même récit :
    • mieux cibler […], développer l’offre […], augmenter la satisfaction […]
  5. Éviter les fonctionnalités qui sont l’objectif métier

La finalité doit conduire à la prise de décision

  1. Éviter une finalité qui n’est pas une décision mais un objectif :
    • afin que la quantité livrée puisse être multipliée par cinq
    • pouvoir améliorer la qualité de mon service de livraison
  2. Éviter une finalité qui est une décision peu précise :
    • afin d’améliorer la qualité de livraison
  3. Éviter les finalités multiples
    • afin de permettre à la chaîne […], de mieux cibler […], d’augmenter la satisfaction […]

Critères de qualité d’un récit utilisateur

La qualité d’un récit utilisateur peut être évalué au moyen du modèle INVEST pour Independent - Negotiable - Valuable - Estimable - Small - Testable. Certains critères de ce modèle ne sont applicables que si l’on évalue un ensemble de récits dans le cadre d’un projet et non juste la qualité d’un récit pris indépendemment de tout contexte.

Modèle INVEST
Modèle INVEST

Précisons ces différents critères :

  • Indépendant : un récit utilisateur ne doit par être dépendant de la réalisation d’un autre récit utilisateur réalisé lors de la même itération.
  • Négociable : un récit utilisateur doit pouvoir être négocié par les différentes parties prenantes, c’est à dire qu’ils doivent être clairs et intelligibles par tout le monde (du client et des utilisateurs finaux, à la maîtrise d’oeuvre en passant par l’assistance à maîtrise d’ouvrage).
  • Valorisable : un récit utilisateur doit conduire à la prise d’une décision. Un récit qui ne conduit à rien en terme d’amélioration des performances des processus de l’entreprise est inutile.
  • Estimable : un récit utilisateur est suffisamment clair pour qu’on puisse estimer son temps de développement.
  • Petit : un récit utilisateur doit être le plus atomique possible de façon à faciliter son développement.
  • Testable : un récit utilisateur doit contenir tous les éléments nécessaires pour pouvoir être testé.

Lecture User Stories : comment bien les rédiger, par Margaux de Hubvisory, https://hubvisory.com/blog/user-stories-comment-bien-les-rediger/, Consulté le 30 novembre 2020.

Lecture Splitting user stories – Why, When, How, par Alin Pandichi, https://mozaicworks.com/blog/splitting-user-stories/, Consulté le 2 avril 2020.

Récits utilisateurs épiques

Certains récits utilisateurs peuvent être considérés comme trop volumineux et non pertinents car ils ne pourront pas être réalisés lors d’une même itération.

Plutôt que de les abandonner, posez-vous la question s’ils ne peuvent pas être utilisés en tant que récits utilisateurs épiques du projet, en réunissant plusieurs récits plus petits.

Les récits utilisateurs épiques permettent ainsi de donner une vision d’ensemble du projet sans rentrer dans le détail. On se donne ainsi la possibilité de préciser certains récits utilisateurs dans les phases ultérieures du projet.

Et ensuite ?

C’est dans un second temps, en fonction des utilisateurs, des fonctionnalités attendues et des décisions à prendre, que vous devrez spécifier comment vous allez répondre à ce besoin. Pour cela, vous devrez définir :