Product Owner : c'est quoi ?

[@ScrumLife]

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

[@snoussithamer8350]

😘🥰😍😘😘😘😘😘😘😘😘😘😘😘😘😭😘😭😘😘😭😘😭😘😘😭

[@snoussithamer8350]

😘😭😘

[@snoussithamer8350]

😭😘🥰😘🥰😘😭

[@snoussithamer8350]

🥰

[@PierreLebailly]

Très riche et très efficace ! Et tellement vrai. Merci

[@ScrumLife]

Merci Pierre, retires-tu des astuces de la vidéo ? Des choses applicables pour toi ?

[@johannharguindeguy4940]

Trop bien votre vidéo Scrumlife. Là où connaître le rôle du PO devient une vision produit ou bien plus une ambition d'orientation professionnelle (on va dire : par itération). Le rôle de facilitateur est complété à présent dans ce qui m'inspirait et j'aime.😊 A moi de jouer pour approcher le savoir marketing et gagner la casquette po en objectif vision produit ❤.

[@ScrumLife]

Merci pour ton enthousiasme @johannharguindeguy4940 ! 😊 Je suis ravi que notre vidéo t'ait inspiré et éclairé sur le rôle du Product Owner. 💡 C'est effectivement un rôle passionnant et crucial pour la vision produit et l'orientation professionnelle. N'hésite pas à partager tes prochaines étapes ou tes questions, ça pourrait intéresser d'autres membres de notre communauté ! Comment penses-tu aborder l'aspect marketing dans ton parcours vers la casquette de PO ? 🎯 À bientôt, Robin 🚀

[@mariannebeglin6590]

Un épisode hyper riche, beau boulot!

[@ScrumLife]

Merci pour ta présence au Live !

[@nixquev]

J'adore, merci encore. J'met un pouce vers le haut même s'il est pas bleu

[@ScrumLife]

Il est pas bleu chez toi ? ^^

[@nixquev]

@@ScrumLife sûrement un truc de AB testing, moi c'est pure noir et blanc.

[@yvesthiery4733]

👍

[@cvts5973]

Bonjour, merci pour vos vidéos éclairantes. Je suis engagé depuis 1 an dans une transformation scrum dans un rôle de Business Analyst. Judte svznt, j'ai œuvré comme MOA dans le même domaine, donc côté utilisateur. Je vous remercie pour la distinction entre PO et PM. Mais cependant, j'ai beaucoup de mal avec le flou du rôle de PO: il me paraît être de partout à la fois, empiète sur le Scrum Master, dit l'équipe dev et s'apparente parfois a un manager avec tous les mauvais côtés. Surtout comment accepter qu'il intervienne sur la solution ou sur les relations au sein de l'équipe dev ? Est-il incongrue de laisser les BA animer l'affinage et laisser le PO s'occuper des sprint Planning et sprint Reviews ? Merci pour vos conseils

[@cvts5973]

@@jeromesteinerdelfingen Bonjour, un très grand merci pour votre réponse. Rien ne me surprend dans ce que vous évoquez et vos suggestions me paraissent très adaptées à la situation. Ceci tranche clairement dans la vision divergente que nous avons de ces rôles. On m'a opposé par exemple qu'il est demandé au PO de "suivre l'avancement" : je trouve ceci anti-scrum ! Effectivement, je suis BA, ce n'est pas défini, et à la base ce rôle proviens de mon ancien poste de CPU (chef de projet utilisateur) donc plutôt expert métier. Cependant le périmètre de la squad est technique et nous fournissons des services aux autres squads. Cependant, le positionnement avec le PO fait conflit et effectivement le scrum master ne s'affirme pas et ne régule pas l'équipe.

[@ScrumLife]

@@cvts5973 Ce que tu décris là est quelque chose que je vois assez souvent. Le rôle du BA est souvent difficile à intégrer, mais c'est possible. Typiquement, c'est un rôle qui va venir épauler le PO et même le former. Comme nous le disons dans la vidéo, le PO doit pouvoir prendre des décisions stratégiques, mais pas n'importe comment. Le ou la BA peut lui fournir des éléments et des outils pour l'aider à cette décision. Il ou elle peut participer à la définition de la solution en planning par exemple et aider l'équipe à définir ce qui sera mesurer et comment pour savoir si la solution convient bien. C'est très important car comment nous allons mesurer quelque chose peut avoir un fort impact sur les développements (sondes à implémenter, etc.) comme nous l'expliquions dans cette vidéo : kzbin.info/www/bejne/rXWYiJiAbN2Xm5o -- Constantin

[@JulienReszka]

Vous parlez d'itérations comme si c'était une bonne chose mais mon expérience me dit que il faut au contraire viser le MOINS d'itérations possibles car ça entraine des surcouts monstrueux. Il faut prévoir tous les user flows et leurs dépendances et idéalement réussir à tout développer du premier coup, SANS itérations.

[@ScrumLife]

Merci Julien pour ton commentaire. Dans mon expérience au sein de grandes entreprises (très grandes) ou de startup, il n'est jamais arrivé qu'une équipe développe tous les bons "user flows et leurs dépendances" du premier coup. Même en faisant pleins de recherches utilisateurs, etc (ça prend du temps et ça coute cher, il faut le compter dans le budget), même en écoutant et en comprenant parfaitement ce que demandent les utilisateurs, le résultat n'est pas satisfaisant. Une fois le produit entre les mains, l'utilisateur n'est pas satisfait, même si c'est ce qu'il a demandé, car il se rend compte que ce n'est pas très pratique ou bien ce n'est plus adapté, car son besoin à évoluer. Donc si on attend d'avoir tout fait en itérant moins, et qu'on s'est trompé (comme bien souvent dans ce que j'ai pu voir), et qu'on doit refaire énormément de choses, est-ce qu'à ton avis on a vraiment éviter un surcoût ? Le danger est de croire qu'on l'a évité car on a pas demandé leur avis aux utilisateurs et que donc, on se cache la vérité. Dans ton expérience, comment vérifies-tu que ce que tu livres a bien apporté de la valeur à tes clients ? Et à leurs utilisateurs (c'est parfois différent ^^) ? -- Constantin

[@jissedelavega2653]

Je suis PO, personne ne m'a jamais dit que c'était classe... Menteurs! Tartuffes!

[@COACHAGILE]

C’est trop la claaasssssse !

[@jissedelavega2653]

@@COACHAGILE Mon dieu, ma vie s'en voit boulversifiée, merci Coach Agile!