Archive

Posts Tagged ‘estimation user story’

Le gestionnaire agile dans les lignes de tir

June 10th, 2010 6 comments

Coincé entre sa direction qui ne comprend pas encore les enjeux et les répercussions de la mise en place d’une approche de gestion de projet agile  et son équipe qui maintenant prend ses responsabilités, le manager d’une équipe agile reçoit des balles de toute part.

Bien entendu, tout le monde ne souhaite qu’une chose, réussir le projet. Cependant, les 3 protagonistes n’ont pas le même point de vue sur ce projet. Ils n’ont pas les mêmes connaissances de l’ampleur, du détail et de la difficulté de l’ouvrage. Ils n’ont pas non plus les mêmes besoins aux mêmes moments pour se rassurer (ou être rassurer) sur les chances de réussite ou sur la santé du projet.

Le gestionnaire agile dans les lignes de tir

Le gestionnaire agile dans les lignes de tir (photo by http://www.flickr.com/photos/mashleymorgan)

Lorsque qu’après avoir convenu qu’une première livraison de 2 mois permettrait de lever les risques et d’obtenir une ‘tranche’ verticale de logiciel fonctionnel, afin estimer de façon plus sereine le reste du projet, la direction décide de demander à l’équipe de réestimer la totalité du backlog après seulement 1 mois de travail, la fusillade éclate et le gestionnaire ou manager agile se retrouve dans les lignes de tir.

Satisfaire la demande de la direction ou soutenir l’équipe qui est tout à fait d’accord de réestimer le backlog, mais seulement après la release, une fois qu’elle aura l’information pertinente qu’elle cherche à obtenir.

C’est à ce moment là que le manager « au service de l’équipe » devrait faire son apparition. Être au soutient de l’équipe et l’éducateur de la direction.

Il doit être en mesure de répondre clairement aux interrogations des uns et des autres et d’expliquer à chacun les besoins de l’autre comme par exemple :

  • Pourquoi la direction veut-elle une réestimation maintenant? Y a-t-il un besoin concret qui échappe à l’équipe comme par exemple une communication stratégique ou bien est-ce simplement une crainte, une insécurité générée par les nouvelles façons de faire, le nouveau reporting?
  • Peut-on patienter encore quelques semaines? Admettons que les estimés préliminaires sont faux. Normal, ce sont des estimés! Ceux d’aujourd’hui, réalisés avec des connaissances encore incomplètes sur des risques identifiés, ne seront-ils  pas aussi faux? Seront-ils plus pertinent s’ils sont établits dans 4 semaines une fois les risques levés?
  • Pourquoi l’équipe ne souhaite-t-elle pas réestimer maintenant? A-t-elle peur? Refuse-t-elle de communiquer, d’être transparent vis-à-vis de la direction? Pense-t-elle que l’investissement à ce moment donné n’est pas rentable? Manque-t-il des informations nécessaires?

Les arguments de tous seront valables. Alors que doit faire le manager? Rester au milieu et prendre les balles? Ne satisfaire personne? Ou bien se positionner et prendre le risque de décevoir sa direction ou son équipe?

Pour ma part, je pense que le calcul à faire est celui du succès de l’équipe. Est-ce qu’une journée d’estimation rapporte plus qu’une journée à coder pendant laquelle on apprend sur les risques techniques que l’on doit affronter? À certains moments peut-être, à d’autres non. Ce qui est certain c’est qu’une équipe frustrée qui ne se sent pas soutenue, est moins productive et performante.

Faire le calcul de répondre à la demande de la direction sans tenir compte de l’équipe est peut-être bon pour la carrière, mais n’est pas le meilleur moyen d’aboutir à une équipe auto-organisée, performante, motivée et responsable. Il est plus pertinent d’éduquer la direction, de la rassurer, de lui expliquer que l’équipe ne juge pas pertinent de réévaluer maintenant mais qu’elle le fera dès que possible et qu’il faut lui faire confiance. Il est aussi judicieux d’expliquer qu’en Scrum cette (ré)estimation est permanente et fait partie du cadre.

Vous serez peut-être intéressés par ce précédent billet :

Faut-il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?

June 3rd, 2010 6 comments

À maintes reprises ces derniers mois, j’ai dû répondre à la question qui tracasse beaucoup d’équipes et de Product Owner (PO) lorsqu’ils viennet d’échouer une ou plusieurs stories :

Faut-il réestimer les stories refusées lorsqu’on les prend dans l’engagement du sprint suivant?

Je demande alors ce qui fait sens pour eux. Quelle information tirent-ils de l’estimation d’une storie? Qu’est-ce qui serait le plus pertinent pour réussir le prochain sprint puisque le dernier vient d’échouer?

Les réponses varient bien évidemment, mais le plus important est alors de déclencher avec l’équipe une conversation autour de la notion de vélocité1, de son utilité, de son utilisation. Cette discussion ne fait pas l’objet du billet d’aujourd’hui mais j’y reviendrai éventuellement (au sens québécois du terme 😉 ) dans un prochain billet.

Burndown en story point - Faut-il réestimer les stories non terminées ou refusées à la fin du sprint?

L'allure générale du burndown va varier en fonction de votre façon de gérer les stories échouées à la fin d'un sprint

Aujourd’hui je souhaite principalement partager ma pratique actuelle. Je dis actuelle car ma réflexion et ma préconisation ont évolué au cours du temps.

Actuellement, au moment de la planification d’un sprint, je préconise à l’équipe de réestimer les stories et de mettre à jour le backlog pour refléter l’effort nouvellement évalué. Cette façon de faire à les effets  suivants :

  • lisser la vélocité,
  • réduire le volume global du backlog, (sur l’instant bien entendu car j’exclus ici la création de story ou la réévaluation de story précédemment estimées, etc),
  • perdre l’historique de l’effort initialement estimé pour la story.

Dans le passé, je ne réestimais pas les stories au moment du sprint, l’équipe évaluait ou plutôt devrais-je dire pariait, comme pour un premier sprint, sur le ‘volume’ des stories qu’elle pensait être capable de réaliser. Cette façon de faire avait les effets suivants :

  • générer des fluctuations parfois importantes de la vélocité, pour finalement calculer une moyenne sur le long terme,
  • rendre l’engagement très aléatoire, l’équipe n’avait pas de repère (vélocité précédente) et pariait sur un engagement, comme lors d’un tout premier sprint,
  • conserver le volume du backlog tel qu’initialement estimé (sans faire entrer ici d’autres considérations telles que la réestimation des stories déjà estimées au cours des planifications de release précédentes, la division d’une story en plusieurs, la création de stories,…),
  • maintenir l’historique de l’effort estimé pour la story.

J’ai aussi vu une troisième méthode qui consistait à réestimer ‘oralement’ le reste-à-faire (en story points), mais sans mettre à jour le backlog. Cela permettait de prendre un engagement raisonnable car il incluait le nouvel effort estimé, mais l’engagement affiché était lui très généreux, reprenant l’effort estimé au sprint passé et non mis à jour!

Comme je vous le disais plus tôt la discussion autour de la notion de vélocité était intéressante. Pourquoi réestimer sans mettre le backlog à jour? Mystère! Un bon sujet pour un prochain billet. 😉

Afin de partager vos pratiques, je vous propose de répondre au sondage suivant. Et surtout n’hésitez pas à partager votre expérience en laissant un commentaire.

Comment gérez-vous les stories refusées par le PO lors de planification du sprint suivant?

  • Je réestime et réajuste le pointage au backlog et je m'engage par rapport à ma vélocité connue (57%, 27 Votes)
  • Je ne réestime pas les stories et je 'parie' sur l'engagement (15%, 7 Votes)
  • Je réestime "oralement" pour maîtriser l'engagement mais je garde le pointage inchangé au backlog (13%, 6 Votes)
  • J'utilise une autre méthode (9%, 4 Votes)

Total Voters: 47

Loading ... Loading ...
  1. La vélocité d’une équipe est le nombre story points du backlog brûlés pendant un sprint

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 ;-)! 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! 😉

  1. time-box

tous_assis_devant_un_écran VS debout_devant_le_mur_avec_des_Post-it!

April 1st, 2010 3 comments
 Le match du jour : tous_assis_devant_un_écran VS debout_devant_le_mur_avec_des_post-it by Dunechaser http://www.flickr.com/photos/dunechaser/

À ma droite "tous_assis_devant_un_écran" et à ma gauche "debout_devant_le_mur_avec_des_post-it"

Le match du jour oppose les tous_assis_devant_un_écran à l’équipe debout_devant_le_mur_avec_des_Post-it!
Le cri de guerre de cette dernière résonne encore!

« Lâchez votre écran lors du découpage en tâches des User Stories! Levez vous et aimez les Post-it! »

Ces dernières semaines j’ai assisté à de nombreuses séances de planification d’équipes Scrum. Après avoir estimé les User Stories, et s’être engagée, l’équipe attaque le découpage en tâches. La constante, pour la plupart des équipes, est le manque cruel d’énergie et l’ambiance morose qui règne pour ne pas dire l’apathie.

À chaque fois j’entends des plaintes ressemblant à la suivante : « C’est long, c’est plate, on bâcle ça pour être débarrassés. Mais du coup, pendant l’itération nous sommes obligés de revoir le découpage, et nos estimations en heure sont souvent mauvaises (sous-estimées) »

En observant le fonctionnement de ces équipes lors de leur séance de planification, je comprends mieux pourquoi « c’est long et plate! ». Les équipes sont assises autour d’une table au milieu de laquelle trônent vidéo-projecteur et ordinateur portable, ce dernier étant piloté la plupart du temps par le ScrumMaster. Tout le monde regarde l’écran projeté diffusant l’interface du logiciel de gestion du carnet de produit dans lequel le ScrumMaster ajoute les tâches en direct.

S’il vous plaît, si vous êtes colocalisés, arrêtez d’utiliser votre outils de gestion de carnet de produit lors de la séance de découpage en tâches des User Stories. Tout le monde s’ennuie pendant qu’une seule personne utilise le clavier. Si en plus, votre outil n’est pas ergonomique et ne permet pas d’accompagner le flux d’idées de façon efficace, la seule chose que vous obtenez ce sont des coéquipiers qui ‘décrochent’ et s’endorment petit à petit.

En plein milieu d’une séance, j’ai demandé à l’une des équipes tous_assis_devant_un_écran de tout arrêter et de d’aller chercher des Post-it puis de faire le découpage à la façon de l’équipe debout_devant_le_mur_avec_des_Post-it!

Vous me croirez ou pas, mais il n’y avait pas de Post-it dans la pièce! Et même une fois les petites feuilles de papier jaune et collantes entre les mains, personne n’avait de stylo pour écrire dessus!

Mais, une fois ses membres équipés de stylos, le résultat de l’équipe debout_devant_le_mur_avec_des_Post-it a été fantastique. L’équipe s’est réveillée. En quelques minutes, tout le monde était autour de la table ou proche du mur et participait activement à la conversation.

En révisant les tâches afin de les (ré)estimer, debout_devant_le_mur_avec_des_Post-it les à réajuster, à trouver des tâches manquantes et à éliminer celles devenues superflues du fait de la réorganisation du travail.

Bref, un vrai plaisir de voir l’équipe debout_devant_le_mur_avec_des_Post-it écraser par KO les tous_assis_devant_un_écran.

Dans votre équipe, comment se passe le découpage en tâchess des User Stories de l’itération? Est-ce un meeting dynamique et plaisant à la debout_devant_le_mur_avec_des_Post-it ou bien un meeting des plus ennuyeux à la tous_assis_devant_un_écran?

Quelles sont vos astuces pour rendre les séances de découpage efficaces et intéressantes.