Besoin de feedback : Comment travailler avec des US verticales?

Communauté Scrum Life
1

Bonjour,
Dans le cadre du passage à des équipes pluridisciplinaires, il m’est proposé d’adopter des US verticales.
Ma compréhension du concept est le suivant: l’US « verticale » permet de traiter un besoin utilisateur dans sa globalité.
Par exemple : si le besoin est « En tan qu’utilisateur Je veux pouvoir me connecter au site Afin de … », on aurait une seule US qui traiterait de cette US.
Ensuite, designer, front, back estiment le besoin et l’US sera embarquée à un moment donné dans le sprint.
L’objectif de cela est d’apporter de la valeur à l’utilisateur et de pouvoir tester au plus vite.

Ma première réaction est que :

  • la complexité n’est pas la même d’un métier à l’autre pour un besoin de donner (peut-être que le dev back sera très simple à réaliser vs le dev front) => on peut me dire que l’important est de trouver un consensus pour cette estimation.
  • comment se passe le suivi (s’il y a une US globale, elle restera plus longtemps bloquée dans une colonne du tableau de suivi de sprint => plus compliqué de repérer en un coup d’oeil les points de bloquages) ?
  • J’ai lu que certains découpent l’US en tâches et que chaque US est attribuée à 1 personne => alors en en revient à une historie de vocabulaire où TACHE = US. Dans ce cas, y a t il un sens d’estimer une US ? Ne vaut il mieux pas estimer une TACHE et l’estimation de l’US revient à la somme des TACHES ?

Je suis plutôt ouvert à toute évolution, mais j’avoue que je bloque un peu sur l’avantage de cette approche.
Pour moi, l’important est que l’équipe ait la vision de ce que l’on fait, qu’il y ait de la discussion sur les US (échanger sur comment répondre au besoin, redécouper,…) et que le sprint apporte de la valeur.
Et une US indépendante apporte qd même de la valeur même si, d’un point de vue utilisateur, c’est un ensemble d’US qui permettront de repondre au besoin initial (ex: mettre en place l’API permettant de se connecter n’apporte pas forcément à l’utilisateur final si elle est prise de façon indépendante mais elle est indispensable à la réalisation).

Mais j’ai peut-être raté une étape du concept et je suis preneur de vos retours d’expérience.

Merci :slight_smile:

2

Hello seb !

Bienvenue ici !
Un premier truc qui me parle ici, dans ce que tu écris, c’est que j’ai l’impréhension que tu n’as travaillé que sur des US horizontales… Alors qu’en fait ce n’est pas le but d’une US. Une US, elle est verticale : tu regardes le besoin utilisateur, tu la donnes à ton équipe, et elle s’organise pour la découper en tâches techniques de 1 à 2 j environ pour répondre à ce besoin. L’intérêt étant : vite donner de la valeur pour vite avoir des retours utilisateurs !

  • la complexité n’est pas la même d’un métier à l’autre pour un besoin de donner (peut-être que le dev back sera très simple à réaliser vs le dev front) => on peut me dire que l’important est de trouver un consensus pour cette estimation.

L’important, c’est les discussions. C’est justement ce qui manque dans les équipes non pluri-disciplinaires, les discussions rapides entre front, API, back… Et si le consensus est chiant, tu peux utiliser la technique dans Clean Agile de Uncle Bob : tu moyennes le résultat !

Une US, faut essayer de la rendre petite. Et en quoi une plus grande, c’est plus difficile de repérer les points de blocages ? Je dirais au contraire, c’est limite plus facile de voir le gros éléphant au milieu de la pièce de mon expérience :wink:
Après, il y a généralement 3 niveaux de granularités : le thème (globalement à quoi ça sert pour le besoin utilisateur), l’epic (une US qui est trop grosse pour une itération, donc danger), l’US (granularité suffisante pour la prendre dans une itération)

  • J’ai lu que certains découpent l’US en tâches et que chaque US est attribuée à 1 personne => alors en en revient à une historie de vocabulaire où TACHE = US. Dans ce cas, y a t il un sens d’estimer une US ? Ne vaut il mieux pas estimer une TACHE et l’estimation de l’US revient à la somme des TACHES ?

Alors NON : chaque US n’est pas attribuée à une personne.

En fait l’US c’est :
Le besoin sous la forme de QUI QUOI POURQUOI (« En tant qu’utilisateur je veux rechercher un groupe pour pouvoir voir le prochain concert d’eux et pouvoir l’acheter après »)
Ca permet de planifier facilement un ensemble d’US utilisateur afin d’avoir un parcours utilisateur clarifié pour l’équipe, puis de les planifier dans des itérations petit à petit et rapidement avoir des feedbacks des utilisateurs.

Désolé ça fait beaucoup d’infos, n’hésite pas à demander des clarifications !

2 « J'aime »
3

Hello et bienvenue,

En fait une US verticale, c’est juste … une US: ça décrit une interaction avec le système du point de vue de l’utilisateur. Lui se moque de savoir s’il y a une architecture en 1, 2, 5 ou 92 sous-systèmes, avec des équipes dédiées ou partagées. En revanche, cette interaction doit lui apporter de la valeur.

Si on fait des découpages de backlog au niveau technique, par exemple l’ajout d’une route dans une API, ben c’est cool, mais si n’y a pas un front pour appeler cette route, l’utilisateur n’en voit pas la couleur, et donc il n’y a aucune valeur apportée. Donc à quoi bon développer cette nouvelle route ? Note: il peut y avoir une bonne raison mais dans ce cas c’est probablement qu’on se trompe d’utilisateur.

Ensuite la logique de Scrum, c’est qu’en planning le PO vient avec un objectif = une story = une fonctionnalité à développer durant le sprint. Là, l’équipe de développement, qui est pluridisciplinaire travaille ensemble, en mêlée (= traduction de Scrum), pour atteindre cet objectif. L’équipe établit alors un plan prévisionnel de choses à faire (les tâches) qu’elle se répartit. C’est à ce moment qu’à lieu le design technique de la solution. Avec le PO, avec le SM, et avec les devs (par opposition avec la pratique de la « spec-story »). Et c’est là aussi qu’entre en compte la diversité de la complexité selon les tâches et les métiers. On doit donc potentiellement faire des compromis pour atteindre l’objectif de livrer une version d’ici la fin de sprint.

A cette étape du processus, estimer les tâches n’est pas important. L’estimation des tâches peut être un outil pour aider l’équipe à faire un plan crédible mais ce n’est pas une fin en soit. Ce qui est important c’est d’estimer la crédibilité du plan global devant aboutir à fournir la fonctionnalité-story aux utilisateurs d’ici la fin du sprint.

Ensuite, le suivi s’effectue quotidiennement, lors de la mêlée quotidienne, où on inspecte le plan et on peut le faire évoluer, en fonction de ce qu’on a appris jusqu’à présent. Car le plan est un prévisionnel, mais on ne sait jamais vraiment ce que ça va donner tant qu’on n’a pas fait le travail. Lors de la mêlée quotidienne, l’objectif de toute l’équipe, c’est d’aboutir, à la fin du sprint, à la livraison de la fonctionnalité-objectif-US prévue aux utilisateurs. Cette livraison prend la forme d’un incrément utilisable (= conforme à la DOD) pour que les utilisateurs donnent un avis et permettent d’affiner la solution.

Attention, c’est l’incrément qui est terminé, pas la fonctionnalité.

On veut justement obtenir l’avis des utilisateurs pour savoir si on doit la faire évoluer. Et au lieu de faire ça au bout d’un tunnel de 6 mois qui noie les utilisateurs sous 25 nouvelles fonctionnalités ou corrections de bug, on fait un incrément élément par élément, développé rapidement et à peu de frais, pour savoir si on se dirige dans la bonne direction ou non.

4

Désolé Sébastien ce n’est pas contre toi personnellement, mais est-ce qu’on peut prendre juste un moment pour apprécier le niveau d’absurdité auquel l’agilité a pu parvenir pour appeler « user » story un truc qui ne serait pas vertical ?

À quel moment est-ce qu’un utilisateur, même l’utilisateur fictif et fantasmé des « En tant qu’utilisateur… », pourrait se dire « alors moi je voudrais bien avoir un bouton là dans l’interface, mais c’est pas grave s’il ne fait rien hein, je comprends que le dev back n’était pas dispo parce qu’il travaillait sur ses US à lui » ?

Une US, c’est forcément vertical. Si ce n’est pas vertical, alors c’est une tâche, ou au mieux une somme de tâches. Mais l’idée d’une « US front » ou d’une « US back »… quelle absurdité :slight_smile:

Maintenant, pour répondre aux questions posées :

  • La complexité n’est effectivement pas la même d’un métier à l’autre pour une US donnée, mais ça n’empêche pas de donner une estimation globale dans une unité abstraite (au hasard, les story points). Et oui, arriver à un consensus est plus important que l’estimation elle-même. Au moment du planning, l’estimation la plus fiable est encore le sentiment de l’équipe en voyant ce qui a été sélectionné, indépendamment de ce que disent les chiffres. S’il y a trop peu de front par exemple, les devs front n’ont pas besoin de chiffres pour s’en rendre compte.

  • Le fait qu’il n’y ait qu’un seul ticket dans le tableau de sprint facilite au contraire le suivi, dans le sens où on garde mieux la vue sur l’objectif qu’on cherche à atteindre. Ça rend la responsabilité de rendre un service à l’utilisateur collective plutôt qu’individuelle. La question en daily devient « qu’est-ce qu’on doit faire en tant qu’équipe pour que ce service soit rendu ? » plutôt que « mais qu’est-ce qu’il fout machin à ne pas avoir fini sa tâche ? ». Ça donne plus de flexibilité dans l’atteinte de l’objectif de l’US, que ce soit au niveau des gens qui contribuent qu’au niveau des solutions à mettre en œuvre. Et ça augmente la probabilité d’avoir livré de la valeur à la fin du sprint : si tu as un sprint avec 5 US, il vaut mieux avoir 4 US fermées et une presque pas entamée, plutôt que 5 US « presque finies ».

  • Sur l’estimation de l’US comme la somme d’estimations individuelles, une histoire que j’aime bien c’est celle du golfeur. Si tu cherches à savoir combien de coups un golfeur a besoin pour faire ses 18 trous, tu auras une réponse bien plus précise en lui demandant une estimation globale qu’en lui faisant estimer chaque trou séparément et en sommant les estimations. Trop de découpage peut nuire au découpage. Et puis comme je le disais plus haut, c’est toujours le sentiment général de l’équipe qui finit par l’emporter. Si les chiffres disent que ça passe mais que l’équipe ne le sent pas, elle poussera pour réduire le périmètre. Si les chiffres disent que ça ne passe pas mais que l’équipe est confiante, elle poussera pour y aller quand même.

5

Bonjour,

Avant toute chose, un grand merci pour vos retours complets et détaillés (et donc pour le temps consacré).

De ce que je déduis de vos retours, c’est que c’est beaucoup une histoire de sémentique / représentation et que l’on parle de la même chose.
Je suis 100% d’accord avec vous sur le fait que, si on schématise à outrance, une US back, une US front, une US UI/UX, … n’a pas bcp de sens prise individuellement pour l’utilisateur final (même si typiquement, elles peuvent apporter du feedback via du test utilisateur / de comportement… même si ce n’est pas « en prod »). De là à penser que que c’est un non sens, pas certain : https://www.youtube.com/watch?v=vAUoFakjr0I. Disons que c’est une approche possible.
On pourrait se dire que les X US « horizontale » seraient équivalentes aux X tâches d’une US « verticale ».
Mais je vous rejoins sur le fait que conceptuellement, il est bcp plus simple de formuler et ça fait plus sens d’avoir une US globale comme « En tant que xxxx je veux xxxx… » avec un ensemble de tâches rattachées.
Ceci dit, si l’on se réfère au scrum guide, il n’y a pas de notion de User Story, Task, … Et c’est très certainement pas anodin.
L’essentiel étant que les membres de l’équipe / l’organisation parlent un langage commun.
Ensuite, c’est le sprint dans son ensemble qui apporte de la valeur (et donc les éléments qui le composent, que ça soit des US, des tasks). Car pour toute US du sprint, aussi verticale soit elle, si une des tâches qui la compose n’est pas finie, forcément, l’US ne passe pas en prod et le sprint n’est pas atteint.

Concernant l’estimation de l’US dans sa globalité, plutôt que l’estimation des tâches, effectivement, on peut faire une sorte de moyenne (et effectivement, cela n’a pas trop d’importance, l’idée est surtout que l’équipe puisse être en mesure d’évaluer le travail à embarquer dans le sprint).

Merci pour vos retours, cette approche est plus claire pour moi.

Je testerai probablement l’approche verticale tout en gardant une vue sur les tâches lors du sprint car, selon moi, s’il y a des dépendances entre elles, c’est important de pouvoir les visualiser (et non pas dans une optique de flicage).

Bonne journée à tous,

Sébastien

6

Non en effet, le scrum guide parle seulement de product backlog items car il se veut générique.
Il n’est pas très bien fait sur ce point à mon avis, voire limite trompeur.

Le concept de user-story, quant à lui, est un outil spécifique au génie logiciel, créé par Kent Beck pour XP, et repris indépendamment par une majorité de pratiquants de Scrum pour « formatter » les items et « forcer » les PO à décrire une interaction porteuse de valeur pour l’utilisateur. L’objectif est d’éviter de tomber dans les deux mauvais extrêmes que sont les PBI de type « tâche » ou de type « epic ».

Sans trop de surprise, l’expérience montre que le design technique (découpage d’une fonctionnalité en tâches techniques) est nettement plus pertinent quand on le confie à toute l’équipe plutôt qu’au PO seul.

L’important c’est de se rappeler que le point fixe du sprint c’est le sprint goal et non la liste de tâche. La liste de tâche est un moyen prévisionnel d’atteindre l’objectif, et le rôle de la mêlée quotidienne c’est d’affiner le plan, en modifiant les tâches si nécessaire, pour atteindre l’objectif. La liste des tâches est donc un outil au service de l’équipe pour se rappeler des actions à mener, et s’assurer que l’objectif reste atteignable au cours du sprint.

C’est pour cette raison que l’objectif de sprint est aussi important: quand il n’existe pas, la liste de tâches devient l’objectif. La mêlée quotidienne perd alors son sens pour redevenir un « status report ».