Archive

Posts Tagged ‘propriétaire de produit’

Estimer un carnet de produit complet en 2 heures : Wall Planning Poker

April 8th, 2010 2 comments

En quelques semaines, j’ai eu l’opportunité d’animer à plusieurs reprises un atelier d’estimation de l’ensemble d’un carnet de produit.

Le but de cet atelier, aussi appelé Wall Planning Poker®, est d’estimer de façon relative un grand nombre de User Stories en un temps limité1.

Cet atelier est basé sur l’estimation en Planning Poker lors des séances de planification d’itération, cependant, l’équipe n’utilise pas les cartes de planning poker, elle réalise l’estimation en plaçant les User Stories au mur (ou sur une grande table) par rapport au nombre de points évalués. On insiste évidemment beaucoup le côté relatif de l’estimation. Le but de l’exercice, je le rappelle, est d’obtenir une idée de l’ampleur du carnet de produit.

Certes, avec une estimation rapide l’équipe va faire des erreurs, et c’est normal! D’ailleurs, n’en fait-elle pas lors de l’estimation des User Stories pour une seule itération? Pour abaisser le risque d’erreur, l’équipe choisit des User Stories étalons qu’elle révise et publie chacun dans leur “case” respective au mur. De plus, par expérience, j’estime que les cartes surévaluées compensent globalement les cartes sous-évaluées.

Un élément important à la réussite de l’atelier est de passer à l’équipe le message clair que l’estimation n’est pas définitive. Lorsque les User Stories seront inclues dans une itération, elles seront réévaluées par en fonction des éléments d’information acquis à ce moment là. (Mesdames, Messieurs les propriétaires de produit, ce message est aussi pour vous!)

Une fois les étalons établis et les messages passés sur l’estimation relative et non définitive c’est le moment de s’y mettre.

Prévoyez au moins 2 heures pour l’atelier. Si l’équipe n’a jamais estimé auparavant, prévoyez de passer du temps pour établir les premières estimations et obtenir  ainsi vos étalons. Je vous conseille d’ailleurs, dans ce cas, de séparer l’évaluation “détaillée” d’une première itération de l’atelier proprement dit, l’équipe ayant l’opportunité de construire ainsi ses étalons.

Même s’il est préférable que tout le monde participe simultanément à l’estimation de toutes les User Stories, j’ai remarqué dans la pratique que la constitution d’équipes de 4 à 5 personnes est plus efficace. Pourquoi? Pour les deux raisons suivantes principalement :

  • Les discussions dans un groupe 4 ou 5 personnes sont plus riches et surtout moins longues.
  • La division permet de faire une revue de l’estimation de chacun des groupes par un autre groupe.

Comment se déroule l’atelier?

  1. Constituez des équipes de 4 ou 5 personnes multidisciplinaires et multicompétences. Insistez sur le fait de bien répartir les connaissances et compétences dans les équipes.
  2. Distribuez à chacune des équipes des cartes sur lesquelles vous avez imprimé les User Stories du carnet de produit. Essayez dans la mesure du possible de séparer les cartes en conservant groupés les Épics ou les processus. Cela facilite souvent l’estimation du fait de bénéficier de la vue globale de la fonctionnalité. Pensez à vous assurez que si la boîte de temps achève, les User Stories les plus prioritaires auront été estimées.
  3. Chaque équipe bénéficie du temps préalablement déterminé (prévoir 1h à 1,5h) pour classer les cartes au mur. Dans le cas de plusieurs équipes réalisant l’exercice simultanément, avoir trop de monde près du mur peut être gênant. Dans ce cas proposez aux équipes d’utiliser une table avant de reporter leurs cartes au mur.
  4. Une variante de l’exercice consiste à ne pas affecter de points aux cartes tout de suite. Il est intéressant de classer les cartes par rapport à l’effort relatif pour réaliser la fonctionnalité, puis, une fois toutes les cartes évaluées réaliser le pointage au mur.
  5. Une fois toutes les User Stories estimées au mur, demandez à chaque équipe de revoir les cartes pointées par les autres équipes (donner comme consigne, au début de l’atelier, à chaque équipe d’identifier les cartes qu’elle évalue par un signe distinctif). Chacune des équipes restant bien entendu à la disposition des autres pour expliquer un choix. S’il s’avère nécessaire, après discussion, de déplacer des User Stories, faites-le! L’avantage de cette pratique au delà de permettre un croisement des estimations, est de générer des discussions avec tous les participants et de vérifier que chaque équipe est restée proche des estimées étalons. Prévoyez 30 min à 45 min pour cette partie de l’atelier.
  6. Pour conclure l’atelier, comme pour tout atelier ou pour toute réunion importante, prévoyez 15 minutes pour une petite rétrospective.

Le résultat de cet atelier est spectaculaire. Il donne à l’équipe une vue globale du carnet de produit et permet au propriétaire de produit de planifier les futures livraisons, de construire un roadmap. Il permet aussi d’évaluer la faisabilité du projet par rapport aux dates envisagées et de prendre des décisions éclairées sur la stratégie à mener pour réussir vos projets. Cela est d’autant plus vrai et plus pertinent que vous connaissez la vélocité de votre équipe.

Si vous avez des expériences à partager concernant cet ateliers ou des ateliers similaires, laissez-moi un commentaire icon wink Estimer un carnet de produit complet en 2 heures : Wall Planning Poker ! Si vous avez des questions écrivez-moi (tbalbous à pyxis-tech point com)

Si vous avez besoin d’aide, je serai ravi de venir animer cet atelier dans votre équipe. Contactez moi! icon wink Estimer un carnet de produit complet en 2 heures : Wall Planning Poker

  1. time-box

Une équipe Scrum peut-elle vivre sans ScrumMaster ‘officiel’ ?

January 14th, 2010 Comments off
equipe peut elle vivre sans scrummaster officiel 150x150 Une équipe Scrum peut elle vivre sans ScrumMaster officiel ?

Une équipe peut-elle vivre sans ScrumMaster 'officiel'?

L’été dernier j’ai rejoint un projet qui avait démarré 15 mois auparavant. L’équipe chargée du développement était répartie entre 3 sites (1 à Montréal, 2 à Bordeaux). Peu après mon arrivée, il y a eu réorganisation des équipes, et dans notre équipe, nous avons proposé de ne pas avoir de ScrumMaster ‘officiel’. La question suivante se posait donc pour nous :

Une équipe Scrum peut-elle vivre sans ScrumMaster ‘officiel’?

Je dois dire tout de suite que nous n’avons pas eu le loisir de pousser très loin l’expérimentation car le projet a été interrompu environ 6 semaines après la réorganisation. Nous avons tout de même travaillé avec ce modèle pendant 2 itérations1.

Cette équipe était composée de 3 personnes. Deux étaient présentes depuis longtemps : depuis le début pour l’un et depuis 10 mois pour l’autre. Puis il y avait moi, nouveau sur le projet. Le coéquipier leader naturel travaillait depuis plusieurs mois sur le module dont nous avions la charge. Il y avait une bonne cohésion, nous étions à l’aise avec Scrum et nous nous sentions en contrôle!

Nous tenions notre mêlée quotidienne2 sans difficultés. Nous allions à tour de rôle à la mêlée des mêlées3 — cette pratique était déjà en place  bien avant la réorganisation. Nous faisions la maintenance du carnet de produit4 régulièrement avec le propriétaire de produit5. Nous aidions tous à l’organisation de l’équipe, même si une très grosse partie du travail était réalisée par le leader de l’équipe.

Voici les avantages obtenus lors de ce projet

  • Nous nous sentions vraiment autonomes. Nous organisions nous même nos rencontres importantes (mêlée quotidienne, maintenance du carnet de produit, réunion avec les intervenants extérieurs).
  • Nous étions beaucoup plus responsables. Lorsque quelque chose allait de travers, nous ne pouvions pas dire :  «Le ScrumMaster ne fait pas son boulot ».
  • Nous avions une bonne flexibilité, mais ce point relève petut-être du fait que nous n’étions que trois.
  • Contrairement à ce que j’ai vu à maintes reprises, personne dans l’équipe n’était perçu comme ‘supérieur hiérarchique’.

Nous n’avons pas subi d’inconvénients, mais peut-être y en aurait-il eu à long terme.

Cependant je suis convaincu d’une chose : il y a un préalable. Cela peut fonctionner à la condition que l’équipe soit mature, tant sur le plan des personnes qui la compose que  sur le plan de la maîtrise des outils, du processus Scrum et de la communication. Je vous invite à lire, sur un thème similaire, le retour d’expérience d’Isabelle Therrien, où elle fait mention des dérives qui peuvent se produire. Dans les commentaires notamment, il est question de prendre du recul, ce qui n’est pas toujours simple quand on a la tête dans le code pour livrer de la valeur à longueur de journée.

Résumé en quelques lignes, le choix de ne pas avoir de ScrumMaster ‘officiel’ peut paraître rapide ou évident, mais tout ceci ne s’est pas décidé en un jour. De fait, même une fois en place, les questionnements suivants revenaient de façon récurrente dans nos conversations :

  • S’il fait fonction de ScrumMaster, le leader doit-il prendre le titre et s’exposer?
  • Ce rôle peut il être partagé, et dans ce cas, est-ce efficace?

Pour conclure, je dois dire que j’ai aimé cette expérience. Même si cela n’a pas duré bien longtemps, j’ai vu les prémices de quelque chose que je voulais vérifier depuis longtemps : « le rôle de ScrumMaster est un rôle temporaire, il a pour objectif de rendre son équipe capable de se passer de sa présence, et cela peut fonctionner ».

Avez-vous des retours d’expérience similaires à partager ?

  1. Itération : Sprint
  2. Mêlée quotidienne : Daily Scrum
  3. Mêlée des mêlées : Scrum of Scrums
  4. Carnet de produit : Product backlog
  5. Propriétaire de produit : Product Owner