Le terme « feature » reste l’un des plus mal définis dans les spécifications agiles. Confondu avec l’epic, réduit à un titre de menu ou gonflé en mini-projet, il perd sa fonction première : découper un produit en tranches de valeur livrables et testables. Nous détaillons ici les modèles de phrases en anglais qui permettent de formuler des features exploitables dans les specs et les user stories, avec les pièges syntaxiques à éviter.
Feature statement en anglais : la phrase qui manque entre l’epic et la story
La plupart des guides agile sautent directement de l’epic à la user story. La feature, elle, occupe un niveau intermédiaire qui structure le backlog sans le transformer en cahier des charges.
Un feature statement décrit un comportement utilisateur observable et borné. Il ne décrit ni un écran, ni un composant technique, ni un objectif stratégique. Il décrit ce que le produit permet de faire, vu du métier.
Modèle de phrase recommandé
Le format le plus opérationnel que nous utilisons en specs anglophones suit cette structure :
Enable [user segment] to [action verb] + [object] so that [measurable outcome].
Exemple concret : Enable returning customers to pay with a saved card so that checkout completion rate increases.
Ce modèle se distingue du template classique de la user story (« As a… I want… so that… ») sur un point clé : il porte sur un slice de comportement vérifiable, pas sur un besoin individuel. La feature regroupe potentiellement plusieurs stories, mais reste assez précise pour qu’une équipe de développement puisse estimer son périmètre en sprint planning.
User story template en anglais : au-delà du triptyque rôle, besoin, bénéfice
Le format « As a [role], I want [goal], so that [benefit] » reste un standard. Nous observons toutefois que les équipes matures l’utilisent de moins en moins comme phrase canonique obligatoire, et de plus en plus comme point de départ conversationnel.
Deux approches de rédaction coexistent
- Title-first story : un titre comportemental court en anglais (« Returning customer pays with a saved card »), suivi de critères d’acceptation détaillés. Cette approche convient aux équipes qui pratiquent le refinement en continu et n’ont pas besoin du cadre syntaxique pour lancer la conversation.
- Canonical template : la phrase complète « As a… I want… so that… » reste utile pour les équipes qui démarrent en agile ou qui travaillent avec des parties prenantes peu familières du backlog. Elle force la réflexion sur le bénéfice utilisateur.
La tendance récente consiste à réserver la phrase type aux équipes qui en ont encore besoin pour cadrer la discussion, et à privilégier le titre comportemental pour les équipes rodées. Dans les deux cas, la story n’a de valeur que si elle est adossée à des preuves de complétion.
Acceptance criteria en anglais : le signal de complétion que les specs ignorent
Rédiger une feature ou une user story sans critères d’acceptation revient à livrer une spécification sans définition de « fini ». Les acceptance criteria transforment une intention en preuve de complétion mesurable.
Format Given/When/Then et ses limites
Le format Gherkin reste le plus courant :
Given [precondition], When [action], Then [expected result].
Exemple : Given a returning customer with a saved card, When they select « Pay now », Then the payment is processed without re-entering card details.
Ce format fonctionne bien pour les comportements transactionnels. Il devient lourd quand les critères portent sur des métriques ou des comportements asynchrones. Dans ce cas, un format libre mais structuré convient mieux :
- Signal mesurable : le taux de complétion du checkout augmente après déploiement
- Environnement de test : testé sur le parcours mobile avec un compte existant disposant d’une carte enregistrée
- Métrique suivie : temps moyen entre sélection du produit et confirmation de paiement
L’objectif est de lier chaque story à un outcome observable par le métier, pas à une validation purement technique. Cette distinction est rarement couverte dans les guides qui s’arrêtent au format Given/When/Then sans aborder la preuve de valeur.
Erreurs de formulation dans les specs en anglais : features et stories mélangées
Le piège le plus fréquent que nous rencontrons dans les backlogs anglophones est la confusion de granularité. Une feature rédigée comme une story produit des items trop larges pour un sprint. Une story rédigée comme une feature génère des dépendances cachées.
Symptômes d’une feature déguisée en story
Quand une user story contient des verbes comme « manage », « handle » ou « support » sans préciser l’action utilisateur concrète, elle décrit en réalité une feature. « As an admin, I want to manage users » n’est pas une story : c’est un périmètre fonctionnel entier qui recouvre la création, la modification, la suppression et la recherche d’utilisateurs.
La correction consiste à découper la feature en stories comportementales unitaires : « Admin creates a new user account », « Admin deactivates an existing user », « Admin searches users by email ». Chaque story porte sur un seul changement de comportement testable.
Symptômes d’une story gonflée en feature
À l’inverse, quand une story inclut un « so that » portant sur un objectif stratégique (« so that we increase retention »), elle a dépassé son niveau de granularité. Le bénéfice d’une story doit rester à portée de vérification directe par l’équipe de développement, pas par le comité de direction.
Un feature statement porte un outcome produit, une story porte un outcome utilisateur immédiat. Maintenir cette distinction dans la rédaction anglophone des specs évite que le backlog se transforme en document de stratégie produit déguisé en liste de tâches.
La qualité d’un backlog ne dépend pas du volume de stories rédigées, mais de la précision avec laquelle chaque niveau (feature, story, acceptance criteria) remplit son rôle. Un titre comportemental clair, des critères de complétion liés à un signal mesurable et une granularité cohérente entre les niveaux suffisent à produire des specs que l’équipe peut réellement livrer en sprint.
