Pilotage Agile avec le Burn-Up - Scrum Life 21

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/I3tp4e

[@jeremiegroulet6619]

merci, j'en découvre la vraie utilité.

[@clotairegouala494]

Merci J.P. je ne connaissais pas cette formule pour gérer les malentendus entre l'équipe et son environnement

[@jeremieroudaut6371]

Merci Jean Pierre, un bonne outil à tester en parallèle d'un story mapping j'imagine.

[@chuibete]

L outil a l'air top, je vais voir pour l utiliser

[@ScrumLife]

Est-ce que tu nous raconteras ? -- JP

[@chuibete]

@@ScrumLife Avec plaisir faudra juste que je me souvienne sur quel video j'ai laissé un commentaire ^^

[@TheVavan29]

Cette vidéo tombe à pic ! On est en pleine mise en place de cet outil sur notre projet :D

[@lionelfristot568]

Tout pareil pour moi, perfect timing :)

[@yvesthiery4733]

😂 ."Le burn down est bien pourri..... mais c normal qu'il ressemble à rien ; On a eu plein de trucs en plus ….." ? Oh OUI ! ce chart par nature a tjs créé des crispations et frustrations. Le Burn Up est révélateur du mindset de l'agilité , est un bon outil visuel de suivi et de COM autour du projet.

[@ScrumLife]

Merci 😁 Est-ce que tu l'utilises au quotidien avec tes équipes ? -- JP

[@xaviertiteca-beauport9164]

Merci JEan-Pierre. ça aurait été chouette d'avoir un peu plus de détail sur comment construire chacune des deux courbes. JE vais regarder s'il n'existe pas un épisode sur le calcul de la vélocité concernant la courbe du bas, mais pour celle du haut, j'ai cru deviner qu'il s'agit du nombre de feature ou d'US, je ne sais pas trop.

[@ScrumLife]

Salut Xavier, la courbe du bas représente le travail déjà fait. Comme pour le calcul de la vélocité, on ajoute les "points" des éléments terminés, et on les ajoute au total de ce qui est déjà terminé. Sur à cette itération on a fait 15 points, et que jusqu'ici on avait fait 62 points, alors nous sommes maintenant à 77 points terminés. Pour la courbe du haut c'est la somme des "points" des éléments de backlog qu'on a identifié dans le périmètre qui nous intéresse. Est-ce plus clair ainsi ? -- JP

[@xaviertiteca-beauport9164]

@@ScrumLife très bien merci JP, oui c'est plus clair.

[@WalidBouanani]

Pour faire le burnup chart il faut avoir une estimation de tout les tickets du backlog ?

[@Cedoch]

Je n’utilisais pas le burn-up, mais je compte le faire maintenant ! Merci.

[@en8636]

un périmètre "figé" : que constitue le périmetre et en quoi est -t-il figé? ( merci-sm débutant en apprentissage) :)

[@ScrumLife]

Bonjour : Un périmètre "figé" est un périmètre qui, à l'avance, définit clairement les objectifs et fonctionnalités à atteindre (l'ancien cahier des charges ?)... dans un monde complexe, ce n'est pas forcément la bonne approche. Robin

[@charlinedufour3640]

Bonjour Jean-Pierre, je découvre l'outil grâce à cette vidéo et j'ai envie de le mettre en place sur le prochain projet que je vais piloter. Toutefois, j'ai une question : Est-ce les points d'estimations (poker planning) qui sont utilisés comme échelle des graphiques ou le nombre de stories ?

[@ScrumLife]

Salut, on doit pouvoir utiliser les 2 mais c'est plutôt les points d'estimation car généralement on est à un niveau macro où les différents éléments peuvent avoir des tailles très différentes. Tu nous raconteras ce que ça donne sur ton prochain projet ? -- JP

[@fun3000able]

Pour répondre à ta question, non le burn up chart n'"est pas nouveau dans le concept, mais le fait de le représenter et de l'utiliser ouvertement est une avancée : le périmètre bouge et ce n'est pas un signe d'échec comme dans certaines approches cycle en V.

[@christianseme734]

Il y a me semble-t-il 3 unités possibles pour le burn-up : sur le nombre de User Stories (Pas idiot à l'échelle d'une release, ca montre bien l'évolution du périmètre, mais moins bien le niveau de valeur ou de complexité atteint), les points de valeur (mais du coup la projection du done ne sera pas nécessairement linéaire), les points de complexité (mais pour cela, il faudra avoir déjà une première estimation des points de complexité de toutes les US du backlog, ce qui n'est pas toujours le cas)

[@ScrumLife]

Nuances intéressantes, merci. Néanmoins j'aimerais élaborer sur votre commentaire sur le troisième cas de figure : "il faudra avoir déjà une première estimation des points de complexité de toutes les US du backlog, ce qui n'est pas toujours le cas" Si ce n'est pas le cas et que c'est totalement normal parce qu'on est en "mode produit" plutôt qu'en "mode projet" alors je questionne l'intérêt même de l'exercice. Pourquoi faire un Burn-Up si on n'a pas de date de fin ? Par définition cet exercice sert à se projeter sur une date de fin, il faut donc connaître le périmètre -- qui bien entendu n'est pas figé et évoluera, mais qui est malgré tout connu en son état actuel à l'instant T. Qui plus est, il n'est pas interdit de faire l'exercice en sachant pertinemment que la courbe de périmètre va monter non pas parce qu'on va rajouter du travail mais simplement parce qu'on va affiner le backlog restant. Cela nécessite cependant une communication supplémentaire spécifique, ce qui peut rendre l'exercice périlleux.

[@sebastienleclerc6847]

Mon plus gros problème par rapport au burn up c'est d'avoir la visibilité suffisante sur le périmètre global. On chiffre sprint après sprint les US et l'occupation du PO fait qu'il est difficile de prendre de l'avance sur l'écriture des US et sur le chiffrage... Comment résoudre ça?

[@ScrumLife]

Est-ce un problème ? Le burn-up est un bon outil dans le cas d'un périmètre plus ou moins connu à l'avance -- il sera bien sûr ajusté, mais on a déjà une base de départ qui représente l'ensemble du périmètre connu à l'instant T. De nombreux produits ou projets ne sont pas dans ce cas de figure. Le produit vit dans le temps et continue de vivre. Dans ce cas on n'a pas de périmètre connu qui permet d'utiliser le burn-up. Si malgré tout vous êtes dans un cas de figure où le burn-up fait sens mais que le PO manque de temps pour vous permettre de faire ce travail, il va alors falloir lui prendre une partie de son travail. Il faut trouver le bon équilibre entre équipe de développement et PO. Vous pourriez par exemple prendre en main l'écriture des US, le PO se concentrant plus sur la vision. Finalement, vous définiriez ensemble l'objectif de sprint et vous vous débrouilleriez pour tout le reste.

[@sebastienleclerc6847]

@@ScrumLife Merci beaucoup pour cette réponse! ça va m'aider énormément !

[@leilaben3545]

Hyper intéressée pour utiliser cet outil !

[@ScrumLife]

N'hésite pas à nous demander des conseils complémentaires ! Et à nous raconter ensuite ce que ça a donné 💪 À bientôt ! -- JP

[@j0hnmerrick]

sur mon burn up, je met la valeur business produite. vu qu'on commence (en théorie) par les fonctionnalités ayant le plus grande valeurs business, on se rend compte qu'au bout d'un moment on apporte plus vraiment de valeur au produit (ou très peu). Peut être qu'il faut arrêter le projet non ?

[@ScrumLife]

Peut-être bien ! :-) Dans ce que tu décris, l'usage et l'enjeu n'est pas le même. Je trouve ça très bien vu ! Mais est-ce que ça n'aurait pas encore plus d'impact en cumulant les deux : effort vs. valeur ? Pour voir justement que l'effort qu'on met dans le produit est de moins en moins rentable.

[@huguespeccatte1532]

Quelle est l'unité pour ces burn-ups s'il te plaît ? À mon sens, les seules unités qui pourraient être valables seraient : - le temps : cela induit que pour toutes les stories, on soit allé jusqu'à la création des tâches, de leur estimation horaire (ce qui ne se fait pas vraiment trop en avance il me semble) et cela pourrait mettre une certaine pression à l'équipe car il y a alors une forte notion de temps / d'échéance => ça ne me semble donc pas pertinent pour le périmètre ; - l'effort : cela induit que la totalité des stories présentes actuellement soit estimée en terme d'effort, et je ne crois pas que le backlog doive être estimé entièrement… => ça ne me semble pas pertinent non plus pour le périmètre ; - le nombre de stories : c'est le plus simple à mesurer et ça fonctionne aussi bien pour le travail accompli que pour le périmètre => serait-ce la bonne unité ? Dans ce cas, cela signifie que l'on considère globalement que les stories sont équivalentes (ou que l'on prend une moyenne de taille / effort / temps). Cela est-il dérangeant ou au contraire acceptable vu qu'il ne s'agit que de prévisions grosses mailles ? Merci pour tes réponses et les vidéos !

[@lionelfristot568]

Mon avis perso pour le moment après avoir lu/échangé/expériencé, le nombre de stories me paraît être la bonne option. En tout cas dans un premier temps, et surtout dans le cas d'une équipe qui démarre, elle n'est pas assez à l'aise sur le fonctionnel / infra / ... pour estimer. On ne cherche pas forcément une précision millimétrée mais une tendance moyenne et ça marche plutôt bien à ce niveau d'abstraction. Un autre moyen qui rejoins un peu les 1 et 2 c'est de faire faire une estimation des stories du backlog en taille de T-shirt grosse maille, en expliquant bien à l'équipe que ce n'est pas engageant mais pour se donner une idée. Au final, l'estimation sera sûrement proche de la réalité, on constate souvent que les erreurs se compensent entre elles entre les sous-estimations et les sur-estimations si le backlog est composé d'assez de users stories (genre > 20 quoi).

[@grumly85]

De notre côté on ne s’en sert pas pour le moment, l’équipe est encore récente et les process agile se mettent encore en place petit à petit. Mais en tout cas ça donne une meilleure idée que de juste penser que c’est le burn down à l’envers !

[@olivierbakou158]

Excusez-moi monsieur, souvent je me pose des questions sur vous et je me demande si réellement vous connaissez ce que vous présentez. Vous êtes comme un étudiant qui a lu une information et vient la présenter à ces collègues avec arrogance pour montrer qu'il maîtrise la chose

[@ScrumLife]

Bonjour, Qu'est-ce qui vous fait penser ça ? Pourriez-vous être plus précis s'il vous plaît ? En quoi le contenu de cette vidéo ne correspond pas à votre expérience ? Que reprochez-vous à la manière de présenter la vidéo ? Merci d'avance, -- JP