5 raisons de modifier l'ordre des items

Un Product Owner donne à son équipe 10 Story Cards (des fiches contenant chacune une User Story). Les membres de l'équipe les lisent et rendent au Product Owner les cinquième et sixième cartes. À la fin du Sprint, l'équipe livre les fonctionnalités des cartes 1, 2, 3, 4 et 7. Cependant, le travail sur les cartes 5 et 6 n'a pas encore commencé.

À mon avis, c'est tout à fait acceptable.

Une recommandation standard dans les méthodes agiles est que l'équipe doit travailler sur les éléments du Backlog dans l'ordre défini par le Product Owner. Même si cela a du sens jusqu'à un certain point, les bonnes équipes agiles font régulièrement des exceptions à cette règle.

Il existe de nombreuses bonnes raisons pour qu'une équipe ne respecte pas l'ordre établi. En voici quelques-unes qui devraient suffire à le justifier :

1) Effets de synergie

Il existe souvent des effets de synergie entre les items tout en haut du Product Backlog. Pendant qu'une équipe travaille par exemple sur l'item n°3, elle devrait aussi pouvoir travailler sur l'item n°6. Si deux items se trouvent dans la même partie du système et peuvent être traités plus rapidement ensemble, le Product Owner devrait également l'autoriser.

2) Dépendances

Une équipe peut décider que l'item 4 est plus important que les items 5 et 6. Malheureusement, on ne peut travailler sur le n°4 qu'une fois le n°7 terminé. Une telle dépendance suffit généralement à autoriser une équipe à s'écarter de l'ordre prévu.

3) Disponibilité de l'expertise

Une équipe aimerait peut-être travailler sur le quatrième item le plus important du Product Owner, mais la bonne personne pour cela n'est malheureusement pas disponible. Bien sûr, cela peut être un signe que davantage de membres de l'équipe devraient être capables de travailler de manière transversale – mais c'est plutôt une solution à long terme. Une solution à court terme serait simplement de travailler sur d'autres items jusqu'à ce que le membre de l'équipe possédant les compétences requises soit à nouveau disponible.

4) C'est plus intéressant

D'accord, ce point est discutable. Je ne dis pas que l'équipe devrait travailler sur les items n°1, 2, 3, 4 puis sur le n°600. Mais choisir les items comme dans mon exemple (1, 2, 3, 4, 7) est acceptable si cela rend le travail un peu plus passionnant.

Dans certains projets, les équipes tombent parfois sur toute une série de Product Backlog Items qui ne sont pas vraiment amusants. Si une équipe peut de temps en temps avancer un item qui offre un peu de variété, cela peut avoir un effet positif sur le moral des membres de l'équipe. Et c'est à son tour bénéfique pour le Product Owner.

Bonus : 4.1.) C'est plus intéressant pour les parties prenantes

Puisqu'on en parle : j'affirme simplement qu'il est également acceptable pour une équipe de modifier l'ordre si certains items intéressent les Stakeholder.

Parfois, il peut être assez difficile d'amener toutes les personnes importantes à participer aux Sprint Reviews. Cela devient particulièrement compliqué quand les dernières Reviews étaient plutôt ennuyeuses. La raison peut être la haute priorité de certains travaux (par exemple des choses importantes mais qui ne sont pas vraiment visibles pour les parties prenantes).

Dans un tel cas, il peut être judicieux de donner un peu de sex-appeal au prochain Sprint Review. Car si l'équipe travaille sur quelque chose que les parties prenantes trouvent intéressant, celles-ci seront plus enclines à participer à la réunion.

5) Taille

Si les raisons précédentes ne t'ont pas encore convaincu, j'ai gardé la raison la plus convaincante pour la fin. Elle prouve que chaque équipe peut parfois s'écarter de l'ordre défini par le Product Owner : une équipe peut par exemple sauter l'item n°5 s'il est trop gros. L'équipe prend alors l'item suivant qui correspond à la taille du Sprint.

Si ce n'était pas autorisé, l'équipe ne sélectionnerait que les items 1, 2, 3 et 4, puis s'arrêterait. Il resterait alors peut-être une partie considérable du Sprint non utilisée. Bien sûr, l'équipe pourrait au moins accomplir une partie de l'item 5 puis en attaquer un autre. Mais ce n'est pas vraiment judicieux dans de nombreux cas. C'est pourquoi l'équipe s'écartera au moins de temps en temps de l'ordre initial.

Les Product Owners ne sont pas parfaits

Un Product Owner parfait saurait tout cela. Un Product Owner parfait saurait que les quatre premiers items du backlog représentent déjà tellement de travail lié à la base de données qu'il ne devrait pas mettre un autre item de ce type en position 5. Un Product Owner parfait saurait que les items 2 et 5 concernent la même classe Java et les regrouperait donc lors de la priorisation.

Mais pour la plupart des Product Owners, il est difficile d'être parfait. La meilleure solution est simplement de prioriser le Product Backlog du mieux possible, puis de laisser l'équipe peaufiner les détails.

Ce texte provient du blog de Mike Cohn et a été traduit par nos soins en français.

agile100: Roger Martin

=> En février 2021, nous avons parlé avec Roger L. Martin de son livre "When more is not Better".

Travail agile chez MAN

=> À quel point MAN Truck & Bus SE est-elle agile et comment fonctionne le travail agile dans l'industrie automobile ?