Les règles de Scrum sont bien connues et largement répandues. Elles ne sont pas très compliquées. Mais les appliquer correctement est une autre paire de manches. En tant que ScrumMaster, vous avez de nombreux écueils à éviter. En voici 4.
Un Product Backlog bien ordonné est capital. C’est en principe la tâche du Product Owner qui, heureusement, n’est pas seul à s’en charger. Le ScrumMaster peut l’aider à trouver des techniques de gestion efficace du Product Backlog. Deuxièmement, le ScrumMaster peut inciter son équipe à créer des items clairs et concis pour le Product Backlog. Réfléchir avec le Product Owner est également intéressant pour mieux comprendre le planning produit et le fonctionnement du département. Enfin, le ScrumMaster peut apprendre au Product Owner à ordonner son Product Backlog afin d’en tirer le maximum. Le ScrumMaster assume donc lui aussi la responsabilité de faire en sorte que le Product Owner évite habilement les pièges. Regardez ci-dessous comment ces pièges peuvent se présenter.
1. Avez-vous réalisé ce que vous vouliez ?
Connaissez-vous la roue de Deming Plan, Do, Check, Act ? Les étapes Check et Act sont souvent oubliées. Ceci peut avoir plusieurs raisons : vous ne connaissez pas la situation initiale, il n’y a pas d’objectifs clairs ou aucune mesure n’est faite. Tant que vous n’aurez pas comparé avec la situation initiale et recoupé avec les objectifs le résultat de vos Product Backlog Items (PBI), vous ne saurez pas ce qu’il reste à faire : act ! Il n’y a pas de processus d’apprentissage, ce qui complique la gestion du Product Backlog.
2. Trop d’items dans le Product Backlog
Le Product Backlog est une liste ordonnée de tous les items nécessaires pour ce produit, mais si vous y placez littéralement tous les items, vous risquez d’obtenir une liste interminable et incompréhensible. En tant que ScrumMaster, vous pouvez proposer des techniques pour gérer efficacement cette liste, entre autres en rassemblant les PBI qui ont un lien entre eux mais n’ont pas encore été traités en un seul grand PBI. C’est ce que l’on appelle les Features ou Epics. Vous pouvez ainsi classer les items sur différents niveaux afin de rendre le Product Backlog plus clair.
3. Le volume de chaque PBI n’a pas été estimé
Chaque PBI représente une quantité de travail. Si cette quantité de travail n’a pas été identifiée, cependant, vous ne pourrez pas connaître la valeur relative des PBI, et ne saurez pas non plus si le Product Backlog a été ordonné de la manière la plus efficace possible.
4. La valeur des PBI n’est pas connue
Chaque PBI a une valeur. Si vous ne connaissez pas la valeur, vous ne pourrez pas non plus établir de valeur relative, ce qui compliquera la priorisation du Product Backlog pour le Product Owner. Ceci, à son tour, vous empêchera de tirer le maximum du produit, le résultat du travail acharné de l’équipe Development.
Source : www.cibit.nl
Envie d’en savoir plus ?
La formation de 2 jours Certified ScrumMaster vous apprendra comment appliquer correctement Scrum et, en tant que ScrumMaster, accompagner votre équipe et le processus de façon optimale. Comment et où sont nés Agile et Scrum ? Quelles en sont les principales différences avec l’approche traditionnelle, et comment cela fonctionne-t-il ? Théorie, pratique et Agile Games.
