Sprint Goal, Product Goal : l'interview Scrum Life de Maarten Dalmijn

🎁 Le guide du Scrum Master compétent 👉 sl.run/vqZMcM
Trop contents d'enfin recevoir Maarten Dalmijn sur Scrum Life ! C'est bien entendu l'occasion de parler de son livre sur les Sprint Goals. Sympa aussi de faire ensemble un petit état des lieux du marché de l'utilisation des Sprint Goals et des Product Goals 😊 #ScrumLife #Interview #MaartenDalmijn
💜️ Rejoins la communauté Scrum Life 👉 sl.run/5vCK1e (c'est gratuit !)
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
Lien affilié pour acheter le livre “Driving Value with Sprint Goals: Humble Plans, Exceptional Results” de Maarten Dalmijn : amzn.to/3PzbiLQ
----------
SOMMAIRE️
00:00 Sprint Goals : est-ce suffisant ?
00:53 Présentation de Maarten Dalmijn
01:34 Pourquoi crée-t-on une équipe ?
03:14 Etat des lieux des pratiques d'équipe
06:13 L'impact de borner dans le temps
09:08 Le message de Maarten

[@ScrumLife]

Tu as aimé cet échange avec Maarten ? Une autre vidéo de notre interview est à venir, abonne-toi pour ne pas rater ça !! On parlera de comment bien impliquer les parties prenantes 🤩 Abonne-toi !

[@LoicDubart]

Merci pour l'interview. C'est un sujet très intéressant. Selon moi le product goal est un état précis de création de valeur que l'on ne sait pas exactement quand on va l'atteindre et donc je trouve sain qu'il ne soit pas timeboxé. Les OKRs en revanche permettent d'avancer à un rythme défini et ambitieux vers ce goal et après chaque itération d'okr on peut les ajuster et donc se rapprocher d'un product goal. Le dernier OKR est alors le product goal lui même

[@lionelpayan8378]

Avec cet interview, cela m'a permis de faire le lien avec un précédent meetup sur comment créer un board numérique d'équipe VRAIMENT utile. J'ai mon précédent client, la vraie problématique était d'identifier le ou les produits sur lesquels travaillaient les équipes de développement. Cela n'était pas évident car par exe les équipes de back offices utilisaient un outil de gestion qui contenaient une multitude de fonctionnalités. Alors est-ce que le produit c'est cet outil ou bien chaque fonctionnalité est un produit en soi ? Réflexion importante pour définir ensuite les objectifs produit à atteindre avec le travail des équipes de développement. Autre exemple: j'étais PO sur un projet de migration de l'ancien SI vers le nouveau SI pour comptabiliser le paiement des prestations. Pour cela, l'équipe devait créer un fichier avec des écritures comptables, qui est intégré dans un progiciel comptable, à partir des résultats de paie et des référentiels comptables. Le produit pour moi était ce fichier car il répond bien aux besoins de la Direction Comptable et l'objectif produit est que toutes les prestations payées soient bien comptabilisées sur les bons comptes avec le libellé correspondant dans le fichier produit.. Pourtant, chaque référentiel comptable pouvaient aussi être considéré comme un produit puisque l'équipe de développement les a créé pour ensuite générer le fichier des écritures comptables. Dans ce cas, il aurait fallu identifier le ou les objectifs produit. Et l'équipe de développement aurait dans ce cas plusieurs objectifs produit pour mon projet. Qu'en pensez-vous ?