Cahier des charges déguisé 🫣 Bien utiliser User Story, Epic, Theme, Feature !

Рет қаралды 5,305

Scrum Life - Lean, Agile, Kanban

Күн бұрын

Пікірлер: 28

@ScrumLife 7 ай бұрын

Vous mettez quoi derrière "Epic" dans ton équipe, dans ta boîte ou chez ton client ? Dis-nous, on est curieux !

@UniversB3 7 ай бұрын

Ici, on a avait un découpage à 2 niveaux. L epic : qui représentait une grande fonctionnalité qu'on découpait en plusieurs US. Comme on est en phase de réécriture de notre produit, on a ressenti le besoin d'avoir un 3eme niveau. On va avoir dans quelques semaines le découpage suivant sachant qu'on utilise redmine et qu'on garde bien le lien entre les différents niveaux. Epic = { feature} Feature = { Us} Us = un seul scénario utilisateur. Voilou ! Bouchra

@ScrumLife 7 ай бұрын

Merci du partage ! Est-ce qu'en prenant un peu de recul tu te dis qu'il faudrait changer quelque chose ? Comment améliorerais-tu ça ? -- JP

@Roland-cy7ll 7 ай бұрын

Basiquement derriere une Epic on a des features. Et derriere une Epic on a un MVP qui est un ensemble de features qui permettent de valider l Epic. D ailleurs je ne sais jamais si on dit une ou un Epic.

@nicolasponcet8626 7 ай бұрын

Merci pour cette vidéo éclairante ! Comme j utilisais Jira, j ai moi aussi été influencé par l outil 😅 Nous avons commencé notre projet avec des Épics qui sont vites devenus au fur et à mesure des Sprints, des Themes. Et le lien US / Epic(=thème) a été reproduit pour les nouveaux problemes générant de nouveux Récits Utilisateurs, directement sous le nom d'US, au détriment de la lisibilité sur leur taille (Epic=n futures US) et leur association avec le Product Backlog clair et contextualisé.

@ScrumLife 7 ай бұрын

Est-ce que ça te donne envie de changer d'approche ? -- JP

@ScrumLife 3 ай бұрын

Merci @nicolasponcet8626 pour ton retour ! 🎉 Je comprends parfaitement ta situation. L'influence des outils comme Jira peut parfois brouiller les pistes. 🙂 En fait, c'est un challenge courant dans l'adoption des approches agiles : l'outil devient une fin en soi plutôt qu'un moyen. Ton retour sur la confusion entre Épics et Thèmes est très pertinent. Une Épic devrait en effet être vue comme une grande User Story fragmentée en plus petites, tandis qu'un Thème regroupe des User Stories ayant un objectif commun. Ta remarque sur la lisibilité et l'association avec un Product Backlog clair est cruciale. Un Backlog bien structuré avec une hiérarchisation évidente peut largement faciliter la compréhension et la priorisation des tâches. N'hésite pas à creuser encore plus cette thématique ! Quelles autres bonnes pratiques as-tu mises en place pour garder ton Backlog lisible et pertinent ? À très vite sous la bannière de l'agilité ! 🚀 Robin

@vincentgillet3428 7 ай бұрын

Merci pour cette vidéo J'étais dans une mission avec du simili SAFe Les epics pourraient correspondre à des product goals, les PI plannings donnaient une feuille de route découpée en features rattachées à ces epics et enfin lez features étaient découpées en US. Le tout dans Jira. Qu'en dîtes-vous de ce type de découpage ? En tout cas, aucune notion de thème dans mon exemple Merci

@amineherizi4687 6 ай бұрын

J'étais dans une mission qui utilisait ce même découpage et tout est claire et efficace, j'étais étonné de voir qu'on pouvait avoir un lien direct entre Epic et US sont passé par des Features. Je pense que le fait d'avoir une Gross Epic avec des Features dedans qui sont par la suite déclinés en US est une très bonne approche.

@ScrumLife 3 ай бұрын

Salut @vincentgillet3428, Merci pour ton commentaire et pour avoir partagé ton expérience. 🎉 C'est fascinant de voir comment différentes équipes s'approprient les approches agiles ! Ton découpage de l'épique jusqu'aux user stories via les PI plannings et les features est une procédure courante et pragmatique. Ça marche particulièrement bien pour donner une vision d'ensemble tout en gardant une granularité sur les tâches à court terme. Cependant, si aucune notion de thème n'est présente, cela peut parfois complexifier la traçabilité des objectifs stratégiques à long terme. Je trouve que les thèmes peuvent donner un cadre supplémentaire pour aligner les efforts sur des objectifs plus larges et peuvent aider dans la priorisation. As-tu déjà expérimenté avec les thèmes dans un autre contexte ? Curieux de connaître ton avis. 😃 À bientôt, Robin

@TheCalibou 7 ай бұрын

Merci pour cet éclairage. Par contre, je n'ai pas compris ce qu'est un product goal ou une fonctionnalité, car vite écartée. Chez nous, on utilise aussi Jira. Des product owner s'occupe des epic, dont des portfolio, comme des fonctionnalités ressemblant à un cahier des charges. Donc tout est précis des le début mais finement découpé.

@ScrumLife 7 ай бұрын

Oh, mais effectivement ! On a parlé comme si de rien n'était du Product Goal, sans prendre le temps de l'expliquer alors que c'est une notion relativement récente... Voici la vidéo sur le sujet : kzbin.info/www/bejne/bn66i5uXgK6Ejpo Dis-nous si ça t'éclaire ensuite ! Merci de ton partage 🙏 -- JP

@ScrumLife 3 ай бұрын

Salut @TheCalibou ! Merci pour ton commentaire et pour avoir partagé ton expérience. Je vois que tu évoques des points très intéressants sur l'utilisation des épics et des fonctionnalités. Pour clarifier, le "Product Goal" en Scrum est une vision à long terme que l'équipe Scrum s'efforce d'atteindre. C'est comme un étoile polaire qui guide toutes les actions de l'équipe. Contrairement aux fonctionnalités ou aux récits utilisateurs, le Product Goal n'est pas une tâche individuelle à accomplir, mais plutôt une ambition globale qui aligne les efforts de l'équipe sur des objectifs communs. En ce qui concerne Jira, il est effectivement fréquent de voir des Product Owners utiliser des épics pour structurer leur travail. Les épics, chez nous, regroupent de grands morceaux de travail qui peuvent être scindés en récits plus petits et plus gérables. Le lien avec ton "cahier des charges" me semble pertinent : il s'agit de balayer en détail ce que l'équipe doit réaliser pour atteindre un objectif spécifique. J'espère que cela éclaire un peu plus le sujet pour toi ! D'ailleurs, est-ce que tu as d'autres questions ou des points spécifiques que tu aimerais que je développe un peu plus ? N'hésite pas, je suis là pour aider ! A très vite, Robin

@OlivierFarlotti 7 ай бұрын

Je n'avais pas forcément rapproché explicitement les Epics du Product Goal. Je note :) Pour ma part, dans ma propre pratique auprès de mes coachés, je leur présente les EPICs comme un grand besoin et j'insiste (à tort ?) sur leur dimension business. Je m'attends à y voir des hypothèses de valeur avec des €€€ et , tandis que les features sont un découpage de ce besoin au niveau grande fonctionalité (ou usage) tandis que les US sont encore un découpage portant les uses cases les + petits possibles. Je me rends compte que plus il y a de niveaux de découpage, plus on cristalise une solution....

@ScrumLife 7 ай бұрын

Ah ah, on réfléchit tous ensemble, hein ! Avoir une dimension business et des €€€ c'est TOUJOURS une bonne idée 😁 Est-ce que tu changerais des choses dans ton approche par défaut suite au visionnage de cette vidéo ? -- JP

@OlivierFarlotti 7 ай бұрын

@@ScrumLife peut être les niveaux de découpage.

@ScrumLife 3 ай бұрын

Salut @OlivierFarlotti, Un grand merci pour ton commentaire détaillé et pour avoir partagé ta perspective ! C'est super intéressant de voir comment tu insistes sur la dimension business des Epics. La focalisation sur les hypothèses de valeur et l'impact économique (€€€) est effectivement cruciale dans une approche orientée résultats. C'est vrai, plus on découpe, plus on peut risquer de cristalliser une solution spécifique - mais c'est aussi une opportunité pour affiner la compréhension et maximiser l'alignement avec les objectifs business, non ? Je me demande : comment tes coachés réagissent-ils à cette vision des Epics ? Et comment trouves-tu l'équilibre entre découpage et flexibilité ? Merci encore pour ta contribution et hâte de te lire à nouveau ! À bientôt ! Robin 🌟

@JfD_xUp 20 күн бұрын

Bonjour. Merci pour ce partage, je m’interroge encore sur Scrum - je suis plus orienté V/cascade et Lean présentation : je mettrais "Scrum term" / "niveau de granularité de la valorisation | (autre dénomination)" dis-nous si je résume correctement - ta vision serait : US : cas particulier / use case feature : cas d'usage général - usage métier / usage case | job case epic : lié à un processus métier particulier / process case pour moi les visions €€€ et business ne peuvent pas être liées aux niveaux Epic, bien que ces Epics pourrait être utilisés comme base d'évaluation d'une plus-value (stream value chain) pour moi, il faudrait alors ajouter : theme : dimension business (ex : obligation de sécurisation) / business case initiative : choix d'une stratégie = valorisation €€€ envisagée ou concurrentiel (d'où on retrouvera des "thématiques stratégiques") / strategic market case positioning | business model

7 ай бұрын

EPIC > Feature Theme > EPIC Safe a fait beaucoup de tort au vocabulaire. Effectivement, ce qu'on appelle "EPIC" en Scrum (alors que ce n'est pas dans le SG) c'est "une US trop grosse pour un sprint" J'aime beaucoup dire qu'une éqic bien réussie, c'est quand on finit l'epic en ayant fait le MOINS de story possible. Si on dit "c'est fini quand tout est fait" alors on a découpé en tâches et pas un US

@ScrumLife 6 ай бұрын

Tu touches un point super intéressant @ChristopheGesche! Ton approche de "faire le moins de stories possible pour compléter un epic" est vraiment dans l'esprit de l'agilité-maximiser la valeur en minimisant le travail non nécessaire. C'est une super perspective pour garder les choses simples et rester focus sur la valeur. 👍💡 Robin

@JfD_xUp 20 күн бұрын

@@ScrumLife bonjour, pardon de m'interposer, mais il me semble vous confondez (ou par rapidité d'écriture) "agilité" (adaptation) et le "lean" (l'optimisation d'où en est sorti "maximiser la valeur avec un minimum de travail"), là où l'agilité en terme pur peut répéter des actions de part l'adaptation et les itérations (besoin client, technologique etc ce qui n'est pas nécessairement optimisé). Désolé, je ne suis pas un pro de Scrum, mais il me semble que Scrum base 80% du discours en terme de spécifications fonctionnelles et non techniques (20% restant disons) "c'est fini quand tout est fait" sous l'égide Scrum serait alors un "done" pour toutes les US sous-jacentes d'une épique, comme on le fait en méthode V/cascade - ici c'est plus représentatif de la "version Agile" répondant à la demande/besoin en cours. "faire le moins de stories possible pour compléter un epic" serait la transposition en version Lean les 2 (agile et Lean) n'étant pas opposables, mais me semble t-il, plus difficile à composer du fait de sprints de 2 semaines. Il me semble justement que le PO devrait avoir une vision à plus long termes, type SaFe / train, planifiable dans la vision (initiative, thèmes) sans nécessiter de précision (qui viendra au fur et à mesure)

@JfD_xUp 20 күн бұрын

Bonjour, où mettriez-vous les termes "initiatives" et "taches" ? pour le terme "fonctionnalité", je m'excuse, mais votre vidéo ne semble pas vraiment expliciter ce terme. pour moi, une "fonctionnalité" serait plus une fonction support, comme une base réutilisable dans d'autres US/épiques. ex technique : un peu comme un "objet abstrait" en POO (programmation orienté objet) ex fonctionnel : reporting automatisé de bugs de programmation (in-situ), ou encore les "décorations", la mise en place d'outils d'automatisation ou l'analyse des messages échangés (sous de thème de la "qualité / exigence / IVVQ"), fonction qui sera supprimée pour la livraison (pas de besoin client, mais répondant à une exigence)

7 ай бұрын

Le drame c'est quand le PO crée des Epics

7 ай бұрын

Si une EPIC est un PBI exprimé sous forme de Récit (US) mais trop ambitieux pour "un sprint"... Comment un PO peut créer un epic sans consulter son équipe pour voir que c'est trop ambitieux