product ownership : retours d'expérience

Product Owner retour d’expériences / XPday 2009

!Sébastien Sacard

Consultant Définition de Produit

sebastien@piaolink.com

Cursus

• Depuis 2007: Piaolink, Consultant définition de produit - Kivahu.fr, Product Owner - Drimki.fr, Product Owner

• 2006/2007: Yahoo! Voyages Europe, Product Owner

• 2006: Formation interne Yahoo! de SCRUM Master

• Entre 2002 et 2006: Kelkoo, Chef de projet technique

Product Backlog

Priorité Elément Estimation

Very High Le rôle du Product Owner 5

High Le Product Owner et le Business Owner 10

High Le Product Owner et l’équipe SCRUM 10

LowL’équipe produit

5

Le rôle du Product Owner

«The Product Owner

prioritizes the Product

Backlog.»

http://www.mountaingoatsoftware.com/product-owner

C’est tout ?

Description détaillée

1/ Typically someone from a Marketing role or a key user in internal development.

2/ In return for their commitment to completing the selected tasks, the product owner commits that she will not throw new requirements at the team during the sprint.

3/ Requirements are allowed to change but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.

http://www.mountaingoatsoftware.com/product-owner

Beaucoup d’interdiction. !

Peu de direction....

1/ Profil technique ou marketing ?

Les deux !

• Marketing pour pouvoir s’affranchir des contraintes techniques

• Technique pour comprendre et anticiper les contraintes de l’équipe de développement

En pratique : un Product Owner sans background technique se retrouve vite limité.

2/ Ne pas interférer

• Le Buffer d’urgence (mise en place chez Drimki)

• 20% de la bande passe pour le «hors-sprint»

• A été négocié avec le business pour conserverla flexibilité (et SCRUM)

• Le SCRUM Master doit pouvoir résister

• Ne pas compter «que» sur le respect de la méthode

• Rapport de force permanent... mais respectueux des compétences de chacun !

3/ Changer les besoins hors sprint

• Convaincre le business owner d’attendre Mettre en jeu les objectifs de qualité sur le long terme

• Donner de la visibilité ! Sur les 3 ou 4 sprints suivants / sur le trimestre

• Protéger l’équipe SCRUM Afin de conserver l’enthousiasme

• Négocier en permanence Avec le business owner, avec le scrum master

Pourrait-on remplacer le Product Owner par...

• ... un chef de projet ? - peut rentrer en conflit avec le SCRUM Master «technique» - le SCRUM Master risque de devenir un simple «animateur»

• ... un chef de produit ? - si trop marketing, déconnecté des contraintes de développement. - en général, rarement au quotidien avec l’équipe

• ... le client ? - risque de rester fixer sur les objectifs business (court terme) - manque des compétences spécifiques (planification)

Peut-on se passer de Product Owner ?

Si pas le budget et si le SCRUM Master est expérimenté, les fonctions de Product Owner peuvent être limitées.

• Le rôle du Product Owner peut être limité à l’expression des besoins (avec un minimum de rigueur)

• Le SCRUM Master gère l’intéraction avec le client et gère le product backlog

Product Owner &

Business Owner

Responsabilités

• Education

• Mise en place / Maintenance du Product Backlog

• Etablissement d’une feuille de route

• Estimation et Priorisation

• Reporting

Education

• Beaucoup de clients ne sont pas habitués à être impliqués... et à partager les succès et les échecs

• Faire comprendre que le Business Owner n’est pas forcément le client idéal de son propre produit

• Besoin de représentants clients

• Etude de marché + étude de besoins

Maintenir le product backlog

• Document d’interface entre le PO et l’équipe SCRUM

• Différents outils existent : Tableur + Traitement de texte fonctionnent très bien

• Utiliser les récits utilisateurs, mais ne pas s’arrêter à l’expression (ne pas oublier les tests de validation).

• Impliquer le Business Owner : Demander d’exprimer les besoins sous forme de récits, ou les exprimer à sa place et les faire valider

La feuille de route

• Document d’interface entre le Business Owner et le PO

• La feuille de route est une vision condensée du Product Backlog: les mises à jour mutuelles sont essentielles

• La feuille de route est l’instrument de visibilité par excellence pour le Business Owner: un document d’une page contenant les fonctionnalités clés

• La feuille de route sert à l’équipe SCRUM qui a la visibilité sur ce qui est communiqué au Business, parfois avec un vocabulaire différent

Estimation et Priorisation

• Estimation :

• Difficile en amont sans le feed-back technique

• Doit se concentrer sur l’estimation de la complexité relative par rapport aux autres récits

• Priorisation :

• Accompagner le Business Owner a faire le choix

• Montrer le backlog pour justifier de son entretient

Product Owner &

Equipe SCRUM

Responsabilités du Product Owner

• Gestion Product Backlog

• Sprint planning meeting

• Sprint tracking

• Sprint review

• Release tracking

Gestion Product Backlog

• Objectif : Maintenir les priorités à jour

• Bonnes pratiques :

• Organiser tous les 3 sprint une revue globale et assigner les éléments aux prochains sprints (sur 2 ou 3 mois)

• Gérer «des» backlogs :

• gérer des backlogs par thèmes (grandes fonctionnalités)

• faire gérer un backlog technique par le SCRUM master

• gérer les bugs à part (bug tracking)

Intérêt de différents backlogs

• Permet d’incorporer plus facilement les demandes quotidiennes et de ne pas se perdre dans un backlog trop généraliste.

• Permet de gérer les priorités techniques (maintenance, sécurité) en dehors des fonctionnalités produits

• Permet de créer des sprints pondérés: et négociés:

• sprint n: 70% produit, sprint n+1: 70% technique

Spécification des éléments

• Les spécifications sont faites en amont des sprints

• Besoin des feed-backs des dévelopeurs mais ne pas les déranger....

• option 1 : Réserver des plages de travails dans le sprint => ralenti le sprint en cours

• option 2 : Travailler dans les intevalles=> nécessite de spécifier le sprint n+2

Sprint Planning

• Objectif : créer le Sprint backlog

• Bonnes pratiques :

• Etre convaincant sur les priorités !

• Ne pas inclure une fonctionnalité qui n’est pas spécifiée

• Ne pas participer a l’estimation des points

• Négocier et valider le Sprint Backlog proposé par l’équipe SCRUM

Sprint Tracking

• Objectif : pouvoir tenir informé le business des avancées

• Bonnes pratiques :

• Tester chaque fonctionnalité «réalisée» durant le sprint (ne pas attendre la fin du sprint pour tout tester)

• Etre vigilant et accepter de retirer des fonctionnalités

Sprint review

• Objectif : analyser et améliorer

• Bonnes pratiques :

• Ne pas se réfugier derrière les «specs»

• Accepter les critiques

• S’assurer que les commentaires seront pris en compte dans le prochain sprint !

Release tracking

• Objectif : Avoir une visibilité sur l’avancement de la roadmap

• Bonne pratique :

• Gérer les fonctionnalités par trimestre

• Le premier trimestre est trés précis, les suivants moins

• Travailler sur la roadmap avec le SCRUM master et idéalement certains développeurs seniors

Bonnes pratiques

• Ne pas avoir de listes de diffusion par mail «produit» et «dev»: - Coupe l’équipe en deux - Déresponsabilise («demande au produit»)

• Avoir des listes par sprints : «sprint-n@» - Permet de travailler sur plusieurs sprints en même temps, tout en permettant de filtrer ce qui concerne le sprint courant des sprints suivants- Permet d’affiner les spécifications en «flux tendu»

Pour conclure

• Donner de la visibilité et de l’autonomie dans les choix techniques, pas dans les choix fonctionnels (mais écouter)

• Attention au putsch : Une équipe SCRUM peut évincer un Product Owner si trop d’autonomie (vécu)

• SCRUM n’est pas adapté aux développeurs junior, s’assurer que l’équipe est homogène et globalement senior

• SCRUM s’inscrit dans la durée : pas adapté pour des projets «one-shot». Surtout si l’équipe existante n’est pas agile.

L’équipe produit

Profils et fonctions

• Architecte de l’information : le cartographe

• Concepteur Rédacteur : la voix

• Graphiste (DA, designer) : l’artiste

• Ergonome : le responsable de la satisfaction

• Designer d’interaction : le responsable qualité

Les intégrer dans l’équipe SCRUM ?

+ permet de favoriser l’interaction et l’efficacité

+ permet d’avoir un feed-back rapide durant le sprint

- le travail de spécification n’est pas continu

- qui est le responsable de leur travail : PO ou Scrum Master ? En pratique : ces métiers ne doivent pas être intégrés dans l’équipe SCRUM.

Les outils du Product Owner

• Présentations haut-niveau (Powerpoint)

• Persona

• Récits utilisateurs (User Stories)

• Architecture de l’information

• Wireframes

• Prototypes dynamiques