1. Proxy Product Owner
Enrichit ou dénature Scrum
Frédéric Duffau – 27 mars 2012

2. Merci
à nos sponsors Platinum

3. Et merci
à nos sponsors Gold et Silver

4. Le Product Owner : PO

5. #0.0 PO, compétences
● bonne connaissance du domaine métier,
● maîtrise des techniques de définition de produit,
● capacité à avoir une position respectée et à
prendre des décisions,
● capacité à détailler une fonctionnalité au bon
moment
● esprit ouvert au changement,
● bon négociateur.

6. #0.1 PO, activités
● mettre à jour le backlog de produit, ajuster
les priorités
● répondre aux questions sur les user stories
● définir les tests d'acceptation
● passer ces tests ou s'assurer qu'ils le sont

7. #0.1 PO, implication
● Revue de backlog
● Réunion planification de sprint
● Revue de sprint
● Disponible pour répondre aux questions
venant de l'équipe

8. Proxy Product Owner : PPO
2 cas d'utilisation

9. Proxy Product Owner
Soutien de Scrum
P

10. #1 Proxy PO pour compenser
● Le Product Owner n'est pas en place
● Progression en 9 étapes de l'organisation
projet
● Révélation d'un Product Owner

11. #1.0 Constat
● Equipe Scrum de développement prête
● Projet doit démarrer
● ScrumMaster prêt mais problème de
backlog produit
● PO pas formé et pas disponible

12. #1.1 Phase 1
● le scrum master a élaboré un backlog
● le scrum master fait intervenir un autre
scrum master
● le SM 1 devient PPO
● le projet scrum doit suivre son cours car
l'équipe de développement est prête et
disponible
2
P

13. #1.2 Phase 2
● le PO est présent mais participe seulement
à la priorisation
● le PPO fait les taches de grooming
● l'équipe scrum ne reconnait que le PPO
P

14. #1.3 Phase 3
● le PO ayant pris trop de distance
● le PO perd la vision de son produit et ce
qu'il devient
● les utilisateurs ne sont pas impliqués par le
PO

15. #1.4 Retrospective Release
● demo : les utilisateurs remettent en cause
le PO
● le PO ne connaît pas son produit
● Le PO n'est pas reconnu par l'équipe de
développement
● le PPO tient le backlog
● PPO / SM devait aussi développer P

16. #1.5 Retour à Scrum
● formation du PO
● disponibilité du PO
● présence du PO
● objectifs sur la 2eme release partagés

17. #1.6 Phase 4
● PO aux cérémonies
● PO exprime les Tests d'Acceptance
● PO donne les priorités
● PPO pour la rédaction des US
P

18. #1.7 Phase 5
● PPO redevient ScrumMaster
● PO besoin de tracer ses demandes
● Besoin d'un outil pour palier l'absence
● PO utilise IceScrum pour rédiger US, Bugs
P
2

19. #1.8 Demo Release
● demo par le PO
● equipe scrum présente avec son SM
● vision release 2 partagée par PO

20. #1.9 et après quelques sprints
● Adoption totale de Scrum
● Utilité reconnue du planning poker
● Utilisation des users points pour
commander les travaux futurs
● PO ne voit plus autrement : Révélation

21. Proxy Product Owner
Renfort de Scrum
P

22. #2 Proxy PO pour renforcer
● Organisation sensibilisée voire formée
● Experts métiers et responsables projet
inscrits dans le même objectif de réussite
● Impliquer les exploitants et les
responsables qualité
● Mettre en place une organisation « scrum
de scrum » référencée comme un standard

23. #2.0 Constat
● PO formé par un coach agile
● stakeholders formés par un coach agile
● Scrum nouveau dans le référentiel Qualité
● 2 produits interconnectés à développer en
parallèle

24. #2.1 Phase 1
● présenter un Plan De Développement
(PDV) incluant Scrum et tous les acteurs
● impliquer tous les acteurs principaux
● Scrum de Scrum sur le fond
● introduction du PPO : PO proche de
l'équipe de développement
● stakeholders impliqués sont PO

25. #2.2 Phase 2
● appliquer le PDV
● initié le Scrum de 1er niveau P
● réunion PO / PPO pour faire émerger un
backlog
● itérer pour obtenir des backlogs produit
aptes à partir en développement
● intégrer les acteurs de l'exploitation

26. #2.3 Phase 3
● Scrum de 2nd niveau
● début du développement
● lancement des features du PROD1
● 3 sprints de rodage avec PPO1 et PO1
P
1

27. #2.4 Retrospective Release
● alléger le process standard
● trouver un formalisme pour les Tests
d'Acceptance
● bons résultats : adhésion des utilisateurs
● décision lancement PROD2
P
2

28. #2.5 Phase 4
● lancement des sprints du PROD2
● réunions avec PPO1/PO1 + PPO2/PO2
● backlog compliqué et pas forcément bien
priorisé
● problème de dépendances des 2 produits
P P
1 2

29. #2.6 Phase 5
● après plusieurs sprints, on sépare les 2
produits en 2 équipes
● sprints des 2 produits synchronisés mais
réunions indépendantes
● synchronisation des backlogs entre
POi/PPOj
P P
1 2 1s

30. #2.7 Phase 6
● indépendance des 2 produits
● favoriser les Tests d'Acceptance propres
au produit
● formalisme de Test d'Acceptance en
évaluation
● taches de grooming par SM
● problème stabilité US dans un sprint selon
le produit

31. #2.8 Phase 7
● 2 physionomies différentes
● PPO1 suit le projet mais PO1 joue son rôle
● PPO2 joue bien le rôle de product owner,
PO2 peu impliqué
P P
1
≠ 2

32. #2.9 et après ...
● Finalement le PO et PPO tendent à
disparaître pour laisser place à un PO et
un responsable utilisateur
● Apparition d'un Super PO pour coordonner
le backlog produit

33. Questions ?