Guide de mêlée | 12. Coopération entre Product Owner et Scrum Master

Publié: 2022-04-22

Dans l'article d'aujourd'hui, nous aborderons le sujet de la coopération entre Product Owner et Scrum Master. Le Product Owner soumet un objectif de produit clairement défini à l'équipe de développement et exige des progrès dans sa mise en œuvre. Le Scrum Master veille à la qualité du processus de sa création : bonne ambiance accompagnant le travail de l'équipe, motivation et levée des obstacles. Cependant, le Product Owner et le Scrum Master ne sont pas deux forces indépendantes agissant au sein de l'équipe de développement.

Coopération entre Product Owner et Scrum Master – table des matières

  1. Scrum Master & Product Owner
  2. Soutenir une communication efficace avec les développeurs
  3. Connaissance de l'expérience
  4. Présentation des parties prenantes dans Scrum
  5. Sommaire
cooperation between Product Owner and Scrum Master

Scrum Master & Product Owner

Bien que la façon dont chacun d'eux travaille soit très différente, leurs intérêts convergent : il s'agit pour l'équipe Scrum de travailler efficacement. C'est pourquoi la relation entre Scrum Master et Product Owner, et leur collaboration efficace, est si importante.

La plupart des tâches du Product Owner et du Scrum Master – que nous avons décrites plus en détail dans des articles séparés – tournent autour de leurs responsabilités liées au travail de l'équipe de développement. Cependant, les devoirs et responsabilités du Scrum Master incluent également le soutien au travail du Product Owner.

Soutenir une communication efficace avec les développeurs

Une communication efficace entre le Product Owner et l'équipe de développement nécessite au moins deux fondamentaux solides : la compréhensibilité et un impact suffisant. Le Scrum Master aide le Product Owner à les renforcer.

Comprendre le carnet de produit

L'une des principales façons dont le Scrum Master aide le Product Owner est de s'assurer que les messages formulés sont compris par l'équipe de développement. Le Scrum Master examine les entrées du Product Backlog et pose des questions supplémentaires pour améliorer leur clarté en prêtant attention principalement à :

  • clarté des entrées - afin que les développeurs sachent exactement dans quel but ils développent une fonctionnalité donnée
  • garder les entrées concises - de sorte que les descriptions des fonctionnalités prévues n'incluent que les informations nécessaires et qu'il faille le moins de temps possible pour les lire

De cette manière, le Scrum Master évite qu'un décalage n'apparaisse entre le Product Goal, tel que le Product Owner l'imagine, et la manière dont les membres de l'équipe de développement ont compris leur tâche.

Le pouvoir d'influence du Product Owner

Scrum Master aide le Product Owner à améliorer l'efficacité et le charisme des messages. Le Scrum Master agit comme un coach avec lequel le Product Owner peut discuter des problématiques concernant le Produit et sa réalisation. C'est pourquoi les rencontres individuelles au cours desquelles des échanges ont lieu entre eux sont si importantes. Grâce à ces échanges, le Product Owner peut clarifier la vision du produit et répondre aux questions du Scrum Master avant de la présenter à l'équipe.

Le Scrum Master, en donnant du feedback, rend le message du Product Owner lors d'une réunion avec l'équipe plus fort et plus clair. Cette préparation nécessaire aide le Product Owner à communiquer de mieux en mieux l'Objectif Produit lors des Scrum Events, que nous décrivons dans un article séparé.

Product Owner and Scrum Master

Connaissance de l'expérience

Le Scrum Master aide également le Product Owner à planifier de manière réaliste les tâches de l'équipe de développement. Il peut arriver qu'un Product Backlog bien préparé ne corresponde pas à la manière de travailler de l'organisation dans laquelle l'Objectif Produit doit être réalisé.

Le Scrum Master va donc accompagner le Product Owner avec un savoir d'expérience en le puisant dans le constat d'échecs et de difficultés survenus lors de projets antérieurs. Grâce aux connaissances empiriques, Scrum Master peut prévoir les difficultés d'exécution des tâches et d'atteinte du Product Goal qui résultent des spécificités de l'organisation, de l'équipe ou de sa spécialisation.

Présentation des parties prenantes dans Scrum

Le Scrum Master travaille quotidiennement principalement avec l'équipe de développement. Et parfois aussi avec le service RH, notamment lors du processus de team building et dans ces rares moments où l'équipe a besoin d'être élargie ou changée. Les tâches quotidiennes du Scrum Master n'incluent généralement pas la coopération des parties prenantes - c'est le travail du Product Owner.

L'exception est lorsque vous commencez à travailler avec des parties prenantes qui ne sont pas familiarisées avec les principes et les rôles de Scrum. C'est à ce moment que les Scrum Masters travaillent avec le Product Owner lors de réunions avec toutes les personnes impliquées dans la création du Produit. Ils expliquent qui est qui dans l'équipe Scrum, dont nous avons parlé dans un article séparé. Ils aident également le Product Owner à mettre en place de bonnes pratiques de communication. Celles-ci incluent, par exemple, la présence active des parties prenantes lors de la revue de sprint ou la création de bonnes histoires d'utilisateurs.

Sommaire

Le Scrum Master permet au Product Owner de se concentrer sur son travail : sur la maximisation de la valeur métier du produit en cours de création. Le Scrum Master aide également le Product Owner à communiquer efficacement grâce à un coaching individuel et à des discussions sur la forme du Product Backlog. De plus, le Scrum Master soutient le Product Owner avec sa connaissance du travail avec une équipe et une organisation spécifiques. Et enfin – si nécessaire – facilite le Product Owner en initiant les Stakeholders à la méthode de travail Scrum.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube.

Scrum Guide | 12. Cooperation between Product Owner and Scrum Master caroline becker avatar 1background

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Guide de mêlée :

  1. Glossaire des termes, rôles et notions de base
  2. Qu'est-ce que Scrum ?
  3. Valeurs Scrum
  4. Comment implémenter Scrum dans votre entreprise ?
  5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
  6. Qui est un Product Owner ?
  7. Les erreurs les plus courantes du Product Owner
  8. Qui est le Scrum Master ?
  9. Caractéristiques d'un bon Scrum Master
  10. Les erreurs les plus courantes du Scrum Master
  11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
  12. Coopération entre Product Owner et Scrum Master
  13. Équipe de développement dans Scrum
  14. Les erreurs les plus courantes des développeurs
  15. Artefacts Scrum
  16. Mise à l'échelle Scrum
  17. Carnet de sprint
  18. Qu'est-ce que le carnet de produit ?
  19. Qu'est-ce qu'une User Story ?
  20. Créer la meilleure User Story avec INVEST
  21. Les erreurs les plus courantes de la User Story
  22. Critères d'acceptation des user stories
  23. Estimation et Story Points dans Scrum
  24. Planification Poker
  25. Jeu d'estimation d'équipe
  26. Définition de l'incrément
  27. Événements Scrum
  28. Qu'est-ce que Sprint dans Scrum ?
  29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
  30. Qu'est-ce qu'un Burndown Chart ?
  31. Comment créer et interpréter un burndown chart ?
  32. Avantages et inconvénients du burndown chart
  33. Tableaux Kanban dans Scrum et Scrumban
  34. Velocity in Scrum - Vitesse de l'équipe de développement
  35. Mêlée quotidienne
  36. Planification des sprints
  37. Revue de sprint
  38. Qu'est-ce qu'une rétrospective Sprint ?
  39. Erreurs courantes lors d'une rétrospective de sprint
  40. Nourrir le backlog produit