Dans un article sur les relations entre Product Owners et développeurs, Clément évoquait notamment l’importance d’embarquer les développeurs dans la vision et la conception du produit. Le rythme SCRUM et ses successions de sprints, mais aussi le découpage en user-stories indépendantes, peuvent en effet rapidement mener à une organisation délétère ; un système où les Product Owners génèrent à leur rythme un flux continu de user-stories, les développeurs se contentant de les estimer puis de les développer, le nez en permanence dans le guidon, sans avoir de vision d’ensemble.
J’ai été moi-même confronté à cette problématique lors d’un de mes projets. Au delà de communiquer à l’équipe un cap général, une vision produit (ce qui est naturellement indispensable), il était parfois difficile de donner de la visibilité aux équipes de développement sur les fonctionnalités ou évolutions à venir au delà du périmètre des 2 prochains sprints. Par ailleurs, nous voulions également recueillir des avis de développeurs plus en amont, afin de collecter leurs bonnes idées et d'adapter nos stories aux contraintes techniques envisagées.
Plusieurs approches complémentaires sont possibles pour résoudre ce problème de visibilité “moyen terme” et embarquer les développeurs dès la phase de conception des stories.
Transparence totale sur le backlog
Sur ce projet, notre backlog de stories était entièrement ouvert à toute l’équipe, accessible dans Jira mais aussi sous forme de management visuel sur un mur dédié. En tant que Product Owner, nous nous efforçions également de mentionner lors des Daily Meetings les sujets sur lesquels nous étions en train de travailler, les retours remontés par les clients, ou encore les grands changements d’orientation du produit à prévoir.
Cependant, le fait que toutes ces informations soient accessibles ne signifie pas qu’elles sont lues. Une équipe de développement en plein sprint prend rarement le temps d’aller lire par curiosité les spécifications d’une user story qui ne sera pas développée avant un ou deux mois, encore moins de proposer des modifications ou suggestions.
Il est donc préférable d’organiser un moment récurrent où toute l’équipe se réunit pour parler du backlog.
Séances de Backlog estimation
Une option consiste à organiser des sessions régulières d’estimation des stories (rapides - à travers des ateliers de planning poker ou d'eXtrême quotation par exemple - ou plus exhaustives). De cette façon, on s’assure d’avoir un stock de stories estimé et on donne une visibilité à l’équipe (à un niveau très macro) sur les fonctionnalités à venir dans l’application. Ce mode de fonctionnement est utile pour le Product Owner car il lui permet de mieux planifier ses futurs sprint et d’anticiper la réécriture de user stories perçues comme trop complexes ou importantes ; mais il pose plusieurs problèmes.
D’abord, ces ateliers sont relativement fréquents et ne doivent donc pas durer trop longtemps : les story sont décrites très succinctement, assez pour une estimation rapide, mais pas suffisamment pour discuter du fond ou collecter des idées
Ensuite, nous nous sommes rendus compte que d’estimer le backlog à l’avance ne faisait en pratique pas gagner énormément de temps au moment du sprint planning. Certes, ce n'est pas le but premier, mais devoir présenter deux fois chaque user story représente un investissement en temps important. Quelques semaines plus tard, lorsqu’il s’agissait de construire le sprint, tout le monde avait oublié les discussions autour de la story et ce qui justifiait l’estimation initiale ; la story pouvait avoir été modifiée entre temps ; ou bien certains développeurs n’étaient pas là lors de la séance d’estimation et découvraient la story de toute façon en sprint planning.
Séances de “Backlog Preview”
Nous avons finalement choisi de proposer des séances récurrentes d’échange autour des stories, que nous avons baptisées “Backlog Preview”.
Ces réunions, souvent organisées juste après le Daily Stand Up, ne devaient pas durer plus de 10 à 15 minutes, et ne concernaient qu’une unique user story par session. Nous sélectionnons les stories à présenter en priorisant :
- Les fonctionnalités “stratégiques” représentant de gros changement à venir sur le produit : nouveau pan fonctionnel, refontes de rôles utilisateurs...
- Les user-stories pour lesquelles nous envisageons plusieurs solutions / implémentations possibles, avec un besoin d'évaluer la complexité de chacune pour pouvoir trancher
- Les user-stories encore en brouillon pour lesquelles nous avions besoin d’idées fraîches ou d'avis extérieurs
- Les user-stories à propos desquelles nous soupçonnions l’existence de gros défis techniques
- Enfin, les user-stories ayant un impact potentiel sur des fonctionnalités en cours de développement dans le sprint
Ces séances n’avaient pas pour but d’estimer les stories, mais bien de présenter au développeur ce que nous avions en tête pour le futur du produit tout en collectant leur avis sur la faisabilité technique, mais aussi l’UX et les fonctionnalités.
En choisissant des stories liées aux fonctionnalités du sprint courant, cela a permis aussi parfois d’anticiper dans l’architecture ou les développements en cours de futurs besoins fonctionnels.
Bilan
Nous organisions ces réunions en fonction des besoins, en général de une à deux fois par semaine. Mais il aurait sans doute été préférable d’y dédier un créneau fixe, car ce planning un peu lâche a malheureusement conduit à la raréfaction puis la disparition progressive de ces “Backlog Previews”. Pour autant, le concept d'une réunion collaborative autour des stories assez en amont de leur développement semble toujours pertinent, offrant la possibilité à chaque membre de l'équipe d'apporter des idées en fonction de sa sensibilité (technique, UX, fonctionnelle).
Et vous, comment faites vous pour impliquer vos développeurs dans la création des stories et communiquer sur votre backlog à moyen-terme ?
