Agile INVEST – 6 grandes lignes directrices pour les histoires d’utilisateur

Agile utilise les histoires d’utilisateur pour exprimer les problèmes que doit résoudre un produit ou un système. La ligne directrice Agile INVEST est un ensemble de recommandations compilées par Bill Wake afin d’aider à tester et à créer des histoires d’utilisateur de haute qualité (ou plus généralement, des éléments de la liste de produits) qui soutiennent une gestion agile efficacegestion de projet agile.

Selon la Agile INVESTligne directrice, les histoires d’utilisateur de haute qualité sont faciles à :

• Comprendre
• Mettre en œuvre
• Tester
• Démontrer au client
• Être indépendantes

Mais examinons ce que signifie réellement l’acronyme INVEST.

Agile INVEST – Indépendant

Cela signifie que l’histoire peut exister en tant qu’élément de la liste de produits (PBI) avec sa propre priorité, être estimée de manière indépendante, et ne dépendre d’aucune autre histoire.

La priorité attribuée à une histoire d’utilisateur doit être le seul facteur déterminant lors de sa mise en œuvre par l’équipe. Si sa priorité est plus faible, l’histoire est placée plus bas dans la liste de produits et est mise en œuvre plus tard ; si elle est plus élevée, l’équipe la déplace plus haut dans la liste pour une livraison plus rapide. Lorsque les histoires d’utilisateur sont interdépendantes, c’est la dépendance – et non la priorité – qui détermine quand l’équipe les met en œuvre.

Agile INVEST – Négociable

Une bonne histoire d’utilisateur capture l’essence du besoin du client. Si des questions surviennent, l’équipe en discute avec le client afin de déterminer la valeur correcte de l’histoire. L’équipe de développement peut négocier avec le propriétaire du produit et les parties prenantes. Ainsi, la collaboration entre l’équipe projet (fournisseur et client) permet de créer un produit ou un service exceptionnel.

Un équipe agile n’a-t-elle rien à demander parce que tout est documenté dans l’histoire d’utilisateur agile ? Alors, un analyste métier a rédigé les exigences.

Il y aura certains éléments non négociables (souvent non fonctionnels), tels que :

• Politiques de sécurité liées aux comptes utilisateurs
• Exigences de performance, telles que le nombre d’utilisateurs simultanés que le système doit gérer

C’est acceptable, à condition que les détails de la fonctionnalité elle-même restent ouverts et invitent à la discussion.

Agile INVEST – Valeureux

En se référant aux principes agiles, « valeur » signifie que nous pouvons démontrer la fonctionnalité ou le caractère demandé au client lors de la réunion de revue de sprint.

Lorsqu’on divise les histoires d’utilisateur, les équipes doivent le faire verticalement (ce qui représente également le « V ») plutôt que horizontalement. Cela permet de livrer une fonctionnalité complète à la fin du sprint et augmente l’incrément potentiellement livrable du produit.

Les équipes peuvent trouver plus intéressant de mettre en œuvre des PBIs techniques, mais ils ne livrent pas toujours une valeur directe au client – ce qui contredit l’un des principes agiles: satisfaire le client grâce à la livraison précoce et continue de logiciels à valeur ajoutée.

Agile INVEST – Estimable

Une bonne histoire utilisateur doit être estimable. En agile, l’estimation est relative — comparée aux autres histoires utilisateur dans le backlog. Les méthodes populaires incluent la suite de Fibonacci, Tailles T-shirt (S, M, L, etc.), et bien d’autres.

La discussion autour de l’estimation aide toute l’équipe à atteindre un consensus sur les conditions nécessaires pour terminer l’histoire. Parfois, une histoire n’est pas estimable, ce qui est normal si l’histoire est trop grande ou contient plusieurs fonctionnalités au sein d’un même élément. Dans de tels cas, divisez l’histoire en plusieurs histoires plus petites. Dans d’autres situations, il y a trop d’inconnues qui nécessitent une recherche.

Agile INVEST – Petit

Les histoires doivent prendre de quelques heures à un maximum d’une durée complète de Sprint. Sinon, différents problèmes surviennent — comme la vitesse (la manière dont l’équipe se tient responsable des points de livraison), la difficulté d’une estimation précise, et bien d’autres.

Agile INVEST – Testable

Dans ce contexte, « testable » fait référence aux critères d’acceptation définis lors de l’analyse.

Nous ne pouvons pas considérer une histoire utilisateur comme « terminée » à moins qu’elle ne satisfasse les critères d’acceptation. La seule façon de savoir qu’elle est satisfaite est par le biais de tests et de vérification.

Les critères d’acceptation ne sont pas des cas de test. Ils répondent à la question : « Comment sais-je que j’ai terminé cette histoire utilisateur ? »

Les cas de test décrivent les étapes nécessaires pour tester la fonctionnalité.

Le client peut vous indiquer à quoi ressemble l’environnement de test et les conditions de test selon lesquelles l’équipe considère qu’une histoire utilisateur est TERMINÉE.