Je suis beaucoup plus fan d'un Coût du Délai quantifié par une valeur absolue que relative, comme dis ici ! La raison est simple : en relatif, le coût des files d'attentes sont invisible, le coût des gros lots est inquantifiable, et on risque de s'intéresser plus à la vélocité qu'au fond du problème : y a des features qui nous coûtent grave de l'argent si elles sont pas mises en prod vite ! Et le pire, c'est qu'avec des idées relatives plutôt que des datas économiques et scientifiques, on risque d'avoir des priorisations fausses, plutôt liées à l'intuition de "celui qui a le plus gros salaire", ou du "PO qui n'aime pas les datas". :/ jchyip.blogspot.com/2012/12/problems-i-have-with-saf-style-wsjf.html présente bien le soucis ! Sinon, comme d'hab, super vidéo, et j'ai appris des petits trucs :)
Au top, comme toujours ! C'est parfois assez compliqué de mettre en place la Business Value. Récemment, j'ai vu les parties prenantes mettre toutes les demandes au même niveau. Ce qu'ils attendent, c'est que tous les sujets avancent en même temps. Cela crée de la tension entre les différentes personnes : - Rien ne sort car tout est en cours (Frustration des parties prenantes) - Pas de vision du produit sur le moyen terme (Frustration des développeurs) Pour que ça marche bien, il faut que tout le monde comprenne l'intérêt de ces values et participe au jeu. Pour ça, j'ai entendu parler de l'atelier Buy a feature, avec un peu de chance on aura une vidéo sur le sujet ? :D
Salut Cédric, oui je crois qu'on a l'atelier dans le backlog en tout cas c'est intéressant. Tu peux aussi montrer que se focaliser sur un sujet est plus performant avec l'atelier de l'écriture des noms d'Henry Kniberg : The Multitasking Name Game www.dropbox.com/s/kkk6frvtw03450b/Multitasking-Name-Game.pdf?dl=0 (un sujet d'une autre vidéo aussi ? ^^)
Je suis assez mitigé sur la notion de vélocité pour la business value pour 2 raisons : - elle est complètement décorrélée de l'effort à fournir donc très aléatoire entre les sprints - comme tu l'expliques, elle a tendance à tomber sur le long terme vu qu'on a déjà fourni la majeure partie de la valeur attendue du produit, donc ça peut être un peu déprimant pour l'équipe. Peut-être qu'en burn-up ce serait mieux perçu. Tu l'as bien résumé à la fin : c'est un outil hyper utile pour avoir une vision de ce qu'on fait (cette fonctionnalité a l'air quelconque mais elle est hyper attendue), mais pas une finalité en soit. Merci pour cet épisode encore une fois très intéressant.
J'aime bien l'idée de remplacer les story point (l'effort) par la business value. Je trouve que ça complète le #NoEstimate dont tu as déjà parlé précédemment. Le business poker semble intéressant toujours dans l'idée de prioriser en comparant des pommes et des fraises :)
@@ScrumLife oui ça avance je viens justement d'avoir la possibilité d'organiser un point avec mes parties prenantes pour échanger sur leurs Business Value et team value, NPS.. cela les intéresse beaucoup. Je leur ai indiqué que c'était pour prioriser, direct j'ai eu des retours
Sujet très intéressant. Pour rebondir sur la partie du biais de la business value, je dirais intuitivement que dans les cas des "points" business, le référentiel a tendance à évoluer au cours du développement d'un produit (contrairement aux points d'effort qui eux dépendent de l'équipe). C'est à dire que si la valeur business semble diminuer, c'est peut être aussi qu'on l'analyse toujours par rapport au contexte du début du projet, alors que celui ci a potentiellement beaucoup changé (maturité des utilisateurs, taille du marché, etc.). De mon côté, a chaque fois que je parle de business value j'essaye d'associer des indicateurs mesurables pour éviter ça. Mais je n'avais jamais envisagé utiliser des points, à tester.
En effet Cym0ril, il ne faut pas comparer la valeur par rapport au référentiel initial mais bien le réévaluer relativement. Par contre, les points d'efforts aussi évoluent. Par exemple, quelque chose évalué à "13 points d'effort" l'est par rapport au produit actuel. Demain ça peut devenir 3 pts, parce qu'on aura ajouté quelque chose facilitant l'implémentation, ou au contraire, ça peut devenir 30 pts car le produit actuel rend ça beaucoup plus difficile. Qu'en dis-tu ? -- Constantin
Toujours super ces vidéos. Un grand merci. :) C'est aussi un outil qui permet de donner de la satisfaction à l'équipe. Elle voit ce qui est important. Elle se focalise dessus. Et effectivement, elle améliore ses échanges et sa façon de traiter les sujets. Concernant l'exploitation de la BV, faire des BurnUp, je l'évite pour les raisons évoquées dans la vidéo. C'est un outil, et ça reste à utiliser s'il y a un besoin réel ou si cela peut aider l'équipe. Encore un fois, si la BV ne sont pas correctement utilisés, ça peut également être une perte de temps et d'investissement pour l'équipe.
Excellent cette vidéo qui tombe juste après un atelier sur la Business Value que nous avons fait chez nous. Ce qui me rassure, c'est que ce qu'il est ressorti de cet atelier correspond globalement à ce qui est dit dans cette vidéo. Il y a toutefois 2 points sur lesquels nous avions quelques doutes, sur lesquels nous nous sommes faits notre avis, mais il est toujours intéressant de recueillir des points de vue différents : - Comment doit-on composer la Business Value, doit-elle être une valeur simple (poker planning tel qu'évoqué dans la vidéo), ou bien une valeur composée d'indicateurs très précis (CA généré par la fonctionnalité + valeur d'impact pour l'image de marque + gain de temps pour l'utilisateur + € gagnés par le client grâce à la nouvelle fonctionnalité) ? - Est-il possible de l'utiliser à l'échelle de l'entreprise ? C'est à dire pouvoir comparer les business value de différents produits pour définir la stratégie d'entreprise, savoir sur quel produit/équipe l'entreprise a-t'elle tout intérêt à miser.
Concernant ta première question, je pense qu'il n'y a pas de vrai réponse. Il faut se poser la question sur les critères qui comptent le plus pour vous. Si vous avez la possibilité d'utiliser des KPI business (ce qui est souvent complexe) et que ça a une cohérence pour vous : faites. Si vous pensez que ça n'apporte pas grand chose et que vous préférez parler en relatif: faites. Dans tous les cas, il faut tester et ne pas hésitez à remettre en question vos décisions. Peut-on le faire à l'échelle de l'entreprise, encore une fois il faut se poser la question : est-ce que l'indicateur est parlant pour toute l'entreprise ? Dans ce cas, pourquoi pas. Mais est-ce probant de mettre tous les projets au même niveau ? Encore une fois c'est à vous de vous poser la question. Une astuce de Jimmy Janlén que j'aime beaucoup : Quand vous mettez en place une règle, mettez une date de péremption dessus. Quand la date est atteinte posez la règle sur le tapie et demandez vous s'il faut la garder, la changer ou la supprimer.
@@cedricn6235 Merci pour ta réponse. A vrai dire, je m'attendais à avoir des avis plus tranchés, mais ce que tu dis est tout à fait juste. Je complète donc les 2 points que j'évoque par rapport à notre cas précis : - Sur la construction et l'analyse de ce genre d'indicateurs, on passe souvent beaucoup de temps, ils ne sont pas toujours justes, il faut donc les adapter. Si le mode de construction de ces indicateurs évolue sans cesse, on n'est donc plus capable de les comparer dans le temps. Une estimation relative reste très simple et beaucoup plus rapide à mettre en place. - Concernant la mise à l'échelle, cela ne me semble pas pertinent, en tout cas dans notre cas précis, surtout si l'on parle en estimations relatives. Nous avons plusieurs produits, destinés à des panels d'utilisateurs très différents, des équipes produisant de la data, des APIs, des apps mobiles... Cela me semble très compliqué de comparer tout ça. Selon moi, c'est plutôt la stratégie d'entreprise et la vision des dirigeants qui doit déterminer où l'accent doit être mis en termes de moyen pour délivrer de la valeur et non l'inverse. En tout cas, ton dernier conseil est très intéressant, et je le garde en tête.
Désolé de ne pas avoir de réponse plus tranché à te donner. Si tu as la possibilité d’avoir la valeur qu’une Us va apporter en terme business (Ventes estimées, audience, ...) et que ça ne coûte pas de l’estimer, dans ce cas c’est plus concret pour comparer. Attention de ne pas tomber dans le piège de passer trop de temps à estimer cela aussi. Après, tu parle de comparer dans le temps ? Généralement on compare les choses pour prendre une décision à instant T. Quels sont les buts de comparer dans le temps dans votre contexte ? Je sais encore une question :D
Découvrez toute la communauté Scrum Life ! 👉 sl.run/EfMJmw
Je suis beaucoup plus fan d'un Coût du Délai quantifié par une valeur absolue que relative, comme dis ici !
La raison est simple : en relatif, le coût des files d'attentes sont invisible, le coût des gros lots est inquantifiable, et on risque de s'intéresser plus à la vélocité qu'au fond du problème : y a des features qui nous coûtent grave de l'argent si elles sont pas mises en prod vite ! Et le pire, c'est qu'avec des idées relatives plutôt que des datas économiques et scientifiques, on risque d'avoir des priorisations fausses, plutôt liées à l'intuition de "celui qui a le plus gros salaire", ou du "PO qui n'aime pas les datas". :/
jchyip.blogspot.com/2012/12/problems-i-have-with-saf-style-wsjf.html présente bien le soucis !
Sinon, comme d'hab, super vidéo, et j'ai appris des petits trucs :)
Au top, comme toujours !
C'est parfois assez compliqué de mettre en place la Business Value. Récemment, j'ai vu les parties prenantes mettre toutes les demandes au même niveau. Ce qu'ils attendent, c'est que tous les sujets avancent en même temps.
Cela crée de la tension entre les différentes personnes :
- Rien ne sort car tout est en cours (Frustration des parties prenantes)
- Pas de vision du produit sur le moyen terme (Frustration des développeurs)
Pour que ça marche bien, il faut que tout le monde comprenne l'intérêt de ces values et participe au jeu. Pour ça, j'ai entendu parler de l'atelier Buy a feature, avec un peu de chance on aura une vidéo sur le sujet ? :D
Salut Cédric, oui je crois qu'on a l'atelier dans le backlog en tout cas c'est intéressant.
Tu peux aussi montrer que se focaliser sur un sujet est plus performant avec l'atelier de l'écriture des noms d'Henry Kniberg : The Multitasking Name Game www.dropbox.com/s/kkk6frvtw03450b/Multitasking-Name-Game.pdf?dl=0 (un sujet d'une autre vidéo aussi ? ^^)
Je suis assez mitigé sur la notion de vélocité pour la business value pour 2 raisons :
- elle est complètement décorrélée de l'effort à fournir donc très aléatoire entre les sprints
- comme tu l'expliques, elle a tendance à tomber sur le long terme vu qu'on a déjà fourni la majeure partie de la valeur attendue du produit, donc ça peut être un peu déprimant pour l'équipe. Peut-être qu'en burn-up ce serait mieux perçu.
Tu l'as bien résumé à la fin : c'est un outil hyper utile pour avoir une vision de ce qu'on fait (cette fonctionnalité a l'air quelconque mais elle est hyper attendue), mais pas une finalité en soit.
Merci pour cet épisode encore une fois très intéressant.
Bonjour Jean Pierre, idéalement qui mesure/evalue la business value, la scrum team, les parties prenantes, les client...?
Merci
I have written a formal process for that on my thesis. You are on those acknoledgments, by the way!! Merci Beacoup pour votre aide!!!
J'aime bien l'idée de remplacer les story point (l'effort) par la business value. Je trouve que ça complète le #NoEstimate dont tu as déjà parlé précédemment. Le business poker semble intéressant toujours dans l'idée de prioriser en comparant des pommes et des fraises :)
Juste merci 👍 c'est exactement comme ça que je vois les choses sur la BV
Tant mieux Pierre-Yves !
Tu arrives à la concrétiser de la sorte dans ton travail ?
-- Constantin
@@ScrumLife oui ça avance je viens justement d'avoir la possibilité d'organiser un point avec mes parties prenantes pour échanger sur leurs Business Value et team value, NPS.. cela les intéresse beaucoup. Je leur ai indiqué que c'était pour prioriser, direct j'ai eu des retours
@@pysordes Formidable ! Tiens nous au courant de ce que ça aura eu comme impact :)
-- Constantin
Sujet très intéressant.
Pour rebondir sur la partie du biais de la business value, je dirais intuitivement que dans les cas des "points" business, le référentiel a tendance à évoluer au cours du développement d'un produit (contrairement aux points d'effort qui eux dépendent de l'équipe). C'est à dire que si la valeur business semble diminuer, c'est peut être aussi qu'on l'analyse toujours par rapport au contexte du début du projet, alors que celui ci a potentiellement beaucoup changé (maturité des utilisateurs, taille du marché, etc.).
De mon côté, a chaque fois que je parle de business value j'essaye d'associer des indicateurs mesurables pour éviter ça. Mais je n'avais jamais envisagé utiliser des points, à tester.
En effet Cym0ril, il ne faut pas comparer la valeur par rapport au référentiel initial mais bien le réévaluer relativement.
Par contre, les points d'efforts aussi évoluent. Par exemple, quelque chose évalué à "13 points d'effort" l'est par rapport au produit actuel. Demain ça peut devenir 3 pts, parce qu'on aura ajouté quelque chose facilitant l'implémentation, ou au contraire, ça peut devenir 30 pts car le produit actuel rend ça beaucoup plus difficile.
Qu'en dis-tu ?
-- Constantin
Toujours super ces vidéos. Un grand merci. :) C'est aussi un outil qui permet de donner de la satisfaction à l'équipe. Elle voit ce qui est important. Elle se focalise dessus. Et effectivement, elle améliore ses échanges et sa façon de traiter les sujets.
Concernant l'exploitation de la BV, faire des BurnUp, je l'évite pour les raisons évoquées dans la vidéo. C'est un outil, et ça reste à utiliser s'il y a un besoin réel ou si cela peut aider l'équipe.
Encore un fois, si la BV ne sont pas correctement utilisés, ça peut également être une perte de temps et d'investissement pour l'équipe.
Oui ! Merci pour tes retours d'expérience qui rejoignent les nôtres.
Je découvre et j'adore ! 👍Merci
merci :)
Super video. J'ai kiffé.
Quel était ton moment préféré ?
Excellent cette vidéo qui tombe juste après un atelier sur la Business Value que nous avons fait chez nous. Ce qui me rassure, c'est que ce qu'il est ressorti de cet atelier correspond globalement à ce qui est dit dans cette vidéo.
Il y a toutefois 2 points sur lesquels nous avions quelques doutes, sur lesquels nous nous sommes faits notre avis, mais il est toujours intéressant de recueillir des points de vue différents :
- Comment doit-on composer la Business Value, doit-elle être une valeur simple (poker planning tel qu'évoqué dans la vidéo), ou bien une valeur composée d'indicateurs très précis (CA généré par la fonctionnalité + valeur d'impact pour l'image de marque + gain de temps pour l'utilisateur + € gagnés par le client grâce à la nouvelle fonctionnalité) ?
- Est-il possible de l'utiliser à l'échelle de l'entreprise ? C'est à dire pouvoir comparer les business value de différents produits pour définir la stratégie d'entreprise, savoir sur quel produit/équipe l'entreprise a-t'elle tout intérêt à miser.
Concernant ta première question, je pense qu'il n'y a pas de vrai réponse. Il faut se poser la question sur les critères qui comptent le plus pour vous. Si vous avez la possibilité d'utiliser des KPI business (ce qui est souvent complexe) et que ça a une cohérence pour vous : faites. Si vous pensez que ça n'apporte pas grand chose et que vous préférez parler en relatif: faites. Dans tous les cas, il faut tester et ne pas hésitez à remettre en question vos décisions.
Peut-on le faire à l'échelle de l'entreprise, encore une fois il faut se poser la question : est-ce que l'indicateur est parlant pour toute l'entreprise ? Dans ce cas, pourquoi pas. Mais est-ce probant de mettre tous les projets au même niveau ? Encore une fois c'est à vous de vous poser la question.
Une astuce de Jimmy Janlén que j'aime beaucoup : Quand vous mettez en place une règle, mettez une date de péremption dessus. Quand la date est atteinte posez la règle sur le tapie et demandez vous s'il faut la garder, la changer ou la supprimer.
@@cedricn6235 Merci pour ta réponse. A vrai dire, je m'attendais à avoir des avis plus tranchés, mais ce que tu dis est tout à fait juste.
Je complète donc les 2 points que j'évoque par rapport à notre cas précis :
- Sur la construction et l'analyse de ce genre d'indicateurs, on passe souvent beaucoup de temps, ils ne sont pas toujours justes, il faut donc les adapter. Si le mode de construction de ces indicateurs évolue sans cesse, on n'est donc plus capable de les comparer dans le temps. Une estimation relative reste très simple et beaucoup plus rapide à mettre en place.
- Concernant la mise à l'échelle, cela ne me semble pas pertinent, en tout cas dans notre cas précis, surtout si l'on parle en estimations relatives. Nous avons plusieurs produits, destinés à des panels d'utilisateurs très différents, des équipes produisant de la data, des APIs, des apps mobiles... Cela me semble très compliqué de comparer tout ça. Selon moi, c'est plutôt la stratégie d'entreprise et la vision des dirigeants qui doit déterminer où l'accent doit être mis en termes de moyen pour délivrer de la valeur et non l'inverse.
En tout cas, ton dernier conseil est très intéressant, et je le garde en tête.
Désolé de ne pas avoir de réponse plus tranché à te donner.
Si tu as la possibilité d’avoir la valeur qu’une Us va apporter en terme business (Ventes estimées, audience, ...) et que ça ne coûte pas de l’estimer, dans ce cas c’est plus concret pour comparer.
Attention de ne pas tomber dans le piège de passer trop de temps à estimer cela aussi.
Après, tu parle de comparer dans le temps ? Généralement on compare les choses pour prendre une décision à instant T. Quels sont les buts de comparer dans le temps dans votre contexte ?
Je sais encore une question :D