Le Product Owner bichonne son backlog

Le backlog de produit demande des soins attentifs et réguliers !

J'ai passé une bonne partie de ma dernière semaine sur le backlog d'IceScrum. En tant que Product Owner de ce bel outil qui rencontre de plus en plus de succès, j'ai du travail qui va aussi en s'amplifiant. Le temps que je consacre à IceScrum peut être divisé en 3 parties à peu près égales :

Communiquer avec les utilisateurs

Il s'agit de travaux qui ne sont pas directement liés au développement du produit mais qui sont absolument nécessaires pour un Product Owner. IceScrum est un produit Open Source qui a de nombreux utilisateurs inconnus, mais aussi quelques uns que je connais bien et dont je sollicite régulièrement le feedback sur le produit. Il y aussi les 30 utilisateurs (étudiants et enseignants) de l'IUP ISI avec lesquels j'ai des relations privilégiées. Je fais aussi du marketing, des démos...

Travailler avec l'équipe sur le sprint courant

Je participe aux réunions du cérémonial avec l'équipe. A côté, je réponds aux questions sur les stories qui font l'objet du sprint courant. Au moins deux fois par semaine, je télécharge le build à partir du serveur d'intégration continue Hudson pour tester les stories et vérifier si elles sont bien finies. Je mets à jour les informations dans le suivi avec IceScrum (on peut y montrer le résultat des tests et déclarer une story comme finie).

Anticiper sur les sprints suivants

C'est dans cette partie que je bichonne particulièrement le backlog. Il faut ajouter dans le backlog ce qui remonte du feedback des utilisateurs, après s'être assuré de son intérêt, définir le type de story, formuler la story. Evidemment j'utilise IceScrum pour ça et une nouvelle story se place automatiquement au fond du backlog. Il faut ensuite se poser la question de la priorité de la story et, selon, la remonter dans la liste (un glisser-déplacer avec IceScrum).
Il est bien plus difficile de définir les priorités sur un produit qui a déjà une longue existence comme IceScrum que pour un nouveau développement. Quand on développe un nouveau produit, les priorités sont définies au niveau des features qui sont ensuite déclinées en stories qui conservent l'ordre défini pour les features. Avec un produit qui offre déjà de nombreuses fonctions et qui est largement utilisé, les nouvelles stories qui proviennent du feedback et aussi celles déclinées de la vision sont bien plus disparates, rendant la définition des priorités plus difficile à établir.
Une fois les 20 stories les plus prioritaires à peu prés identifiées, il faut aller voir l'équipe pour obtenir une estimation (avec un petit planning poker) pour les stories qui n'en ont pas encore. L'estimation de la taille m'amène souvent à ajuster les priorités. Cette réunion s'appelle en fait planification de release[1] : après avoir estimé, on associe les stories les plus prioritaires au sprint à venir, et éventuellement au suivant, pour avoir un horizon à un mois[2].
Avant la fin du sprint, il faut aussi élaborer les tests d'acceptation des 2-3 stories les plus prioritaires du prochain sprint.

Bref bichonner son backlog de produit pour qu'il soit prêt pour le sprint qui va commencer.

Notes

[1] j'appelais cela revue de backlog auparavant

[2] nos sprints durent deux semaines