Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Méthode Scrum partie 3 : tests pour User Stories et priorisation du Product Backlog

Par Christian DESTREMAU Publié le 25/10/2017 à 00:15:31 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Ecrire des tests pour les User Stories

Faut-il tester ?

Il est très important de tester et de valider tout développement réalisé dans le cadre de la méthode Scrum, afin de garantir une qualité optimum du produit et de rendre les utilisateurs plus confiants.

D’autre part, n’oublions pas que l’exécution des tests et leur validation peuvent être un moyen pour le Product Owner de valider ou non le contenu d’un Sprint.

La pyramide de tests de Mike Cohn

Dans son livre « Succeeding with Agile », Mike Cohn a introduit un concept nommé « Pyramide de tests » qui a pour but de répartir en 3 catégories distinctes les tests pouvant être appliqués à une application.

Au plus bas niveau de la pyramide se trouvent les tests unitaires, suivi des tests métiers, et enfin nous avons les tests d’interface graphique en haut de la pyramide.

Les tests unitaires sont à la base de la pyramide : ceci signifie qu’ils jouent un rôle majeur. Et donc, plus ces tests seront nombreux plus la pyramide aura une base solide. L’application sera alors de meilleure qualité car elle sera stable. Ces tests sont réalisés sous forme de code et donc sont facilement automatisables. D’autre part, le coût de mise en place et d’exécution de ces tests est relativement peu élevé.

Ensuite, nous avons les tests fonctionnels qui constituent la partie centrale de la pyramide. Ces tests permettent de vérifier que l’application répond aux besoins et aux exigences fonctionnelles via la question : « Sommes-nous en adéquation avec le besoin ? ». Ils sont difficilement automatisables. Il est nécessaire de mettre en place un référentiel de test afin que chaque test puisse être rejoué à chaque nouvelle itération. Le coût de ces tests est élevé mais ils deviennent de plus en plus importants car ils permettent de s’assurer que le produit est bien conforme aux besoins du client.

Enfin, nous trouvons au sommet de la pyramide les tests d’IHM (interface homme-machine). Il s’agit de vérifier que l’interface graphique correspond aux besoins, qu’elle ne présente pas de bugs et qu’elle est performante. Ces tests restent difficiles à automatiser de nos jours. Leur coût est donc élevé et c’est pourquoi leur place dans la pyramide des tests est minim.

Tests unitaires

Ces tests ont pour objectif de valider une partie du code en confrontant son exécution avec le résultat attendu.

Par exemple, si nous prenons le cas d’une fonction de conversion monétaire, nous allons écrire des tests pour traiter différents cas de figure :

  • Saisie de valeurs non numériques

  • Vérifier que le taux de conversion utilisé est le bon

  • Vérifier que la conversion est effective.

L’usage de tests unitaires va permettre d’assurer une stabilité applicative d’un Sprint à l’autre et d’éviter toute régression. Pour cela, il suffira de rejouer les tests à l’aide d’un outil d’automatisation.

Comme dans n’importe quelle méthode agile, nous préconisons le développement à partir des tests (Test Driven Development). Il consiste à écrire les tests au préalable, puis à écrire ensuite le code qui va devoir les satisfaire.

Tests fonctionnels

Il n’est pas facile pour un développeur de tester l’aspect fonctionnel d’une application. Pour procéder à ce type de tests, nous faisons généralement appel à la mise en place d’un cahier de recette fonctionnelle rédigé par un homologateur logiciel formé à cette tâche. Cette même personne doit dérouler l’ensemble des tests pour s’assurer que l’application correspond aux besoins.

Pour un projet géré de façon agile, ce type de fonctionnement n’est pas adapté car il est lourd et rigide. Nous ferons plutôt appel aux tests d’acceptation qui, appliqués aux User Story, permettent de tester fonctionnellement l’application.

Tests d’IHM (interface homme-machine)

Ces tests permettent de vérifier que l’application est conforme à l’ergonomie souhaitée par le client. C’est un mal nécessaire pour que le client soit entièrement satisfait de la qualité du logiciel fourni.

Souvent mis à l’écart, ces tests sont en réalité fort utiles car les aspects visuels et ergonomiques sont le point d’entrée de l’utilisateur et celui-ci peut rejeter votre travail même si l’aspect fonctionnel est au rendez-vous.

Il faut évaluer en plus l’aspect visuel de l’interface, l’aspect performance. Des outils logiciels existent pour vous faciliter la tâche comme par exemple Selenium (http://seleniumhq.org/).

Définition des tests d’acceptation

Il est assez fastidieux de tester fonctionnellement une application, mais l’usage des tests d’acceptation va nous simplifier la tâche.

Le Product Backlog, vu dans la partie précédente, est constitué de User Stories. Chaque User Story doit suivre le principe INVEST et donc être testable (T comme testable). Les tests d’acceptation vont nous aider par rapport à ce critère.

Un test d’acceptation n’est pas un test technique. Il doit avoir les caractéristiques suivantes :

  • Etre visible de l’utilisateur

  • Ne pas proposer de solution

  • Ne pas être interne à la fonction testée

Critères d’acceptation

Pour créer un test d’acceptation on doit définir des critères d’acceptation respectant le formalisme suivant :

Précondition (état du système avant l’exécution de la User Story)

Quand (acteur et comportement)

Alors (résultat

Si nous avons la User Story suivante : « en tant qu’utilisateur, je peux me connecter au Système d’Information. »

On peut en déduire les critères d’acceptation suivants :

« L’utilisateur est déconnecté. Quand il saisit ses identifiants, il a alors accès au Système d’Information. »

« L’utilisateur est déconnecté. Quand il réalise une erreur lors de la saisie de ses identifiants, l’accès au Système d’Information lui est alors refusé. »

Données de tests et scénarios

Dans l’exemple ci-dessus, nos critères d’acceptation décrivent des scénarios de test mais d’une façon trop générale car on ne connait pas les données à utiliser.

Pour avoir un test d’acceptation en bonne et due forme, nous devons compléter nos critères d’acceptation par des données de test et de scénarios.

Par exemple, nous définissons le test d’acceptation suivant :

« L’utilisateur est déconnecté. Quand il saisit l’identifiant AAA et le mot de passe BBB, il a accès au Système d’Information. »

Tests d’acceptation et User Stories

Une bonne pratique des tests d’acceptation est d’affecter à chaque User Story au minimum 2 tests : un test correspondant au cas idéal et un correspondant au cas d’erreur.

TDD et ATDD

Le pilotage par les tests TDD (Test Driven Development) et les tests d’acceptation ATDD (Acceptance test Driven Development) sont parfaitement applicables aux méthodes agiles.

Test Driven Development

Cette technique de développement est basée avant tout sur les tests. Chaque développeur doit écrire des tests propres à une fonctionnalité avant de la développer.

Le cycle suivi par le TDD est le suivant :

  • Ecrire un premier test

  • S’assurer que ce test échoue tant que le code n’est pas développé

  • Ecrire le code qui va permettre de faire passer le test

  • Vérifier que le test est réussi

  • Améliorer le code par du re-factoring en veillant que la fonctionnalité reste opérationnelle

Les tests TDD sont des tests unitaires. Ils sont donc écrits sous forme de code, ce qui permet de les automatiser.

L’usage de TDD permet au développeur d’améliorer sa productivité. En effet, il n’a à se préoccuper que de l’écriture du code permettant de passer le test et évitera le codage de fonctions inutiles qui alourdiraient l’ensemble de l’application.

Cette technique de développement est à privilégier car elle permet à l’équipe de livrer un incrément de qualité, en respectant le principe suivant du manifeste agile : « Concevoir simple ».

Acceptance Test Driven Development

Cette technique de développement consiste à élaborer des tests fonctionnels avec du code.

En pratique, on va écrire des fonctions (ou méthodes en programmation orienté objet) qui vont suivre le formalisme des tests d’acceptation.

Ces tests ne sont donc pas des actions à réaliser en fin de développement, mais doivent être considérés comme des tâches de développement à part entière.

Les tests en pratique

Les tests sont importants et s’intègre à la méthode Scrum car ils permettent d’améliorer la qualité de l’application livrée. Voyons comment les tests unitaires et d’acceptation sont mis en place dans un projet Scrum.

Le travail du Product Owner

Nous pourrions envisager de demander au Product Owner d’écrire des tests d’acceptation car ce sont des tests fonctionnels.

En pratique, lui demander, en plus de son travail d’écriture des User Stories, d’écrire des tests d’acceptation pour chacune d’elles serait une trop lourde charge.

Nous préférerons que le Product Owner et l’équipe de développement se réunissent pour écrire ces tests ensemble. Cela permettra à l’équipe de s’approprier les tests, et d’améliorer par là-même les développements.

Trouver du temps pour l’écriture

Le principe est le suivant dans la méthode Scrum : chaque User Story incluse dans une itération de développement doit faire l’objet d’au moins un test d’acceptation. A partir de là, l’écriture des tests d’acceptation doit se faire avant chaque démarrage d’un Sprint.

Ce travail n’est pas à faire au moment de la planification de Sprint, car celle-ci est un cérémonial dont le temps est compté. Il faudra donc que l’équipe prévoit un moment pour écrire ces tests mais n’oubliera pas de l’inclure dans la planification.

Faut-il écrire les tests de toutes les User Stories

La réponse est non. Nous n’écrirons que les tests des User Stories éligibles au Sprint suivant.

Comment écrire les tests ?

Si les User Stories sont écrites sur des post-it, alors vous pouvez éventuellement écrire les tests d’acceptation au dos des post-it. Cela n’est pas forcément idéal, car l’espace peut parfois être trop petit.

Il est possible d’utiliser des outils de tests d’acceptation comme Robot Framework ou alors simplement des fichiers Excel.

Priorisation du Product Backlog

Pourquoi prioriser ?

Le but de ce chapitre est la priorisation des éléments constitutifs du Product Backlog, que sont les thèmes, les Epics et les User Stories.

L’intérêt d’une telle priorisation est d’organiser les User Stories pour déterminer celles qui apportent le plus de valeur métier et qui seront réalisées en premier et celles pouvant être développées dans des itérations futures.

La priorisation est une tâche qui revient au Product Owner, aidé par les utilisateurs (qui sont aussi appelés les Stakeholders). Elle doit être réalisée avec méthode, sans quoi, cela risque facilement de tourner au cauchemar.

Que signifie prioriser ?

Prioriser une User Story consiste à définir son degré de priorité par rapport aux autres. Ce degré de priorité représente la valeur métier (Business Value) affectée à la User Story. Ce sont les User Story avec la plus grande valeur métier qui seront développées dans le prochain Sprint.

Il n’est pas facile de définir ce degré de priorité. Pour y arriver, chaque User Story doit être positionné selon 4 critères :

  • La mesure des risques : si la User Story est développée maintenant, on évitera de lourds impacts par la suite.

  • L’amélioration de la qualité : si la User Story augmente la qualité du livrable, il faut la développer rapidement.

  • La dépendance : même si les dépendances sont déconseillées entre les User Stories, c’est parfois inévitable. Une fonctionnalité qui est un prérequis pour d’autres fonctionnalités est prioritaire.

  • Donner confiance aux utilisateurs : il arrive que les utilisateurs aient un désir sans parvenir à l’exprimer. Une User Story définissant ce besoin de façon minimaliste sera prioritaire, afin que les utilisateurs puissent faire facilement leur retour.

En pratique, il n’y pas de recette magique pour prioriser le Product Backlog. C’est en général le résultat de relations humaines et de discussions et propre à chaque projet.

Les utilisateurs ne sont pas en mesure de définir les priorités des User Stories mais par contre le Product Owner a toute autorité pour le faire.

Définir la valeur métier (business value)

En général, on affecte à chaque User Story une valeur métier sous forme de chiffre.

Comment procéder ?

Le principe est le suivant : le Product Owner sélectionne un User Story et définit sa valeur métier par un chiffre en 0 et 100.

Ce chiffre permet de positionner les User Stories entre elles. Une User Story avec un chiffre de 100 est une User Story à forte valeur ajoutée et sera traitée rapidement.

En pratique, la valeur métier est définie par le Product Owner et les Stakeholders. Pour cela, on fait appel à une technique utilisant un jeu de cartes, nommée Planning Poker que nous appellerons ici Priority Poker.

Priority Poker

Le Priority Poker est un jeu de 10 cartes et dont la valeur est donnée par la suite de Fibonacci.

Les valeurs sont : 0 -1-2-3-5-8-13-20-40-100- ?

Le déroulement du Priority poker est le suivant :

  1. Le Product Owner lit la User Story.

  2. Chaque utilisateur possède un jeu de cartes et estime la valeur métier en choisissant la carte qui lui semble appropriée. S’il est indécis, il peut choisir la carte « ? ».

  3. Au signal du Product Owner, chaque utilisateur montre la carte choisie à tout le monde.

  4. S’il existe des différences dans les valeurs choisies, il y a matière à discussion entre les utilisateurs. On recommence les étapes précédentes jusqu’à qu’une valeur commune soit trouvée.

  5. Une fois la valeur métier déterminée, elle est alors inscrite sur la User Story concernée. On peut la classer ensuite dans un tableau contenant les valeurs du Priority poker en colonne.

Lorsque toutes les User Stories ont été passées en revue, on a leur classement par valeur métier. Celles qui ont une valeur plus importante seront traitées en premier dans les prochains Sprints.

Avantages et inconvénients

Tous les Stakeholders pouvant participer à l’estimation de la valeur métier, ils vont ainsi renforcer leur sentiment d’implication dans le projet. C’est la le plus gros atout de cette méthode. D’autre part, le côté ludique est aussi un atout pour cette méthode.

Comme les User Stories sont classées par valeur, il se peut que dans le classement de celles-ci des ex-aequo apparaissent (2 User stories à 4 points, quatre à 8 points…). Le Product Owner doit alors procéder à une nouvelle priorisation pour différencier ces dernières.

Cette méthode n’est pas recommandée pour prioriser l’ensemble du Product Backlog. Il vaut mieux l’utiliser lorsque celui-ci est déjà organisé avec une autre méthode comme par exemple le modèle de Kano.

Priorisation par l’utilisation du modèle de Kano

La théorie du modèle

Le modèle de Kano appliqué à Scrum va répartir les User Stories en 3 catégories :

  • User Stories basiques.

  • User Stories de performances.

  • User Stories d’enthousiasme.

User Stories basiques

Une User Story est considérée comme basique lorsqu’elle exprime un besoin fondamental dont l’application ne peut pas se passer.

Au niveau de la priorisation, ces User Stories vont avoir un caractère prioritaire puisque l’application ne fonctionnera pas sans elles.

User Stories linéaires

Les User Stories linéaires (ou de performances) sont celles exprimant un besoin de qualité qui va séduire l’utilisateur. Voici des exemples en considérant des produits physiques :

  • Une voiture est utile mais un break est plus utile pour une famille nombreuse.

  • Une télévision permet de regarder des films mais la qualité d’image est meilleure sur un écran plat.

En termes de priorité, ces User Stories sont à classer en seconde position car elles sont liées à des valeurs métier non négligeable.

User Stories d’enthousiasme

Une User Story de ce type est souvent liée à l’interjection « ça, c’est super ! » lors de sa présentation. Elles correspondent à un besoin qui n’est pas obligatoire mais qui serait un réel avantage :

« Si je pouvais visualiser la photo de mon client avant de l’appeler, je serai alors capable de mettre un visage sur un nom. »

Ces User Stories ne sont pas prioritaires, mais en inclure quelques-unes dans les Sprint à venir donnera un regain d’intérêt au produit.

Représentation graphique du modèle

Le modèle de Kano possède aussi une représentation graphique qui s’applique aux User Stories :

Pour les User Stories basiques, si la fonctionnalité n’est pas développée cela engendrera beaucoup d’insatisfaction. Mais cela n’engendrera pas beaucoup de satisfaction lorsque la fonctionnalité est présente : en effet, la User Story exprime un besoin fondamental et donc sa présence est seulement normale.

En ce qui concerne les User Stories linéaires, la lecture est facile. si la fonctionnalité est présente, elle génère de la satisfaction, si elle n’est pas présente elle génère de l’insatisfaction.

Enfin, si les User Stories d’enthousiasme ne sont pas présentes cela n’engendre pas pour autant de l’insatisfaction car elles expriment un besoin qui n’est pas nécessaire au produit final. Mais si elles sont mises en place, alors la satisfaction sera plus grande.

Les User Stories à prendre en compte

La méthode de Kano ne permet pas d’affecter une valeur métier à chaque User Story (c’est-à-dire un chiffre). Par contre, elle nous permet de réaliser un tri pour savoir ce qui doit être pris en compte dans les prochaines itérations.

Nous avons la règle suivante :

  • Prendre ne compte toutes les User Stories basiques.

  • Prendre en compte une partie des User Stories linéaires.

  • Prendre en compte quelques-unes des User Stories d’enthousiasme.

La pratique

Une fois que le Product Owner a écrit un nombre satisfaisant de User Stories, il met alors en place des ateliers de priorisation.

Ces ateliers comportent les étapes suivantes :

  • Présentation des User Stories.

  • Catégorisation selon le modèle de Kano.

Demander au Stakeholder de se positionner

Afin de catégoriser les User Stories parmi les groupes que nous avons vu précédemment, nous allons Le ressenti d’un utilisateur vis-à-vis d’une fonctionnalité peut être :

  • « Je suis neutre » (pas d’avis en particulier)

  • « j’aime » (cette idée me plaît)

  • « je n’aime pas » (je n’accroche pas avec cette idée)

Afin de positionner la User Story dans le modèle de Kano, nous allons demander à l’utilisateur de donner son ressenti à partir des questions suivantes :

Que ressentez-vous si cette fonctionnalité est développée en premier lieu ?

Que ressentez-vous si cette fonctionnalité n’est pas développée tout de suite ?

Voici des exemples pour concrétiser mon propos.

Considérons les User Story suivantes :

Première User Story :

« En tant que client, je dois saisir un identifiant et un mot de passe afin de me connecter au Système d’Information. »

En posant les 2 questions aux futurs utilisateurs du système, nous obtenons par exemple les réponses suivantes :

Question n°1 : je suis neutre car cette fonctionnalité est basique.

Question n°2 : je n’aimerais pas que cette fonctionnalité ne soit pas présente car cela peut créer des problèmes de sécurité.

Deuxième User Story :

« En tant que commercial, je dois avoir la possibilité de consulter mon portefeuille clients afin de me faciliter le suivie de celui-ci. »

Voici les réponses que nous avons obtenues :

Question n°1 : j’aime cette fonctionnalité car cela va me rendre plus efficace.

Question n°2 : je n’aimerai pas qu’elle ne soit pas présente car elle concerne le cœur de mon métier.

Catégoriser les User Stories

Maintenant que nous avons noté le ressenti des utilisateurs, nous pouvons classer les User Stories parmi les catégories décrites dans le modèle de Kano :

  • Les User Stories basiques sont celles ayant pour réponse le couple « je suis neutre » / « je n’aime pas » car cela implique que la User Story est un besoin fondamental.

  • Les User Stories linéaires sont celles ayant pour réponse le couple « j’aime » / « je n’aime pas » signifiant là encore que la User Story est nécessaire.

  • Et finalement, les User Stories d’enthousiasme sont celles ayant pour réponse le couple « j’aime » / « je suis neutre ».

Lorsque les User Stories ont été classées par catégories, nous pouvons utiliser la technique du Priority Poker pour définir une priorisation à l’intérieur de chaque catégorie.

Priorisation à partir des thèmes

Cette méthode de priorisation du Product Backlog a été élaborée par Mike Cohn.

Pourquoi prioriser les thèmes ?

La priorisation des thèmes est intéressante car elle se fait au niveau macroscopique. Elle est donc plus facile qu’au niveau de la User Story elle-même.

Theme Screening (Sondage des thèmes)

Cette méthode se base sur la définition de 5 à 9 critères de sélection qui vont permettre de répondre à la question suivante :

« Quels sont les éléments importants pour l’entreprise qui doivent être mis en place dans la future itération ? »

Définition des critères

Pour répondre à la question précédente, nous avons, par exemple, les critères suivants :

  • Se donner un avantage réel par rapport à nos concurrents.

  • Permettre de tester le concept de Mr X.

  • La fonctionnalité est attendue des clients.

  • Générera des encaissements dès le trimestre prochain.

Choix d’un thème de référence

On choisit ensuite un thème de l’application qui doit être connu de tous et qui figure dans la liste des thèmes à développer dans la prochaine itération. Ce thème servira de thème de référence (TO).

Positionnement des thèmes par rapport à la référence

On positionne alors les thèmes en colonne dans un tableau à double entrée comme sur l’image ci-dessous. Les critères d’évaluation constituent les lignes du tableau.

On questionne l’ensemble des utilisateurs en leur demandant leur ressenti sur un critère par rapport à un thème.

Par exemple, supposons que nous avons choisi les critères c1, c2, c3, c4 et les thèmes TA, TB, TC et TD. Le thème TD est le thème de référence TO.

Est-ce que le critère c1 est plus important pour le thème A que pour le thème de référence ? Si oui, on insère un signe + dans le tableau. Si non, on insère un signe – et si l’importance est la même, on insère le signe 0.

Pour connaître la priorisation des thèmes, il suffit d’additionner pour chaque thème le nombre de + et de soustraire le nombre de -. On obtient une liste ordonnée des thèmes.

Theme Scoring (Mesure des thèmes)

Cette méthode de priorisation est similaire à la méthode Theme Screening à la différence qu’il faut attribuer un poids à chaque critère pour préciser son importance relative. Cette approche peut séduire davantage certains d’entre vous, par son côté rationnel.

Définition des poids

Un poids est défini en pourcentage et le total des poids de tous les critères doit faire 100%.

Par exemple, nous avons les poids suivants :

Critère 1 : 25%.

Critère 2 : 10%.

Critère 3 : 20%.

Critère 4 : 45%.

Comparaison des thèmes par rapport aux critères

Ensuite nous choisissons un thème de référence et nous comparons les autres thèmes à ce dernier en utilisant la grille de comparaison suivante :

Table 1. 

Facteur Valeur
1 bien pire que le thème référent
2 pire que le thème référent
3 identique au thème référent
4 mieux que le thème référent
5 bien mieux que le thème référent

Cette grille établit une relation entre un facteur et une valeur.

Elle s’utilise de la façon suivante :

Question : « Comment se positionne le critère 1 de ce thème par rapport au thème de référence ? »

Réponse : « Mieux que le thème référent. »

On obtient un résultat pondéré en multipliant le poids du critère avec le facteur correspondant à la réponse. On procède ensuite de la même façon en passant en revue l’ensemble des critères pour ce thème et on peut ensuite passer au thème suivant.

Nous présentons finalement tous ces résultats dans un tableau comme le montre la figure ci-dessous.

Nous voyons alors la priorisation des thèmes.

Priorisation des thèmes par l’utilisation de poids relatifs

La méthode de priorisation des thèmes par poids relatifs permet de les prioriser en mesurant l’effet de leur présence ou de leur absence sur l’itération à venir ou sur le produit à réaliser.

Evaluation des bénéfices et pénalités

Tout d’abord, il faut constituer une liste de thèmes non ordonnées.

Pour chaque thème, nous allons définir une valeur de 1 (faible importance /faible impact) à 9 [faible importance/faible impact) pour les critères suivants :

  • Bénéfice relatif : Quel est l’impact du thème sur le produit ? Est-il positif ?

  • Pénalité relative : Quel sera l’impact si le thème n’est pas développé ?

On présente ensuite l’ensemble des résultats dans un tableau comme celui figurant ci-dessous :

Table 2. 

  Bénéfice relatif Pénalité relative Total Valeur en %
Thème A 5 3 8 73%
Thème B 2 1 3 27%
Total     11  

Estimation du coût d’effort de développement

L’estimation du coût d’effort de développement sera expliqué dans mon article suivant, dans le chapitre estimation et planification de Sprint. En fait, pour chaque User Story, l’équipe de développement définit un effort estimé à l’aide d’un outil appelé Planning Poker, identique à celui appelé Priority poker. La présence de l’équipe de développement est donc nécessaire.

Pour chaque thème, on obtient le coût d’effort en additionnant les points de chaque User Story. On peut donc compléter le tableau précédent, et on obtient :

Table 3. 

  Bénéfice relatif Pénalité relative Total Valeur en % Coût d’effort Valeur en % Priorité
Thème A 5 3 8 73 % 40 39 % 1.87
Thème B 2 1 3 27 % 62 61 % 0.44
Total     11        

Calcul de la priorisation

Nous pouvons finalement calculer la priorité de chaque thème. :

Thème A = 0.73/0.39 = 1.87

Thème B = 0.27/0.61 = 0.44

Il arrive parfois que le Product Backlog soit construit en amont de la mise en place de la méthode Scrum et donc sans l’équipe de développement.

Il n’est alors pas possible de remplir la colonne estimation. Vous êtes cependant autorisé à insérer dans cette colonne les valeurs de votre choix, à savoir, par exemple, le coût financier du thème.

Priorisation par la communication

Une autre méthode peut être utilisée lorsque les User Stories sont déjà regroupées par catégories ou par thèmes.

Elle consiste en une animation dirigée par le Product Owner. Celui-ci confère à chaque utilisateur une User Story et leur demande de déterminer une valeur métier allant de 1 à 5.

Des couples d’utilisateurs doivent se former dans le but de défendre leur propre User Story au cours d’une discussion.

  1. Le premier utilisateur présente sa User Story à son interlocuteur.

  2. L’interlocuteur présente sa propre User Story ;

  3. Le premier utilisateur doit argumenter sur le fait que sa user Story a une Business Value plus importante que celle de son collègue.

  4. Ils inversent ensuite les rôles.

  5. A la fin de la discussion, la personne ayant été la plus convaincante ajoute au dos de sa User Story, le point qu’avait estimé son adversaire pour sa User Story.

  6. Les utilisateurs vont ensuite former un autre couple et recommence à partir de l’étape 1.

Après quelques itérations de discussion (chaque discussion est limité à une minute au maximum), le Product Owner met fin à celles-ci. Il demande alors aux utilisateurs de faire la somme des points situés au dos de leur User Story. Cette valeur représente la Business Value de la User Story.

La priorisation du Product Backlog est ensuite obtenue en ordonnant de façon décroissante les valeurs métier des User Stories.

Cette méthode est intéressante car elle peut apporter du dynamisme à la tâche de priorisation, parfois perçue comme austère.

Conclusion

Dans cette troisième partie, nous avons d’abord vu comment nous pouvons élaborer des tests pour les User Stories. Ces tests vont améliorer la qualité du produit et rendre les utilisateurs plus confiants.

Ensuite nous nous sommes intéressés à un problème crucial de la méthode Scrum : celui de la priorisation du Product Backlog. Diverses méthodes nous permettent d’obtenir cette priorisation et par là même de savoir quelles User Stories sont à réaliser en premier.

Références Bibliographiques

Site web :https://www.slideshare.net/mikecohn/prioritizing-your-product-backlog-22870228

Livre : Scrum, une méthode agile pour vos projets (éditions ENI)

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels