Et zoup, un nouveau petit post sur les activités de notre cher PO :  la gestion du backlog et découvrons 6 des qualités du PO.

Pour illustrer les difficultés d’un PO à construite un backlog, Henrik Kniberg à réaliser une illustration parfaite, à méditer:

SplitStory

 

Une des premières étapes pour le PO dans un nouveau projet, est, dans mon idée, d’avoir une ébauche de son backlog et un plan de release.  En général, cette ébauche de backlog est réalisée par le PO avec les décideurs du projet, en amont du démarrage de l’implémentation.

La création du backlog se passe en plusieurs étapes. Au début, on peut utiliser des techniques comme l’impact mapping (présentée par Gojko Adzic), qui permettent entre autre d’obtenir une liste des épics avec la valeur attendue pour chacune d’elles (en définissant les hypothèses sur lesquelles les valeurs attendues sont calculées). Les informations sur les hypothèses et la valeur des épics servira plus tard pour la priorisation du backlog et la création du plan de releases.

Slide1

Dans une deuxième étape, les techniques de story mapping (ex : scrum alliance)  permettront d’aller plus loin dans le découpage des épics en stories et d’obtenir un plan de release.

Slide2

Dans une troisième phase, le travail du PO va consister à transformer le plan de release en liste de stories à implémenter par l’équipe  dans chacune des itérations.

Slide3

Notre PO, à donc maintenant un backlog,  mais attention, dans ce backlog toutes les epics ne sont pas détaillées. En effet, quel peut être l’intérêt de détailler des épics pour la release 2, sachant que nous remettrons peut être en cause le contenu fonctionnel de cette release. Pour la même raison, toutes les stories de la release 1 ne sont pas détaillées. En effet, certaines devront être découpées (suite aux estimations de l’équipe, …), ou évolueront au cours du temps.  Le PO doit faire à mon avis, le travail minimal qui lui permettra de travailler avec l’équipe, tout en ayant les informations nécessaire pour réaliser son plan de release (estimation, risques, …). Parmi les outils qui pourront aider notre PO dans l’écriture de son backlog, on peut noter la définition des personna (la vidéo de Jeff Patton illustre bien cette technique).

Une fois ce backlog en poche, notre PO peut commencer son travail quotidien et être confronté à de nombreux challenges:

  • Avoir un backlog à jour : cela semble le B-A,BA  mais est-ce que tous les PO maitrisent leur liste de livrables, questionne leur plan de release (validation des hypothèses sorties de l’impact mapping, …).
    Il doit préparer avec l’équipe les stories pour l’itération n+1 et n+2. Par préparer j’entends vérifier la compréhension de la story, définir les critères d’acceptations et peut être même l’écriture des scénarios de tests.
    Le PO doit aussi découper logiquement les stories trop grosses après l’estimation de l’équipe (Rappel : une story doit être indépendante des autres, négociable, avoir de la valeur, être estimable, réalisable en un sprint et testable). Parmi les ressources que j’aime bien pour aider a splitter les stories :
    * http://www.agileforall.com/2012/01/new-story-splitting-resource/
    * http://www.agileforall.com/2009/10/patterns-for-splitting-user-stories/
    * http://www.infoq.com/news/2011/04/how-to-split-user-stories
  • Comprendre et incorporer le fonctionnel caché : parmi les aspects que l’on oublie souvent dans le Done, ou dans un backlog nous pouvons citer la performance du logiciel, la sécurité, la traduction, la compatibilités dans les différents environnements ou l’application sera déployée ….
  • Adapter son backlog de manière continue : le travail de jardinage de son backlog est une activité quasi-quotidienne, ou le PO doit tenir compte des remarques de l’équipe, des métriques du projet, des remarques collectées lors des démos, de l’évolution de l’environnement, des retours des clients/utilisateurs, …
  • Gérer les défauts :  2 des objectifs des pratiques agile sont de rendre visible le travail réalisé, et de ne pas montrer de choses non finies (contenant un bug).  Cela implique que le PO doit rendre visible le travail réalisé sur les bugs (en donnant des métriques lors des démos par exemple),  minimiser la durée de vie d’un bug (pour rappel, un bug vue rapidement et corrigé directement par le développeur ne coute rien, proportionnellement à son occurrence en production). Il y a souvent un travail pour faire prendre conscience aux équipes de dev de l’importance ou des impacts de la non-qualité. Cela peut aussi aider l’équipe à prendre conscience de sa zone de responsabilité.
  • Tenir compte des taches techniques : qui n’a pas déjà entendu “sans le framework 2.0 on ne peut rien faire”, “on a du légacy”, mais aussi “cela est de la technique, ce n’est pas mon problème, c’est le vôtre”. Alors je sors le bouclier, et je dis non. Autant j’estime que le rôle d’un équipier est de fournir au PO les informations pertinentes (coûts, bénéfices, alternatives possibles, …), autant j’estime que le PO doit jouer son rôle d’arbitrage entre les solutions possible, et surtout dans la planification de ces évolutions dans le plan de release.
  • Gérer les releases : livrer fréquemment est possible, par contre, livrer incrémentalement de la valeur aux clients est beaucoup plus difficile et demande une discipline au PO pour ordonner les stories, valider et remettre en cause les hypothèses, supprimer régulièrement du logiciel les fonctionnalités sans ou peu de valeurs.

 

Advertisements