Voilà plus d’un an et demi que je continue de me documenter sur les pratiques Scrum : lectures de plusieurs ouvrages de référence (The communication Gap, User stories applied, Agile Testing, Gestion de projets agiles, etc.), formation certifiante “Product Owner” en 2010 et spectatrice de divers évènements Scrum.

Aujourd’hui Product Owner (PO) missionnée au sein d’une DSI, j’aimerais revenir sur quelques épisodes marquants de ma vie scrumienne. 

Episode 1- Le budget, la psychose du PO

En principe, dans les pratiques Scrum, le produit applicatif se construit tout au long des cycles de développement (ou itérations) permettant d’implémenter en priorité les fonctionnalités à fortes valeurs métiers et de s’assurer de répondre aux besoins des utilisateurs en recueillant régulièrement leurs retours. Le changement n’est donc, pas seulement autorisé, il est le bienvenu.

En pratique, même si la conception applicative suit effectivement le rythme des itérations, il est difficile, dans un contexte d’entreprise standard, de s’éloigner radicalement du périmètre fonctionnel initial décrit pendant la phase de cadrage (avant l’itération 0). Le backlog est indirectement en cause.

En tant que PO, je dois suivre deux indicateurs et les communiquer aux instances de pilotage, à chaque fin d’itération. Le premier, relatif au produit, concerne la complexité et s’exprime en story points : complexité absorbée (points réalisés pendant l’itération) et complexité restante (points restants dans le backlog produit). Le second, relatif au projet, traite du budget et s’exprime en jours hommes : budget absorbé (jours-hommes utilisés pendant l’itération) et budget restant (jours-hommes disponibles pour le projet). C’est à ce moment précis que se développe ma schizophrénie.

Initialisé à la fin de la phase de cadrage, suite au recueil des besoins métiers,  le backlog décrit les fonctionnalités principales du futur produit. Outil névralgique du projet, il a 2 utilités principales :

  • Pour les équipes décisionnelles, il permet de budgétiser le projet grâce aux estimations de chacune des taches (ou stories) qui le peuplent. Pour ce faire, est appliqué au nombre total de story points un ratio story points/jours-homme, calculé grâce à la vélocité moyenne des équipes de développement. Autrement dit, si le backlog contient 500 story points avec un rapport moyen de 2 points absorbés par développeur et par jour, le budget est de 250 jours-hommes. De ce point de vue, le budget est acté et fixé pour le projet !
     
  • Pour les équipes opérationnelles, il permet d’établir le plan des livraisons à moyen terme et celui des itérations à court terme. De ce point de vue, les fonctionnalités du produit évoluent tout au long du projet : de nouvelles naissent, d’autres sont modifiées mais aucune n’est vraiment jamais remplacée voire supprimée. Cela s’explique par le fait que pendant le cadrage, le besoin est tout juste mesuré et certaines parties ne se révèlent qu’au dernier moment. En conséquence, mon backlog produit grossit sans réajustement budgétaire.

En tant que PO, j’hérite, donc, d’un budget qui n’est plus réel, et, qui constitue, malgré tout, 50% de mes indicateurs de pilotage.

En résolvant cette problématique par dichotomie :

  • Le pire que je puisse faire est d’endiguer les évolutions du backlog …
  • Le mieux, à présent ! Sensibiliser les directions métiers aux processus Scrum et les amener progressivement à utiliser les pratiques agiles dans leur activité de planification

Nous pouvons orienter progressivement les directions métiers dans cette direction grâce notamment à une relation de confiance. Pour y arriver, parmi mes autres responsabilités de PO, la plus importante est la garantie de leur construire le “bon logiciel”. Certaines méthodes existent mais une seule a réellement fonctionné pour moi. Mais ceci mérite d’être le sujet d’une toute autre histoire ……