User Story non terminé : on fait quoi de son estimation en Story Points ? Scrum Life répond !

[@ScrumLife]

Voici les pratiques agiles d'aujourd'hui : kzbin.info/www/bejne/q6emp6qqgJKDY68

[@esunyer]

Cette vidéo est sans doute encore plus puissante qu’il n’y paraît. C’est ce que j’appellerais mettre en coup de pied dans la fourmilière. On devrait penser à rendre son visionnage obligatoire pour toutes les équipes 🙃

[@ScrumLife]

Wow, merci ! Quel élément en particulier te fait dire ça ? -- JP

[@esunyer]

@@ScrumLife Et bien, au détour d'une réponse à une question pratico-pratique, cette vidéo aborde en réalité beaucoup, beaucoup de choses : Biais des coûts irrécupérables, focus sur les objectifs business/utilisateurs, Sprint Goal, Product Goal, indicateurs de suivi de l'atteinte des objectifs business/utilisateurs, "La bonne chose à faire", "Terminé", visualisation de ce qu'il se passe vraiment, projections de l'équipe, adaptation du plan en continu, redécoupage as-you-go des User Stories, "Dépiler du ticket", pression sur les équipes, Scrum vs Kanban... C'est riche, très riche. Mais, ce qui me paraît peut-être le plus intéressant, c'est le paradoxe qu'elle met en avant : Le propre de l'agilité c'est de challenger le statu quo, de chercher de nouvelles manières de générer de l'impact positif pour des "bénéficiaires" et s'adapter au plus tôt en fonction de ce qu'on a testé, découvert et appris. C'est la confiance en nous-mêmes, le produit, le marché via la transparence, les mesures et le feedback. C'est l'acceptation de la survenue inévitable d'échecs en chemin parce qu'ils nous permettent justement de rebondir et que nous ne perdons jamais de vue les objectifs sur lesquels nous nous sommes alignés. Pourtant (peut-être, en effet, "aidées" par des éditeurs logiciels qui ont besoin de vendre du "prêt à penser"), de nombreuses organisations et équipes passent à côté de l'innovation en continuant à vouloir produire, faire le taf, plutôt que de chercher à répondre avec empathie aux problèmes des utilisateurs, elles continuent à vouloir prédire précisément mais de manière factice le futur alors que le travail de création n'est généralement pas une redite d'un autre fait précédemment, elles s'accrochent à des pratiques initialement novatrices et utiles aux discussions mais dont elles n'ont pas appris les limites et les effets pervers. Est-ce pour se rassurer ? Par facilité ? Nous avons besoin d'être plus agiles avec notre manière d'envisager l'agilité. C'est ce que Scrum nous permet et nous encourage à faire, en tant que cadre de travail léger, peu prescriptif et accueillant avantageusement des pratiques complémentaires. C'est ce que j'aime particulièrement dans les approches Lean et Kanban non prescriptives, ancrées dans la seule réalité et entièrement tournées vers le respect des personnes au travers de la qualité. Et puis, comme vous le rappelez régulièrement sur la chaîne, tout ceci ne doit jamais nous empêcher de réfléchir. Les principes et les pratiques sont le point de départ de la réflexion, pas la destination. "L'heritage, c'est ce qu'on fait du fait de ce qu'on a appris, à la sueur de notre front. Le legacy, c'est ce qu'on fait parce qu'on l'a toujours fait." - Cécile Roche, Institut Lean France. Bref, super vidéo 👍

[@esunyer]

@@ScrumLife Le hasard fait peut-être bien les choses. Je regardais (sur une autre chaine 😅) une vidéo traitant de la gestion de la complexité et voici ce que dit à un moment Marty Cagan au sujet de la product discovery, des roadmaps et des estimations : « In you’re a good product company and you’re doing product discovery, and afterwards you put what you’re building on a roadmap, that’s just a simple, useful communication tool. But, in 99 out of 100 cases or so, that’s not how the roadmaps are used. The roadmap is done instead of product discovery […] All the good product company understand the first principle ‘’Know what you can’t know’’. A roadmap in the old way is created by people who are so arrogant they don’t know what they can’t know. They think their features are going to work. They think they know how much it’s going to cost […] and they think ridiculous techniques like […] story points estimation is how you’re going to figure out what’s going to be involved in building something. That’s so amateur, and it’s time to step it up. If you’re going to help serious product companies, you need to do way better than that. » Thoughts?

[@ScrumLife]

Oui, quand on ne sait pas, on explore ! Estimer n'arrange rien. -- JP

[@nicobiot]

Bonne vidéo comme d’habitude mais j’aurais une petite remarque à la 4:05 Si le comptage des points de vélocité des US non terminées peut être écartée car l’US ne répond pas à l’objectif du sprint, on peut se poser la question légitime de « pourquoi ces US sont dans le sprint backlog ? » Doit-on dans ce cas, comme certaines équipes compter des US « bonus » ? Compter la vélocité de ces US comme des points bonus ? Merci

[@ScrumLife]

Salut ! « pourquoi ces US sont dans le sprint backlog ? » En effet c'est une question à se poser. Les réponses pouvant variées de "on pensait que c'était nécessaire, mais en fait non" à "on avait peur que toute l'équipe ne soit pas occupé 100% du temps alors on a ajouté des trucs" :) Ce qui compte, c'est de se poser la question et de se demander si c'est un comportement qu'on veut avoir. -- Constantin

[@nasreddinerachedi1254]

Très bonne vidéo, merci beaucoup!

[@ScrumLife]

Merci ! Quel élément en particulier retiens-tu de cette vidéo ? -- JP

[@OlivierFarlotti]

Très bon sujet, proche du terrain et en même temps qui rappel des fondamentaux. Bravo !

[@ScrumLife]

Merci !!! Quel moment as-tu préféré de la vidéo ? -- JP

[@OlivierFarlotti]

@@ScrumLife Quand en gros vous dîtes : on s'en fou de la vélocité ! Focus sur le sprint goal :)

[@sculderoy]

Hello Scrum Life. Super vidéo, qui sera toujours d'actualité dans 20 ans ^^ Lorsque vous parlez de vrai découpage, je pense que vous auriez pu plus préciser. Par exemple expliquer qu'un vrai découpage est un découpage vertical, avec un gain de valeur sur chacune des US :) Dans votre dernier exemple, j'essaie de retirer les termes de sprint ou d'itération mais de parler de cycles de développements. Et quand on me demande pourquoi je change de terme, j'explique que dans une approche agile on utilise l'itération pour recueillir le feedback et s'adapter, et que dans l'approche waterfall on peut utiliser des cycles de développements pour regarder l'avancement, mais que peu importe le feedback, on suivra le plan, on n'itère donc pas.

[@ScrumLife]

Merci, remarques très pertinentes ! Tu penses que dans 20 ans on sera encore à estimer en points et à faire une vélocité ? -- JP

[@hichamouazzanibouameur187]

Je pense que le scrum est toujours essentiel, même quand on a un délai déjà définie et serré pour livrer un produit complet. Le scrum nous permet de faire des revues régulières pour vérifier si on suit la bonne direction, de réévaluer et réestimer le travail restant pour déterminer si on sera dans le deadline, et de déterminer les axes d'amélioration continue pendant les rétrospectives. en tt cas c'est notre maniere travailler sur un projet assez complexe en ce moment.

[@ScrumLife]

Oui ! C'est ce qu'on illustrait normalement dans l'exemple où le développeur proposait au "métier" de collaborer ensemble pour ne pas rater l'échéance des élections. Au-delà de "penser produit" ou "penser projet", il est avant tout question de collaborer et faire front ensemble vers des enjeux métier. Comment qualifierais-tu le niveau de collaboration sur ton projet ? -- JP

[@pwisshella_inprogress]

Les vidéos sont géniales !! Merci !!

[@ScrumLife]

Merci à toi ! Laquelle t’a apporté le plus de valeur ?

[@nicolasponcet8626]

Une question souvent posée, et j'ai presque à chaque fois entendu un avis différent sur la manière de traiter ce sujet ! Merci donc d'avoir pris le temps de présenter ce qui du point de ScrumLife serait la 'bonne' manière. Il est toujours intéressant de s'appuyer sur vos vidéos et vos références pour remettre un peu d'objectivité et dépassionner les débats lorsque nous traitons ces questions qui touchent notre quotidien. PS : KZbin n'a pas accepté ici le commentaire qui décrit ce qu'a mis en place notre équipe. Je l'ai donc posté, en 3 parties, sur Linked-in 😆

[@ScrumLife]

Roooooh non dommage pour ton retour d'expérience ! 😞 On va suivre sur LinkedIn, du coup 👍 Ca t'arrive souvent d'avoir des débats houleux sur ce sujet ? -- JP

[@nicolasponcet8626]

​@@ScrumLife Oui, régulièrement, mais surtout avec des équipes qui suivent les 'points' comme une richesse à accumuler, et la vélocité comme un KPI vers l'infini et au-delà. Elles souhaitent être 'payées' en Story Points pour leurs efforts pendant le Sprint. Donc avec ce raisonnement, même une US qui n'est pas terminé mériterait son salaire en SP ... Il faut donc revenir aux fondamentaux, que les estimations ne sont pas obligatoires en Scrum et que si l'on s'en sert, c'est pour tenter de se donner une certaine capacité à se projeter dans l'avenir. Par exemple pour l'équipe, pendant le Sprint Planning, la vélocité peut leur servir de 'garde-fou'. Elle peut donner une limite théorique au nombre d'US que l'équipe peut raisonnablement prendre en compte pour atteindre le Goal. En additionnant les SP des US, dépasser cette fameuse vélocité moyenne indique que l'équipe prend peut-être le risque de ne pas terminer certaines US du Sprint et donc de ne pas atteindre le Goal. "Ne pas avoir les yeux plus gros que le ventre" 😆

[@NiokSam]

Pourquoi on parle que d'US dans la vidéo ? 😮

[@ScrumLife]

Par soucis de simplicité, mais bien sûr, c'est le même principe pour tout élément de backlog ! -- Constantin