En tant que partie centrale de nombreuses méthodologies de développement Agile, comme dans le jeu de planification de XP, les histoires d`utilisateurs définissent ce qui doit être construit dans le projet de logiciel. Les témoignages d`utilisateurs sont priorisés par le client (ou le propriétaire du produit dans Scrum) pour indiquer les plus importants pour le système et seront répartis en tâches et estimés par les développeurs. Une façon d`estimer est par l`intermédiaire d`une échelle de Fibonacci. Les récits d`utilisateurs sont souvent enregistrés sur les fiches d`index, sur les notes Post-it ou dans les logiciels de gestion de projet. Selon le projet, les récits d`utilisateurs peuvent être écrits par diverses parties prenantes telles que les clients, les utilisateurs, les gestionnaires ou les membres de l`équipe de développement. Les histoires d`utilisateurs sont souvent écrites sur des cartes d`index ou des notes collantes, stockées dans une boîte à chaussures, et disposées sur des murs ou des tables pour faciliter la planification et la discussion. En tant que tels, ils déplacent fortement l`accent de l`écriture sur les caractéristiques de les discuter. En fait, ces discussions sont plus importantes que n`importe quel texte est écrit. Il est souvent préférable de penser à la partie écrite comme un pointeur vers l`exigence réelle. Les récits d`utilisateurs peuvent pointer vers un diagramme représentant un workflow, une feuille de calcul montrant comment effectuer une évaluation ou tout autre artefact que le propriétaire du produit ou l`équipe désire. Les récits utilisateur capturent uniquement les éléments essentiels d`une exigence: tout d`abord, le processeur analyse l`ensemble de l`histoire de l`utilisateur. Le composant miner utilise spaCy pour analyser chaque récit utilisateur en jetons, qui détiennent le terme lui-même, sa balise de partie-de-parole, et les relations avec d`autres jetons.
Ces jetons sont stockés dans le composant UserStory et utilisés pour déduire des entités et des relations, et pour déterminer les pondérations de jeton. Les récits d`utilisateurs incluent rarement des détails sur les performances ou les exigences non fonctionnelles, de sorte que les tests non fonctionnels (p. ex. temps de réponse) peuvent être négligés. Les histoires d`utilisateurs sont des tâches de développement souvent exprimées en tant que «Persona + Need + but». Les parties prenantes écrivent des histoires d`utilisateurs. Un concept important est que vos parties prenantes de projet écrivent les histoires d`utilisateur, pas les développeurs. Les récits des utilisateurs sont assez simples pour que les gens puissent apprendre à les écrire en quelques minutes, il est donc logique que les experts du domaine (les parties prenantes) les écrivent.
Les récits d`utilisateurs décrivent le pourquoi et le quoi derrière le travail quotidien des membres de l`équipe de développement, souvent exprimés en tant que Persona + Need + but.