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
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.
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é.
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
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
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.
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
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é.
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 : ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-8MWZhaKIQX8.html Dis-nous si ça t'éclaire ensuite ! Merci de ton partage 🙏 -- JP
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
4 месяца назад
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
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
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....
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
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 🌟
4 месяца назад
Le drame c'est quand le PO crée des Epics
4 месяца назад
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
