Les user stories (récits d’utilisateur) sont un outil simple pour articuler le point de vue de l’utilisateur. Ce ne sont pas de longues histoires verbeuses à raconter autour d’un feu de camp, mais plutôt de courtes descriptions (souvent une seule phrase) de ce qu’un utilisateur fera avec une partie d’un système. Ils sont rédigés dans un anglais [français] simple ou dans la langue de l’entreprise dans laquelle ils seront utilisés et ne nécessitent aucun don littéraire spécial ni talent linguistique pour composer.

Ils sont particulièrement importants dans les environnements agiles où ils facilitent la fonctionnalité d’un système mais peuvent être utilisés dans n’importe quel environnement pour garantir que le design et le développement sont axés sur les besoins des utilisateurs. Ils fournissent le « qui », le « quoi » et le « pourquoi » des besoins des utilisateurs dans un format qui peut être facilement compris par quiconque a besoin de les utiliser.

Le contexte des user stories

Les récits d’utilisateur ont été décrits pour la première fois dans Extreme Programming en 1998. Il y a été mentionné que les récits d’utilisateur pouvaient être utilisés pour définir la portée d’un projet de développement d’une manière similaire aux cas d’utilisation (les cas d’utilisation sont des descriptions visuelles des actions prises par un utilisateur, généralement enregistrés en UML – Universal Markup Language).

Les cas d’utilisation UML sont des diagrammes visuels qui capturent les exigences et les acteurs – ils sont très différents des user stories.

Cependant, il est communément admis aujourd’hui qu’un cas d’utilisation et un user story remplissent des fonctions différentes. Les cas d’utilisation traitent de la manière dont une exigence sera traitée, tandis qu’un user story capture simplement l’exigence.

Capturez toujours les user stories d’une manière qui vous semble utile et n’interfère pas trop avec la conversation utilisateur/client – vous pouvez toujours les réviser plus tard.

Écrire des user stories

Dans de nombreux cas, les user stories ne sont pas créés par l’équipe de design ou de développement – elles sont fournies par un client ou un utilisateur professionnel pour essayer d’expliquer à quoi il aimerait que le produit fini ressemble. Cependant, cela ne signifie pas qu’en l’absence de récits fournis par les clients / utilisateurs, l’équipe ne peut pas créer les siens. Dans les grandes organisations, cette responsabilité peut être couverte par les chefs de produit ; dans d’autres organisations, elle peut relever de la compétence de l’équipe UX.

Alors que, dans l’ensemble, un user story va capturer fonctionnellement une exigence du produit, il peut également être utilisé pour décrire les capacités non fonctionnelles des produits (par exemple, les exigences de confidentialité ou de sécurité).

Comme l’a dit Steve Rogers, le célèbre designer :

Designer un produit, c’est designer une relation.

Pour créer cette relation, les récits d’utilisateur sont toujours meilleurs lorsqu’ils sont créés avec la contribution des utilisateurs ou du client final et peuvent facilement être modérés par un designer ou un développeur travaillant en collaboration avec un représentant de la base d’utilisateurs / clients.

L’idée est d’utiliser un format simple de questions et réponses pour développer le récit. Ensuite, le designer ou le développeur enregistre chaque récit sur une seule carte. Ce récit peut ensuite être révisé pour plus de clarté une fois l’exercice de capture des exigences terminé.

Le format généralement accepté pour les user stories est :

« En tant que , je voudrais , pour ça »

Ce format a été proposé en 2001 par une équipe travaillant pour Connextra dans une histoire liée à AgileCoach sur Typepad.

Il existe de nombreuses variantes sur ce thème, mais toutes capturent un ensemble d’informations similaire.

Comme vous pouvez le voir ici – les récits d’utilisateurs, capturés une par carte, peuvent ensuite être facilement présentés aux équipes de développement et de design si nécessaire.

User stories et développement agile

Les user stories sont utilisés en agile pour définir toutes les fonctionnalités du produit final. Ils ne sont pas gravés dans le marbre et il est parfaitement admis que les exigences peuvent changer (et changeront souvent) tout au long du cycle de vie d’un projet.

Le Scrum Master (le chef d’équipe agile) priorise ensuite les récits à développer dans chaque sprint. Les développeurs ont souvent carte blanche pour discuter des récits d’utilisateur avec l’utilisateur final ou le client afin de bien comprendre ce qui est exigé d’eux.

L’agile exige également que chaque récit ait un test correspondant ou des cas de test correspondants pour l’UAT (User Acceptance Testing). De cette façon, le processus de développement garantit que le récit est implémenté de manière satisfaisante pour l’utilisateur. Il fournit également une base de négociation si un user story est correctement implémenté mais ne satisfait pas l’utilisateur final.

Avantages de l’utilisation des user stories dans le design et le développement

L’utilisation des user stories dans les cycles de design et de développement présente plusieurs avantages :

• Ils sont simples et rapides à comprendre.
• Ils permettent aux programmeurs d’implémenter rapidement (en utilisant Agile) la valeur client / utilisateur
• Ils n’ont pas besoin de beaucoup d’entretien
• Ils peuvent être réduits, sauf lorsqu’ils sont utilisés dans le développement
• Ils permettent à un projet d’être divisé en étapes plus petites
• Ils facilitent l’estimation des coûts d’un projet de développement
• Ils facilitent le travail coopératif avec les clients et les utilisateurs

Les inconvénients de l’utilisation des user stories dans le design et le développement

Il y a des inconvénients possibles à utiliser les user stories et en particulier à devenir trop dépendant d’eux au détriment d’autres outils :

• Ils sont difficiles à intégrer dans des projets à grande échelle (où des milliers de récits pourraient être nécessaires)
• Ils peuvent être trop vagues pour être utiles et nécessitent beaucoup de va-et-vient entre les développeurs et les clients
• Ils ne parviennent pas à capturer les mesures de performances et parfois les aspects non fonctionnels du système – par exemple, ils sont trop simples

La simplicité d’un user story peut être sa plus grande force et sa plus grande faiblesse. N’oubliez pas que vous devez capturer suffisamment d’informations pour répondre aux exigences intangibles ainsi qu’aux exigences tangibles.

Ce qu’il faut retenir

Les récits d’utilisateur peuvent être très utiles pour articuler les exigences de l’utilisateur ou du client pour un système en récits simples d’une ligne (ou très courtes) pour chaque exigence. Ils s’intègrent parfaitement dans la méthode de développement Agile et garantissent une compréhension claire de ce qui est nécessaire à chaque sprint. Cependant, il est important de se rappeler que les user stories ont également des limites et que leur utilisation doit être soigneusement envisagée pour s’assurer que toutes les exigences et mesures de performance sont comprises avant que le design ne se transforme en développement.

Ressources

The Connextra user story approach is found here – http://agilecoach.typepad.com/photos/connextra_user_story_2001/connextrastorycard.html

Some simple examples of user stories can be found here – https://www.mountaingoatsoftware.com/agile/user-stories

Agile Modelling offers its take on user stories here – http://www.agilemodeling.com/artifacts/userStory.htm

Some tips for writing better user stories can be found here – http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/