...
Business experimentation : cf “Expérimentation d’affaires”.
...
C
Continuous Discovery : Continuous discovery refers to a sustained practice of product discovery to inform product development decisions continuously.
Culture d’expérimentation : désigne la propension d’un contexte à favoriser la mise en place d’expérimentation d’affaires (par exemple : dans une équipe souhaitant développer ou améliorer un produit innovant).
D
Daily Scrum (Mêlée Quotidienne/ Daily Meeting / Stand-Up Meeting) : événement Scrum Event est limité à 15 minutes organisé chaque jour pour les développeurs. Le Daily Scrum a lieu tous les jours du Sprint. Chez lui, les plans des développeurs fonctionnent pour les prochaines 24 heures. Cela optimise la collaboration et les performances de l'équipe en inspectant le travail depuis le dernier Daily Scrum et en prévoyant le travail de Sprint à venir. Le Daily Scrum se tient à la même heure et au même endroit chaque jour pour réduire la complexité.
Definition of Ready : une compréhension partagée par le Product Owner et les Développeurs concernant le niveau préféré de description des éléments du Product Backlog introduits lors de la planification du Sprint.
Definition of Done (FR : Définition de fini) : est une description formelle de l'état de l'incrément lorsqu'il répond aux mesures de qualité requises pour le produit. Au moment où un élément du backlog produit (PBI) répond à la définition de terminé, un incrément est né. La définition de terminé crée de la transparence en fournissant à chacun une compréhension partagée du travail effectué dans le cadre de l'incrément. Si un élément du backlog produit ne répond pas à la définition de terminé, il ne peut pas être publié ni même présenté lors de la revue de sprint.
Déploiement (Release) : Une version du produit qui est livrée à l’utilisateur final. À ne pas confondre avec une version intermédiaire livrée au promoteur à la fin de chaque Sprint. La relâche se déroule sur plusieurs Sprints.
Design Thinking (FR : Pensée Design) : présentation rapide de la méthode
Dette Technique (eng. : Technical Debt) : les frais généraux généralement imprévisibles liés à la maintenance du produit, souvent causés par des décisions de conception moins qu'idéales, contribuant au coût du produit. La dette technique peut exister involontairement dans l'incrément ou être introduite délibérément pour réaliser de la valeur plus tôt.
E
Early adopter (trad : primo-adoptant) : Personne comprenant le problème à résoudre et la valeur potentielle du produit à un stade précoce. Attention : les early adopters ne sont pas forcément la cible à moyen-long terme d’un produit, ce sont ceux qui vont permettre de se “lancer”.
Émergence : le processus d'apparition ou de proéminence de nouveaux faits ou d'une nouvelle connaissance d'un fait, ou la connaissance d'un fait devenant visible de manière inattendue.
Empirisme : type de contrôle de processus dans lequel seul le passé est accepté comme certain et dans lequel les décisions sont basées sur l'observation, l'expérience et l'expérimentation. L'empirisme repose sur trois piliers : la transparence, l'inspection et l'adaptation.
Épique/Epopée (eng. : Epic) : Une Epic est une User Story qui est trop volumineuse pour être complétée en un seul Sprint. Dans ces circonstances, on doit la subdiviser en multiples Stories. Par exemple, pour une application on pourrait avoir la situation suivante : Interface utilisateur (Epic) => Écran principal (Epic) => Animation arrière-plan (Story)
Équipe autogérée : groupe de personnes qui travaillent ensemble vers un objectif commun et qui sont redevables et responsables de tous ou de la plupart des aspects qui tournent autour des tâches qu’ils effectuent
Équipe autonome : groupe de personnes qui travaillent ensemble vers un objectif commun et qui sont capables de répartir leur travail en prenant soin d’identifier quelles sont les forces et les compétences de chaque membre. Ils mettent l’accent sur l’individualité de chacun (connaissances, compétences, tempérament) et la manière dont la personne sera capable de synergiser avec le reste de l’équipe.
Équipe de développement (Developpeurs) : tout membre d'une équipe Scrum, qui s'engage à créer n'importe quel aspect d'un incrément utilisable à chaque sprint, quelle que soit sa spécialité technique, fonctionnelle ou autre. Tous les autres membres de l’équipe Scrum sont considérés des développeurs, sans égard à leur métier ou leur niveau hiérarchique. Tous les développeurs, dans le cadre Scrum toujours, sont considérés égaux et ainsi personne n’a d’autorité sur les autres, les emmenant à collaborer. Cette dualité d’autorité et d’absence de poste spécifique peut créer des incompréhensions, un sujet que je réserve pour un autre article.
Estimation Agile : C'est le processus qui cherche à évaluer et estimer votre effort pour accomplir une tâche prioritaire dans le backlog du produit. D'habitude les estimations sont faites selon la complexité de la tâche, les ressources disponibles et les connaissances pour compléter et le temps pour l'accomplir. Les estimations ne doivent pas être Critères d'acceptation (Acceptance Criteria") : sont les conditions ou les exigences spécifiques qu'une user story ou un élément du backlog de produit doit satisfaire pour être considéré comme terminé et accepté par le Product Owner. Les critères d'acceptation définissent les attentes claires et mesurables qui doivent être remplies pour qu'une fonctionnalité soit considérée comme complète et prête à être livrée. Ils permettent de définir les conditions nécessaires pour que le travail soit considéré comme accompli et répondant aux besoins de l'utilisateur. Les critères d'acceptation aident l'équipe Scrum à comprendre les exigences spécifiques du Product Owner et à valider si une fonctionnalité est correctement mise en œuvre. Ils servent également de base pour les tests et les validations lors du développement itératif et incrémental.
Continuous Discovery : Continuous discovery refers to a sustained practice of product discovery to inform product development decisions continuously.
Culture d’expérimentation : désigne la propension d’un contexte à favoriser la mise en place d’expérimentation d’affaires (par exemple : dans une équipe souhaitant développer ou améliorer un produit innovant).
...
D
Daily Scrum (Mêlée Quotidienne/ Daily Meeting / Stand-Up Meeting) : événement Scrum Event est limité à 15 minutes organisé chaque jour pour les développeurs. Le Daily Scrum a lieu tous les jours du Sprint. Chez lui, les plans des développeurs fonctionnent pour les prochaines 24 heures. Cela optimise la collaboration et les performances de l'équipe en inspectant le travail depuis le dernier Daily Scrum et en prévoyant le travail de Sprint à venir. Le Daily Scrum se tient à la même heure et au même endroit chaque jour pour réduire la complexité.
Definition of Ready : une compréhension partagée par le Product Owner et les Développeurs concernant le niveau préféré de description des éléments du Product Backlog introduits lors de la planification du Sprint.
Definition of Done (FR : Définition de fini) : est une description formelle de l'état de l'incrément lorsqu'il répond aux mesures de qualité requises pour le produit. Au moment où un élément du backlog produit (PBI) répond à la définition de terminé, un incrément est né. La définition de terminé crée de la transparence en fournissant à chacun une compréhension partagée du travail effectué dans le cadre de l'incrément. Si un élément du backlog produit ne répond pas à la définition de terminé, il ne peut pas être publié ni même présenté lors de la revue de sprint.
Déploiement (Release) : Une version du produit qui est livrée à l’utilisateur final. À ne pas confondre avec une version intermédiaire livrée au promoteur à la fin de chaque Sprint. La relâche se déroule sur plusieurs Sprints.
Design Thinking (FR : Pensée Design) : présentation rapide de la méthode
Dette Technique (eng. : Technical Debt) : les frais généraux généralement imprévisibles liés à la maintenance du produit, souvent causés par des décisions de conception moins qu'idéales, contribuant au coût du produit. La dette technique peut exister involontairement dans l'incrément ou être introduite délibérément pour réaliser de la valeur plus tôt.
...
E
Early adopter (trad : primo-adoptant) : Personne comprenant le problème à résoudre et la valeur potentielle du produit à un stade précoce. Attention : les early adopters ne sont pas forcément la cible à moyen-long terme d’un produit, ce sont ceux qui vont permettre de se “lancer”.
Émergence : le processus d'apparition ou de proéminence de nouveaux faits ou d'une nouvelle connaissance d'un fait, ou la connaissance d'un fait devenant visible de manière inattendue.
Empirisme : type de contrôle de processus dans lequel seul le passé est accepté comme certain et dans lequel les décisions sont basées sur l'observation, l'expérience et l'expérimentation. L'empirisme repose sur trois piliers : la transparence, l'inspection et l'adaptation.
Épique/Epopée (eng. : Epic) : Une Epic est une User Story qui est trop volumineuse pour être complétée en un seul Sprint. Dans ces circonstances, on doit la subdiviser en multiples Stories. Par exemple, pour une application on pourrait avoir la situation suivante : Interface utilisateur (Epic) => Écran principal (Epic) => Animation arrière-plan (Story)
Équipe autogérée : groupe de personnes qui travaillent ensemble vers un objectif commun et qui sont redevables et responsables de tous ou de la plupart des aspects qui tournent autour des tâches qu’ils effectuent
Équipe autonome : groupe de personnes qui travaillent ensemble vers un objectif commun et qui sont capables de répartir leur travail en prenant soin d’identifier quelles sont les forces et les compétences de chaque membre. Ils mettent l’accent sur l’individualité de chacun (connaissances, compétences, tempérament) et la manière dont la personne sera capable de synergiser avec le reste de l’équipe.
Équipe de développement (Développeurs) : tout membre d'une équipe Scrum, qui s'engage à créer n'importe quel aspect d'un incrément utilisable à chaque sprint, quelle que soit sa spécialité technique, fonctionnelle ou autre. Tous les autres membres de l’équipe Scrum sont considérés des développeurs, sans égard à leur métier ou leur niveau hiérarchique. Tous les développeurs, dans le cadre Scrum toujours, sont considérés égaux et ainsi personne n’a d’autorité sur les autres, les emmenant à collaborer. Cette dualité d’autorité et d’absence de poste spécifique peut créer des incompréhensions, un sujet que je réserve pour un autre article.
Estimation Agile : C'est le processus qui cherche à évaluer et estimer votre effort pour accomplir une tâche prioritaire dans le backlog du produit. D'habitude les estimations sont faites selon la complexité de la tâche, les ressources disponibles et les connaissances pour compléter et le temps pour l'accomplir. Les estimations ne doivent pas être prises comme des "absolus", car elles peuvent varier selon la complexité du contexte ou la maturité de l'équipe qui estime.
...
Planning Poker : Technique d'estimation d’effort collective. Chaque élément du Product Backlog est estimé collectivement en se basant généralement sur l'unité appelée « Story Point ». Cette estimation va notamment aider le Product Owner à prioriser son Product Backlog
Product Backlog (carnet/backlog de produit) : un artefact Scrum qui consiste en une liste ordonnée du travail à effectuer pour créer, maintenir et maintenir un produit. Le Product Backlog est la liste de toutes les User Stories que notre produit idéal pourrait contenir, et ce en ordre de priorité. Ces Stories ne sont pas encore subdivisées en tâches et leur description est sommaire sauf pour les plus prioritaires qui feront partie du prochain Sprint (pour éviter d’investir des efforts où ce n’est pas nécessaire). Le Product Owner est en charge de prioriser et de gérer le Backlog au fil du temps et des changements qui surviennent.
Product Backlog Item (PBI) : voir User story (récit d’utilisateur/Story)
Product Backlog refinement (Raffinement du Product Backlog) : l'activité dans un Sprint par laquelle le Product Owner et les Développeurs ajoutent de la granularité au Product Backlog.
Product Discovery : Product discovery refers to research that aims to identify what a product team should build—the solution, features and improvements—based on the customer’s needs.
Product Goal (objectif produit) : décrit un état futur du produit qui peut servir de cible à l'équipe Scrum pour planifier. L'objectif de produit se trouve dans le backlog de produit. Le reste du Product Backlog émerge pour définir "ce qui" remplira l'objectif du produit.
Product Owner (Propriétaire/Responsable du produit ou PO) : rôle dans Scrum responsable de la maximisation de la valeur d'un produit, principalement en gérant et en exprimant progressivement les attentes commerciales et fonctionnelles d'un produit aux développeurs. Le Product Owner est le représentant du promoteur au sein de l’équipe. Il se doit d’avoir une excellente connaissance du produit à réaliser et de la vision du promoteur. Par contre, contrairement à ce dernier, il est présent au quotidien et se charge de la priorisation des fonctionnalités, du respect du budget et de l’échéance. Il se peut que ce rôle soit assumé par le promoteur directement advenant qu’il comprenne bien la différence entre les deux fonctions (particulièrement le compromis entre fonctionnalités, temps/budget et qualité)
Production en cascade (Waterfall) : Waterfall est la méthode «classique» de gestion de projets où l’on planifie toutes les étapes et les tâches à accomplir en amont et en élaborant des plans de gestion des risques afin de contrer les imprévus qui pourraient survenir. Cette façon de faire comporte ses lacunes auxquelles Scrum tente de pallier par une plus grande réactivité au changement. À noter que la méthode Waterfall a aussi ses avantages et peut être adéquate dans de multiples circonstances
Promoteur (Stakeholder) : Le promoteur est le commanditaire du projet, celui qui le finance et qui en a la vision. Ultimement, il s’agit de celui qui tirera bénéfice du projet que vous réalisez. Tout projet a un promoteur, celui-ci n’est pas considéré faire partie de l’équipe même s’il est encouragé à participer.
“Puriste” (ou “religieux”) : Désigne une attitude qui insiste sur la définition théorique des concepts d’une méthode au lieux de leur implication pratique et donc de leur potentiel d’adaptation dans le contexte d’une équipe.
S
Scrum : est un cadre léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes tels que définis dans le Scrum GuideTM.
Scrum Board : un tableau physique pour visualiser les informations pour et par l'équipe Scrum, souvent utilisé pour gérer le Sprint Backlog. Les tableaux Scrum sont une implémentation facultative dans Scrum pour rendre les informations visibles.
Scrum Master : rôle au sein d'une équipe Scrum responsable de guider, d'encadrer, d'enseigner et d'aider une équipe Scrum et ses environnements dans une bonne compréhension et utilisation de Scrum. Il s’agit d’un rôle très important pour le succès des projets Scrum, surtout lorsque l’équipe a peu d’expérience. Son mandat consiste en l’application, selon les règles de l’art, des pratiques Scrum. De plus il s’assure, de par la nature de son mandat, de protéger l’équipe des éléments extérieurs en s’imposant comme un tampon opérationnel entre le Product Owner (PO) et les développeurs. Ses tâches consistent en l’assistance au POpour prioriser les fonctionnalités, la modération et le bon déroulement des cérémonies, l’accompagnement des développeurs vers une plus grande autonomie et la levée de toute entrave au travail de l’équipe. Il n’a pas d’autorité hiérarchique, mais il a la responsabilité d’un meneur-serviteur (servant-leader)Scrum Team (équipe Scrum) : une équipe autogérée composée d'un Scrum Master, d'un Product Owner et de Développeurs.
Sprint : événement Scrum limité à un mois ou moins, qui sert de conteneur pour les autres événements et activités Scrum. Un Sprint contient un ensemble de cérémonies et culmine en la livraison d’un produit intermédiaire fonctionnel démontrant ce qui a été développé durant l’itération. Les sprints se font consécutivement, sans intervalles intermédiaires.
Sprint Backlog : Le Sprint Backlog consiste en la liste des User Stories qui composent le Sprint, tel que déterminé durant la planification du Sprint, en plus d’un «plan» pour comment atteindre l’objectif du Sprint. Ce plan est, à toute fin pratique, les tâches qui composent les Stories. Le Sprint Backlog est la «propriété» des développeurs et ils sont les seuls à pouvoir le modifier. Ceci évite l’ingérence de la part du Product Owner afin d’assurer une stabilité minimale. Ce dernier peut par contre négocier les changements et vice-versa. Le Sprint Backlog évolue en cours de Sprint pour représenter l’avancement du travail.
Sprint Goal (objectif du Sprint): une brève expression de l'objectif d'un Sprint, souvent un problème métier qui est traité et le plant pour le resoudre. Ce dernier peut être ajustée pendant le Sprint afin d'atteindre l'objectif du Sprint.
Sprint Planning (planification du Sprint) : événement Scrum limité à 8 heures ou moins pour démarrer prioritaires qui feront partie du prochain Sprint (pour éviter d’investir des efforts où ce n’est pas nécessaire). Le Product Owner est en charge de prioriser et de gérer le Backlog au fil du temps et des changements qui surviennent.
Product Backlog Item (PBI) : voir User story (récit d’utilisateur/Story)
Product Backlog refinement (Raffinement du Product Backlog) : l'activité dans un Sprint par laquelle le Product Owner et les Développeurs ajoutent de la granularité au Product Backlog.
Product Discovery : Product discovery refers to research that aims to identify what a product team should build—the solution, features and improvements—based on the customer’s needs.
Product Goal (objectif produit) : décrit un état futur du produit qui peut servir de cible à l'équipe Scrum pour planifier. L'objectif de produit se trouve dans le backlog de produit. Le reste du Product Backlog émerge pour définir "ce qui" remplira l'objectif du produit.
Product Owner (Propriétaire/Responsable du produit ou PO) : rôle dans Scrum responsable de la maximisation de la valeur d'un produit, principalement en gérant et en exprimant progressivement les attentes commerciales et fonctionnelles d'un produit aux développeurs. Le Product Owner est le représentant du promoteur au sein de l’équipe. Il se doit d’avoir une excellente connaissance du produit à réaliser et de la vision du promoteur. Par contre, contrairement à ce dernier, il est présent au quotidien et se charge de la priorisation des fonctionnalités, du respect du budget et de l’échéance. Il se peut que ce rôle soit assumé par le promoteur directement advenant qu’il comprenne bien la différence entre les deux fonctions (particulièrement le compromis entre fonctionnalités, temps/budget et qualité)
Production en cascade (Waterfall) : Waterfall est la méthode «classique» de gestion de projets où l’on planifie toutes les étapes et les tâches à accomplir en amont et en élaborant des plans de gestion des risques afin de contrer les imprévus qui pourraient survenir. Cette façon de faire comporte ses lacunes auxquelles Scrum tente de pallier par une plus grande réactivité au changement. À noter que la méthode Waterfall a aussi ses avantages et peut être adéquate dans de multiples circonstances
Promoteur (Stakeholder) : Le promoteur est le commanditaire du projet, celui qui le finance et qui en a la vision. Ultimement, il s’agit de celui qui tirera bénéfice du projet que vous réalisez. Tout projet a un promoteur, celui-ci n’est pas considéré faire partie de l’équipe même s’il est encouragé à participer.
“Puriste” (ou “religieux”) : Désigne une attitude qui insiste sur la définition théorique des concepts d’une méthode au lieux de leur implication pratique et donc de leur potentiel d’adaptation dans le contexte d’une équipe.
...
S
Scrum : est un cadre léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes tels que définis dans le Scrum GuideTM.
Scrum Board : un tableau physique pour visualiser les informations pour et par l'équipe Scrum, souvent utilisé pour gérer le Sprint Backlog. Les tableaux Scrum sont une implémentation facultative dans Scrum pour rendre les informations visibles.
Scrum Master : rôle au sein d'une équipe Scrum responsable de guider, d'encadrer, d'enseigner et d'aider une équipe Scrum et ses environnements dans une bonne compréhension et utilisation de Scrum. Il s’agit d’un rôle très important pour le succès des projets Scrum, surtout lorsque l’équipe a peu d’expérience. Son mandat consiste en l’application, selon les règles de l’art, des pratiques Scrum. De plus il s’assure, de par la nature de son mandat, de protéger l’équipe des éléments extérieurs en s’imposant comme un tampon opérationnel entre le Product Owner (PO) et les développeurs. Ses tâches consistent en l’assistance au POpour prioriser les fonctionnalités, la modération et le bon déroulement des cérémonies, l’accompagnement des développeurs vers une plus grande autonomie et la levée de toute entrave au travail de l’équipe. Il n’a pas d’autorité hiérarchique, mais il a la responsabilité d’un meneur-serviteur (servant-leader)
Scrum Team (équipe Scrum) : une équipe autogérée composée d'un Scrum Master, d'un Product Owner et de Développeurs.
Sprint : événement Scrum limité à un mois ou moins, qui sert de conteneur pour les autres événements et activités Scrum. Un Sprint contient un ensemble de cérémonies et culmine en la livraison d’un produit intermédiaire fonctionnel démontrant ce qui a été développé durant l’itération. Les sprints se font consécutivement, sans intervalles intermédiaires.
Sprint Backlog : Le Sprint Backlog consiste en la liste des User Stories qui composent le Sprint, tel que déterminé durant la planification du Sprint, en plus d’un «plan» pour comment atteindre l’objectif du Sprint. Ce plan est, à toute fin pratique, les tâches qui composent les Stories. Le Sprint Backlog est la «propriété» des développeurs et ils sont les seuls à pouvoir le modifier. Ceci évite l’ingérence de la part du Product Owner afin d’assurer une stabilité minimale. Ce dernier peut par contre négocier les changements et vice-versa. Le Sprint Backlog évolue en cours de Sprint pour représenter l’avancement du travail.
Sprint Goal (objectif du Sprint): une brève expression de l'objectif d'un Sprint, souvent un problème métier qui est traité et le plant pour le resoudre. Ce dernier peut être ajustée pendant le Sprint afin d'atteindre l'objectif du Sprint.
Sprint Planning (planification du Sprint) : événement Scrum limité à 8 heures ou moins pour démarrer un Sprint. Il permet à l'équipe Scrum d'inspecter le travail du backlog de produit qui a le plus de valeur à faire ensuite et de concevoir ce travail dans le backlog de Sprint.
Sprint Retrospective : événement Scrum défini sur une plage horaire de 3 heures ou moins pour terminer un Sprint. Il permet à l'équipe Scrum d'inspecter la maturité de l’équpe et les processus mises en place lors du Sprint passé et de planifier les améliorations à mettre en œuvre lors des Sprints futurs.
Sprint Review (revue de sprint) : événement Scrum défini sur une durée limitée à 4 heures ou moins pour conclure le travail d'un Sprint. Il permet à l'équipe Scrum et aux parties prenantes d'inspecter le travail du backlog de produit qui a le plus de valeur à faire ensuite et de concevoir ce travail dans le backlog de Sprint.
Sprint Retrospective : événement Scrum défini sur une plage horaire de 3 heures ou moins pour terminer un Sprint. Il permet à l'équipe Scrum d'inspecter la maturité de l’équpe et les processus mises en place lors du Sprint passé et de planifier les améliorations à mettre en œuvre lors des Sprints futurs.
Sprint Review (revue de sprint) : événement Scrum défini sur une durée limitée à 4 heures ou moins pour conclure le travail d'un Sprint. Il permet à l'équipe Scrum et aux parties prenantes d'inspecter l'incrément de produit résultant du sprint, d'évaluer l'impact du travail effectué sur la progression globale vers l'objectif du produit et de mettre à jour le backlog du produit afin de maximiser la valeur de la prochaine période.
Story point : unité d’estimation couramment utilisée sur les projets agiles. Permettant de faciliter l’estimation en soi ainsi que la planification des Releases ou des Sprints. Tout en évitant de tomber dans l’illusion de la précision des estimations ou l’amalgame entre les jours/hommes et le délai de réalisationl'incrément de produit résultant du sprint, d'évaluer l'impact du travail effectué sur la progression globale vers l'objectif du produit et de mettre à jour le backlog du produit afin de maximiser la valeur de la prochaine période.
Story point : unité d’estimation couramment utilisée sur les projets agiles. Permettant de faciliter l’estimation en soi ainsi que la planification des Releases ou des Sprints. Tout en évitant de tomber dans l’illusion de la précision des estimations ou l’amalgame entre les jours/hommes et le délai de réalisation.
Subject Matter Expert (SME) : est un expert dans un domaine spécifique. Il s'agit d'une personne qui possède une connaissance approfondie, une expertise et une expérience pratique dans un domaine particulier. Les SME sont souvent sollicités pour fournir des informations, des conseils et des orientations sur des sujets spécifiques, en raison de leur expertise et de leur compréhension approfondie du domaine concerné. Ils peuvent être des professionnels chevronnés, des consultants ou des membres d'une équipe possédant une expertise spécialisée. Les SME jouent un rôle crucial dans le partage de connaissances, la résolution de problèmes et l'aide à la prise de décisions éclairées dans leur domaine d'expertise.
...
U
User story (récit d’utilisateur/Story) : est une description d’une d'une fonctionnalité telle que désirée souhaitée par le promoteur client et définie par le Product Owner. On essaie L'objectif est de décrire la fonctionnalité du point de vue de l’utilisateur l'utilisateur final. Par exemple «En tant que promoteur je désire un espace pour ranger mes dossiers dans mon bureau» ou «En tant qu’usager je désire une interface pour sélectionner une couleur». On y inclut souvent aussi une description un peu plus complète et des conditions de succès qui doivent être résolues pour que la Story soit complétée. Une Story doit absolument pouvoir être complétée dans une seule itération, sinon il s’agit d’une Epic.
User story points (points d’effort) : sont des unités de mesure permettant d'exprimer une estimation de l'effort global requis pour implémenter entièrement un élément du backlog produit ou tout autre élément de travail. Les équipes attribuent des points d'histoire en fonction de la complexité du travail, de la quantité de travail et du risque ou de l'incertitude.
...