Dans une organisation agile, quel est le rôle exact du Product Owner ? Est-ce un chef de projet 2.0 ? Avec ce livre, l’auteur propose au lecteur de répondre à ces interrogations en décrivant ce métier de manière pragmatique. Il intéressera aussi bien les personnes souhaitant passer à l’agilité et devenir Product Owner que les Product Owners ou managers désireux de gérer plus efficacement le développement de leurs produits.

Au fil des chapitres, le lecteur découvre ainsi comment ce véritable chef d'orchestre peut élaborer une vision du produit ainsi qu’une méthode permettant de définir une stratégie et un plan opérationnel faisant sens et nourrissant la motivation de tous les acteurs d’une équipe agile.

La gestion du Backlog de produit est détaillée pour permettre d'en saisir les enjeux afin de s'adapter à un environnement évolutif tout en communiquant mieux grâce à des outils et des méthodes modernes.

Enfin, un chapitre entier est dédié aux principales approches permettant au Product Owner de coordonner les efforts d'une ou plusieurs équipes. Scrum à l’échelle ou SAFe, les enjeux et implications de ces approches sont également décrits précisément afin d’être en mesure d’évoluer sereinement en tant que Product Owner dans différents types d’organisations.

Téléchargements

• Des fichiers complémentaires (3 589 Ko)

Le patron Scrum

1. Les fondamentaux de Scrum
   1. 1. Introduction
      1. a. Définition de Scrum
      2. b. Théorie de Scrum
   2. 2. L’empirisme
   3. 3. La pensée Lean
      1. a. Le modèle Shingo
      2. b. Le modèle 3MU
      3. c. Le modèle TIMWOOD(T)
   4. 4. Les rôles Scrum
      1. a. Les Developers
      2. b. Le Product Owner
      3. c. Le Scrum Master
      4. d. Les parties prenantes
      5. e. Un mot sur les managers
   5. 5. Les évènements Scrum
      1. a. Le Sprint
      2. b. La planification de Sprint
      3. c. L’objectif du Sprint
      4. d. L’annulation du Sprint
      5. e. Le Daily Scrum ou mêlée
      6. f. La revue de Sprint
      7. g. La rétrospective de Sprint
      8. h. L’affinage du Backlog de produit
   6. 6. Les artefacts Scrum
      1. a. Le Backlog de produit
      2. b. Transparence du Backlog de produit
      3. c. Le Backlog de Sprint
      4. d. Transparence du Backlog de Sprint
      5. e. L’incrément
      6. f. Transparence et engagement de l’increment :la définition de « Fini »
   7. 7. Les piliers de Scrum
      1. a. Transparence
      2. b. Inspection
      3. c. Adaptation
   8. 8. Les valeurs de Scrum
      1. a. Focus
      2. b. Ouverture
      3. c. Respect
      4. d. Courage
      5. e. Engagement
   9. 9. Approfondir Scrum
2. Du projet au produit
   1. 1. Focus sur le produit
   2. 2. Le cycle itératif
   3. 3. Fin du diagramme de Gantt
   4. 4. La notion de valeur du produit
      1. a. Impact de la valeur sur l’organisation
      2. b. Calcul de la valeur

Le métier de Product Owner

1. Focus sur le rôle de Product Owner
   1. 1. Le Product Owner n’est pas un chef de projet
      1. a. La responsabilité du Product Owner
      2. b. De la vision projet à la vision produit
      3. c. Les outils du Product Owner
   2. 2. Le Product Owner est un intrapreneur
      1. a. Le pouvoir du Product Owner
      2. b. Les limites du Product Owner
   3. 3. Un manager atypique
      1. a. La clarté des objectifs
      2. b. L’ambiance au sein de l’équipe
      3. c. La communication avec l’équipe
   4. 4. Le positionnement du Product Owner dans l’organisation
   5. 5. Le pilotage par la valeur
2. Focus sur le Backlog de produit
   1. 1. Définition du terme backlog
      1. a. Étymologie
      2. b. Du point de vue de Scrum
   2. 2. Une triple fonction
      1. a. Un outil de planification
      2. b. Un outil d’organisation
      3. c. Un outil de communication
   3. 3. Le Backlog, un répertoire unique
      1. a. Le Backlog de produit est vivant
      2. b. La durée de vie d’un Backlog de produit
      3. c. Propriété du Backlog de produit
      4. d. Pas de multiples Backlogs
      5. e. Un Backlog d’une taille gérable
   4. 4. Un ordonnancement plus qu’une priorisation
      1. a. Organiser en fonction de la valeur
      2. b. Organiser dans le temps
      3. c. Affiner à mesure
3. Les éléments du Backlog de produit
   1. 1. Les attributs des éléments
      1. a. Les attributs essentiels
      2. b. Les attributs récurrents
      3. c. Utiliser d’autres attributs
   2. 2. Focus sur les attributs essentiels
      1. a. Indicateur numérique
      2. b. Une description
      3. c. Une estimation
      4. d. Une valeur
      5. e. Un état
      6. f. Affecter d’autres attributs
   3. 3. Créer des catégories
   4. 4. Maintenir une traçabilité
   5. 5. Lien fort ou lien faible
4. Focus sur la définition de « Fini »
   1. 1. Définition du guide Scrum
      1. a. La définition de « Fini » estrédigée par les Developers
      2. b. Elle s’applique au produit et à ses composants
   2. 2. Les vertus d’une définition de « Fini » claire
      1. a. Les contraintes liées au produit
      2. b. La définition de « Fini » impactela capacité à délivrer
      3. c. La définition de « Fini » clarifiele cadrage du produit
      4. d. La définition de « Fini » évolue
      5. e. Les évolutions de la définitionde « Fini » se planifient
   3. 3. L’impact de la définition de « Fini » dela qualité logicielle
      1. a. La qualité logicielle, un enjeu historique
      2. b. L’impact d’une définition de « Fini » incomplèteest d’ordre financier
      3. c. L’agilité n’a pas permis de réduiresignificativement les coûts
   4. 4. L’implication du Product Owner dans la définitionde « Fini »
      1. a. Des critères d’acceptation à ladéfinition de « Fini »
   5. 5. Convaincre les parties prenantes d’adopter une définition de « Fini » ambitieuse
      1. a. Utiliser la rétrospective de Sprint
      2. b. Utiliser la revue de Sprint
5. Focus sur la transparence
   1. 1. Définition
   2. 2. Les vertus de la transparence
   3. 3. L’effet de la transparence sur l’inspection et l’adaptation
      1. a. Un exemple concret
      2. b. Une controverse est une source d’inspection
   4. 4. Les effets d’une transparence complète ouincomplète

Définir le produit

1. La vision produit
   1. 1. La vision produit est la cible
   2. 2. Les trois principales typologies de produits
      1. a. Un nouveau produit
      2. b. Une évolution de produit
      3. c. Une mise en conformité
   3. 3. Exemples de vision produit
      1. a. Assurancetourix sous la contrainte RGPD
      2. b. Roméo et ses masques
      3. c. Siri
   4. 4. L’anticipation
      1. a. L’anticipation rationnelle
      2. b. L’anticipation émotionnelle
      3. c. La nature de l’anticipation définit la communication
   5. 5. La vision est la rencontre du produit et du marché
      1. a. Le cas Toyota
      2. b. Le cas Haier
   6. 6. Co-construire la vision produit
2. La valeur du produit
   1. 1. Identifier les attributs de valeur
      1. a. Le délai
      2. b. La qualité
      3. c. La fréquence
      4. d. La récurrence
      5. e. D’autres indicateurs
   2. 2. Identifier les objectifs et les contraintes
      1. a. Qualifier les objectifs SMART
      2. b. Exemple de référentiel d’exigences
3. Structurer le produit
   1. 1. La méthode descendante
      1. a. Identifier les objectifs de base
      2. b. Identifier les moyens
      3. c. Identifier les exigences
   2. 2. La méthode montante
   3. 3. Structurer le référentiel d’exigences
      1. a. Prioriser les objectifs
      2. b. Compter les liens des exigences
      3. c. Organiser le référentiel d’exigences
      4. d. Des exigences aux User Stories
4. Rédiger des critères d'acceptation
   1. 1. Rappel des rôles
   2. 2. Les critères d’acceptation baséssur les contraintes
      1. a. Les contraintes métier
      2. b. Les contraintes légales
      3. c. Les contraintes techniques
      4. d. Les contraintes fonctionnelles
   3. 3. Les critères d’acceptation baséssur l’usage
      1. a. La syntaxe Gherkin
      2. b. Cucumber
   4. 4. Le volume des critères d’acceptation

De la stratégie au plan opérationnel

1. Établir une stratégie produit
   1. 1. Les spécificités d’une stratégieproduit  dans un cycle itératif et incrémental
   2. 2. Exemple de stratégie produit
   3. 3. Utiliser les objectifs pour raconter l’histoire duproduit
   4. 4. La stratégie s’inscrit dans le temps
      1. a. Stratégie basée sur un cycle itératifet incrémental
      2. b. La stratégie itérative impliquede découper le produit
      3. c. Ordonnancement basé sur la valeur
      4. d. Ordonnancement basé sur les risques
      5. e. Le MVP
   5. 5. La stratégie produit suppose des moyens
   6. 6. Les besoins des utilisateurs du produit
   7. 7. Maintenir le référentiel d’exigences
      1. a. Qualifier les exigences
      2. b. Initialiser le Backlog de produit
   8. 8. Valider sa stratégie
      1. a. Vérifier les objectifs
      2. b. Vérifier la cohérence des exigences
      3. c. Ordonnancer les objectifs
   9. 9. Concrètement
   10. 10. Les SPOFs
2. Un plan opérationnel
   1. 1. Une vision à long terme
   2. 2. La planification de release
      1. a. La contrainte de délai
      2. b. La contrainte de coût
      3. c. L’objectif d’efficience
      4. d. L’intranet de Marie
      5. e. Partager avec les parties prenantes
      6. f. Partager avec l’équipe
   3. 3. Une vision à court terme
      1. a. Rester focalisé sur les objectifs
      2. b. Le plan de Marie vu par l’équipe
      3. c. Déléguer à la Scrum Team
   4. 4. Planification agile
      1. a. Planifier en fonction du produit
      2. b. Inspecter et adapter
3. Affiner sa vision par rapport à la valeur du produit
   1. 1. Les gains du produit
      1. a. À court terme
      2. b. À long terme
   2. 2. Les coûts du produit
      1. a. Les coûts de réalisation
      2. b. Les coûts de maintenance
   3. 3. Identifier les bénéfices par thématique
      1. a. Bénéfices directs ou financiers
      2. b. Bénéfices de support, d’image oude confort
      3. c. L’exemple de Marie

Gérer le Backlog de produit

1. Organiser le Backlog de produit
   1. 1. Organiser en fonction de la valeur
      1. a. La valeur liée aux gains
      2. b. La valeur liée aux coûts
      3. c. La valeur liée aux délais
      4. d. La valeur liée à des objectifs oucontraintes secondaires
      5. e. La valeur de quel point de vue ?
   2. 2. Organiser en fonction de la complexité
      1. a. La complexité de mise en œuvre
      2. b. La complexité d’exploitation
   3. 3. Organiser en fonction de la prise de risque
   4. 4. Organiser selon d’autres critères
   5. 5. L’organisation du Backlog de Marie
2. Affiner le Backlog de produit
   1. 1. Rappel du principe itératif
   2. 2. Définition de l’affinage
      1. a. Par où commencer l’affinage ?
      2. b. Qui participe à l’affinage du Backlog deproduit ?
      3. c. Quand faut-il affiner le Backlog de produit ?
      4. d. Jusqu’à quel niveau affiner ?
   3. 3. La règle des 10 %
   4. 4. Découper les éléments
   5. 5. Découpage vertical ou horizontal
   6. 6. Affiner les descriptions
   7. 7. Affiner les autres attributs
      1. a. La valeur
      2. b. La complexité
      3. c. Le risque
   8. 8. Affinage et transparence
      1. a. La règle des trois C
      2. b. L’importance d’être compris
      3. c. L’importance de la communication
      4. d. L’importance du format carte
      5. e. Rendre le Backlog de produit lisible et visible
   9. 9. Affiner l’ordonnancement du Backlog de produit
3. Faire face aux changements
   1. 1. Gérer les nouvelles demandes
      1. a. Être proactif
      2. b. Rappeler la planification agile
      3. c. Vérifier les objectifs et les contraintes
      4. d. Rechercher le sens
      5. e. Un modèle opérationnel
      6. f. Savoir dire non
      7. g. Oser dire non
      8. h. Exprimer son désaccord et donner son pointde vue avec assertivité
      9. i. Rester constructif
   2. 2. Nettoyer le Backlog de produit
      1. a. Mesurer les objectifs
      2. b. Les objectifs atteints
      3. c. Les objectifs inaccessibles
      4. d. Les objectifs changent
      5. e. Passer en revue les contraintes
      6. f. Faire le point sur les moyens

Communiquer plus efficacement

1. Introduction
2. Les bénéfices du management visuel
   1. 1. Accéder plus facilement à une informationcomplexe
   2. 2. Réduire le délai de prise de décision
   3. 3. Maintenir plus facilement un référentielcomplexe
3. Les outils de management visuel
   1. 1. La planification de produit
   2. 2. Le Backlog de produit
   3. 3. Le Backlog de Sprint
      1. a. Comprendre le Backlog de Sprint
      2. b. Savoir déceler les signaux d’alerte
   4. 4. Les comptes rendus de l’équipe de développement
   5. 5. Les Burndowns de release ou de produit
   6. 6. Le référentiel d’exigences
   7. 7. Les solutions informatiques
4. Communiquer efficacement
   1. 1. L’information visuelle
   2. 2. S’appuyer sur des faits ou des indicateurs
   3. 3. L’oral et l’écrit
      1. a. Les cas favorables à l’oral
      2. b. Les cas favorables à l’écrit
   4. 4. S’appuyer efficacement sur le Scrum Master
      1. a. Le Scrum Master supprime les obstacles entravant laprogression de l’équipe de développement
      2. b. Le Scrum Master au service du Product Owner
   5. 5. Faire participer des membres de l’équipede développement
   6. 6. Faire participer des parties prenantes

Maximiser la valeur

1. Délivrer le produit
   1. 1. Le plus tôt possible
   2. 2. Livrer fréquemment
      1. a. Le produit de Marie
      2. b. À quelle fréquence ?
   3. 3. Scrum et DevOps
   4. 4. Délivrer le produit de plusieurs équipes
2. Inspecter régulièrement
   1. 1. Inspection du Backlog de produit
      1. a. L’intranet de Marie
      2. b. La qualité des élémentsdu Backlog de produit
      3. c. Les retours des utilisateurs
   2. 2. Inspection des processus de la Scrum Team
      1. a. Marie et ses User Stories
      2. b. La rétrospective de Sprint
      3. c. Inspecter en dehors de la rétrospective deSprint
3. Adapter les processus
   1. 1. Pour accroître la valeur
      1. a. Marie face au RGPD
   2. 2. Pour accroître la transparence
   3. 3. Pour améliorer l’efficience du travail collaboratif
      1. a. Marie change la date de début des Sprints
4. Améliorer la transparence
   1. 1. La revue de Sprint
   2. 2. La compréhension des élémentsdu Backlog de produit
      1. a. Par les parties prenantes
      2. b. Par les Developers
5. Piloter le budget
   1. 1. Mesurer le coût total
      1. a. Le TCO
      2. b. La dette technique
      3. c. La dette opérationnelle
   2. 2. La vélocité comme mesure de ROI
   3. 3. L’usage est la mesure ultime
      1. a. Marie stoppe le développement du produit
6. Piloter les délais
   1. 1. Financer un Sprint supplémentaire
      1. a. Marie prolonge le développement du produit
   2. 2. Réorganiser la planification
      1. a. Le plan de release
      2. b. Réorganiser le Backlog de produit

Scrum à l'échelle

1. Scrum et SAFe
   1. 1. SAFe
   2. 2. Scrum à l’échelle selon Scrum.org
2. Organisation des équipes multiples
   1. 1. Organisation horizontale : la Component Team
   2. 2. Organisation verticale : la Feature Team
3. Scrum avec deux ou trois équipes
   1. 1. La notion d’ambassadeur
   2. 2. La planification de Sprint
      1. a. Le "Why"
      2. b. Le "What"
      3. c. Le "How"
   3. 3. La mêlée quotidienne
   4. 4. La revue de Sprint
   5. 5. La rétrospective de Sprint
4. Scrum à plus grande échelle
   1. 1. Les problèmes de dépendance
      1. a. Dépendances et ordonnancement du Backlogde produit
      2. b. Le poids de la dette technique
      3. c. Marie soigne ses dépendances
   2. 2. Nexus
      1. a. Nexus et SAFe
      2. b. L’affinage du Backlog de produit avec Nexus
      3. c. L’équipe d’IntégrationNexus
      4. d. La planification de Sprint Nexus
      5. e. Les autres évènements Nexus
      6. f. La limite de temps des évènementsNexus
5. Organisation du Backlog de produit
6. Déléguer efficacement

Participer aux événements Scrum

1. Introduction
2. Le Sprint planning
   1. 1. Le thème Why
      1. a. Marie alerte sur la définition de « Fini »
      2. b. L’intérêt de clarifierle Why
      3. c. Respecter le Timebox
      4. d. Le rôle du Product Owner
   2. 2. Le thème What
      1. a. Marie collabore avec la Scrum Team
      2. b. L’importance du Jidoka
      3. c. Le rôle du Product Owner
   3. 3. Le thème How
      1. a. Gérer le Timebox
      2. b. Marie s’appuie sur un objectif clair
      3. c. Le rôle du Product Owner
3. Le Daily Scrum
4. La revue de Sprint
   1. 1. Les bonnes pratiques
      1. a. La revue de la Scrum Team
      2. b. La revue avec les parties prenantes clés
      3. c. La revue avec toutes les parties prenantes
   2. 2. Démythifier la revue de Sprint
      1. a. Tenir des discours différents
      2. b. Manquer de transparence
      3. c. Oublier la Scrum Team
      4. d. Oublier le Scrum Master
      5. e. Croire que tout le monde est agile
   3. 3. Organiser une revue de Sprint
5. La rétrospective de Sprint

Bibliographie

1. Introduction

Glossaire

1. Introduction