PMI PMP: Agile, Scrum et livraison hybride — Guide d'étude

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Fait partie du PMP — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens PMI, ou passez des tests chronométrés sur ExamRoll.io.

Estimation, Story Points et Vélocité

Les story points mesurent l’effort relatif, la complexité et l’incertitude, et non la durée. Une story de cinq points représente environ cinq fois l’effort d’une story d’un point pour cette équipe spécifique. La vélocité (points terminés par sprint) émerge ensuite de manière empirique sur plusieurs sprints et est utilisée pour prévoir des fourchettes, et non pour prendre des engagements calendaires.

Considérer les story points comme des jours fixes est un piège sérieux pour plusieurs raisons. Premièrement, cela détruit l’abstraction : si 1 point = 1 jour, l’équipe se contentera d’estimer en jours et de gonfler les estimations pour respecter les échéances. Deuxièmement, cela élimine le signal d’incertitude : une story de 13 points n’est pas seulement « longue », elle est risquée, et ce risque devrait déclencher une décomposition. Troisièmement, cela permet à la direction d’instrumentaliser les chiffres (« vous aviez dit 40 points, pourquoi n’en avez-vous terminé que 32 ? »), ce qui pousse à gonfler les estimations pour se protéger (sandbagging). L’utilisation correcte est la suivante : tendance de la vélocité + taille du backlog → prévision de livraison probabiliste, communiquée sous forme de fourchette.

Gestion des obstacles, des interruptions et du flux

La tâche la plus tangible du Scrum Master est la suppression des obstacles. Lorsqu’un membre de l’équipe rencontre des difficultés en silence — peut-être par fierté ou par manque d’expérience pour le signaler — le leader de l’équipe doit intervenir directement, comprendre l’obstacle, et soit aider à le résoudre, soit le remonter à un niveau supérieur. Ignorer l’objectif du stand-up quotidien est ce qui permet à ce schéma de s’installer ; une participation irrégulière au stand-up crée des silos de connaissances, masque les bloqueurs et transforme de petits problèmes en risques pour le calendrier. La participation est non négociable précisément parce que la valeur de la cérémonie réside dans la synchronisation, et non dans le rapport de statut.

Les interruptions ad hoc — la demande « urgente » qui contourne le backlog — sont tout aussi corrosives. Elles érodent l’objectif du sprint, invalident les prévisions et habituent les parties prenantes à l’idée que le processus peut être contourné. La bonne manière de les gérer est de diriger les nouvelles demandes vers le PO, qui décide si elles justifient une annulation du sprint (rare) ou si elles doivent être intégrées à un sprint futur (généralement).

Pour les équipes hybrides où les tests ou une autre discipline deviennent un goulot d’étranglement, la visualisation du flux via des tableaux Kanban et des graphiques burndown/burnup expose cette contrainte. Si l’équipe identifie un outil qui pourrait débloquer les tests, le chef de projet ne doit pas approuver ou rejeter unilatéralement la proposition. Il doit l’évaluer de manière collaborative, vérifier la gouvernance organisationnelle (achats, sécurité), consulter le PO sur l’impact sur le backlog, puis prendre une décision. Une approbation réflexe omet la diligence raisonnable ; un refus réflexe ignore l’expertise de l’équipe.

Rétrospectives et amélioration continue

Les rétrospectives bouclent la boucle. Une bonne rétrospective produit une ou deux actions d’amélioration concrètes et appropriées par l’équipe — ce n’est pas une séance de défoulement. Intégrer les équipes opérationnelles et l’assurance qualité (QA) aux rétrospectives dès le début prévient les échecs classiques de transfert, où les équipes optimisent pour les démos de fin de sprint mais pas pour la réalité de la production. L’amélioration continue est le mécanisme qui garantit l’honnêteté de la vélocité, la pertinence de la DoD (Definition of Done) et un engagement élevé de l’équipe tout au long du cycle de vie du produit.

Problème pratique : Scénario de cas d’usage

Scénario : Priya Nair est Scrum Master pour l’équipe du portefeuille mobile « LumenPay » dans une entreprise de fintech. L’équipe fonctionne en sprints de deux semaines et est composée de six développeurs, d’un ingénieur QA et d’un designer UX. Au cours des trois derniers sprints, le Product Owner, Marcus Reeves, n’a assisté qu’à une seule session de planification de sprint et à aucune revue de sprint, invoquant des conflits de responsabilités en tant que directeur des partenariats commerciaux (Retail Partnerships). Les parties prenantes des équipes Conformité et Opérations anti-fraude ont commencé à envoyer directement des e-mails aux développeurs avec des demandes de priorité contradictoires, et l’équipe a reporté 34 des 82 story points sur les deux derniers sprints. La sponsor, Anita Chen, vice-présidente Produit, commence à remettre en question la vélocité de l’équipe.

Défi : Priya doit restaurer l’engagement du Product Owner et mettre fin à la fragmentation du backlog sans outrepasser son rôle de servant leader en prenant elle-même des décisions sur le produit.

Approche recommandée :

1. Documenter les impacts spécifiques de l’absence du PO sur les trois derniers sprints — points reportés, critères d’acceptation ambigus, éléments de backlog non résolus, et le nombre de demandes directes des parties prenantes contournant le PO — pour construire un argumentaire factuel.
2. Organiser d’abord un entretien individuel avec Marcus, en partageant les données et en lui demandant directement s’il peut consacrer les 10 à 15 heures par semaine que le rôle exige, ou si le rôle doit être réattribué ou partagé.
3. Remonter formellement le problème à Anita Chen avec les preuves documentées, en présentant deux options : réattribuer le rôle de PO à quelqu’un ayant la capacité nécessaire, ou négocier une réduction des responsabilités de Marcus dans les partenariats commerciaux.
4. Coacher l’équipe de développement pour qu’elle redirige toutes les demandes entrantes des parties prenantes vers le backlog produit plutôt que de les accepter de manière ad hoc, et renforcer le fait que seul le PO peut redéfinir les priorités.
5. Une fois qu’un PO engagé est confirmé, organiser un atelier d’affinage du backlog (backlog refinement) pour redéfinir les priorités, clarifier les critères d’acceptation et réinitialiser l’objectif du sprint pour la prochaine itération.
6. Établir un accord de fonctionnement (working agreement) spécifiant la présence du PO à la planification, à la revue et à au moins deux sessions d’affinage par sprint.

Pourquoi cette approche fonctionne : Remonter le problème de vacance du poste au sponsor préserve l’intégrité du rôle — le Scrum Master ne doit pas devenir un Product Owner par procuration, car cela masquerait de façon permanente le problème organisationnel et compromettrait la priorisation basée sur la valeur. Fonder la remontée d’information sur des métriques concrètes permet de centrer la conversation sur les résultats de livraison plutôt que sur les personnalités, et le fait de rediriger le flux des parties prenantes vers le backlog restaure la discipline de la source unique de vérité dont dépend Scrum.

← Leadership d’équipe et gestion des ressources · Tous les domaines · Périmètre →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →