Le planning d’itération ou sprint planning est une étape cruciale pour toute équipe Scrum. C’est là qu’elle conçoit, organise et planifie le travail à réaliser pour la durée du sprint. C’est également l’occasion pour l’équipe de travailler en collaboration avec le Product Owner pour s’assurer que tout le monde est aligné sur la trajectoire du produit/projet.
Il est impossible selon moi de garantir la réussite d’une itération mais toute l’équipe peut s’en rapprocher et limiter considérablement les risques en posant les bonnes questions, notamment au Product Owner. Dans cet article, je vous présente 8 questions clés auxquelles un Product Owner devrait pouvoir répondre.
1. Quel est le but de l’itération à venir et comment s'aligne-t-elle sur les objectifs à long terme du produit ?
L’objectif de cette question est de vérifier qu’au-delà des éléments de backlog qui sont prévus, il y a un but, un pas à franchir pour le produit / le projet. Ce sera plus facile de répondre à cette question en début de produit/projet (phase où il y a plus de fonctionnalités à construire) mais plus compliquée pour des équipes qui gèrent une multitude de petites demandes ou simplement de la maintenance. Dans tous les cas, le but d’une itération (d’un point de vue du produit ou du projet) n’est jamais formulé en : « Le but de l’itération est de terminer ce qui est prévu » pour la simple et bonne raison que ce but ne donne aucune indication sur le produit/projet et se concentre simplement sur la planification.
2. Quels sont les critères d'acceptation pour les besoins priorisés du backlog et qui seront embarqués dans cette itération ?
La grande question classique mais qu’il est bon de rappeler. Quelle est la définition de “Terminé” pour chacun des éléments du backlog ? Même si bien souvent c’est le Product Owner qui se charge de la rédiger, de nombreuses équipes sont compétentes pour l’écrire et soulager l’agenda des Product Owner qui est souvent surchargé. Si les critères d’acceptation d’un élément de backlog sont délicats à établir, alors ma suggestion aux équipes est simple : n’embarquez pas cet élément de backlog dans l’itération et reportez-le à une itération ultérieure. Une autre proposition pourrait être : faites le maximum et quel que soit le résultat, il sera accepté. Une stratégie efficace notamment pour les fonctionnalités qui sont encore floues.
3. Les solutions métier et techniques sont-elles discutables ou fixées ?
Une question hautement critique et qui va déterminer la dynamique de l’équipe ! Si vous voulez une équipe d’exécutants, donnez-leur des problèmes à résoudre et fixez les solutions. Leur marge de manœuvre sera limitée.
Si vous voulez une équipe qui réfléchit et qui se responsabilise (à condition que ce soit ce qu’elle souhaite), alors amenez simplement des besoins et des critères d’acceptation métier en restant évasif sur le « comment ». Attention, je ne parle pas d’être binaire (soit une option, soit une autre). Il me semble au contraire que certains besoins doivent répondre à des contraintes très spécifiques presque non discutables, là où d’autres besoins peuvent laisser la place à la créativité. Poser cette question, c’est chercher en équipe où fixer le bon curseur de l’autonomie.
4. Quel est votre niveau de disponibilité pour les questions et les demandes de clarification pendant l’itération ?
Peu d’équipes terminent un sprint planning en ayant la certitude de s’être compris à 100%. En pratique le principe de réalité remplace les efforts de préparation théoriques d’une itération. Une équipe aura certainement besoin de lever des doutes, clarifier certains aspects ou valider une option inenvisagée. L’équipe doit pouvoir compter sur son Product Owner. Elle fait des efforts pour concevoir, estimer et planifier son itération mais qu’en est-il du Product Owner ? Saura-t-il aussi se projeter et répondre présent ? Il vaudrait mieux en théorie mais, en pratique, combien de Product Owner sont pris dans un tourbillon de réunions et sont “multiprojets” ?
5. Que faisons-nous des travaux non terminés de l’itération précédente ?
Si en théorie, une équipe Scrum devrait arriver à cette perfection qui consiste à réaliser exactement ce qu’elle avait prévu, force est de constater qu’à nouveau la réalité du terrain nous rattrape. Quelle équipe n’a pas déjà eu à gérer un reliquat d’itération ? Des éléments de backlog « presque finis » mais qui nécessitent presque rien en travail ? 🙂 Cette question aurait du être tranchée en revue d’itération mais mieux vaut se la poser pour être certain que tout le monde est bien aligné avec la décision. Car un petit peu de travail + un petit peu de travail + … Ça peut représenter une bonne partie de l’itération parfois.
6. L’équipe doit-elle se concentrer sur un élément de backlog en particulier ? Si oui, le(s)quel(s) ?
Il y a les priorités du backlog évidemment mais il y a aussi des évènements externes. Le produit/projet vit aussi parfois au-delà du rythme des itérations : évènement, salon, communication, campagne marketing, démonstration commerciale, … Autant de raisons qui peuvent influencer l’organisation du travail de l’équipe et la planification des tâches qui en découle. Un Product Owner connaît ces évènements à l’avance pour ne pas lui-même les subir et les faire subir à l’équipe. Toute ressemblance…
7. Y a-t-il des dépendances avec d’autres produits/projet de l’organisation ?
Cette question est particulièrement adaptée aux projets complexes impliquant plusieurs équipes interdépendantes (en d’autres termes pour les équipes qui ne peuvent pas gérer leur plan de développement de A à Z avec un collectif de 9 personnes maximum). Ces situations sont nombreuses : comme il est prévu une revue d’itération (pendant laquelle la démonstration aura lieu), il peut être bon de se redonner les dépendances avec les autres équipes. Ces synchronisations impliqueront des coûts inévitables qu’il ne faut jamais sous-estimer – mais on les sous-estime toujours de toute façon 🙂 – Avant de clôturer cette question, vous pourrez ajouter : « Qui sera le référent de chaque dépendance ? Le Product Owner ? Le Scrum Master ? Quelqu’un d’autre ? »
8. Les priorités fixées peuvent-elles être considérées comme fiables et stables ?
Cette question sera particulièrement utile pour toutes les équipes qui évoluent dans de contexte “un peu trop agile” où les changements de priorités, les urgences et les facéties de feuille de route sorties du chapeau sont monnaie courante. Dans l’idéal, les priorités ne bougent pas et sont fixes pour la durée de l’itération. Mais parfois il vaut mieux anticiper et se préparer à un changement de plan en cours d’itération. C’est la vie, c’est aussi ça l’Agilité. Attention toutefois à ce que les exceptions ne deviennent pas la règle. Dans mon article « 3 choses que Scrum n’aime pas », j’explique que la variabilité permanente en cours d’itération est à éviter, ou alors ça s’appelle du flux et Kanban sera sans doute recommandé pour votre équipe.
Pour conclure, la planification d’itération est une étape cruciale dans un développement itératif type Scrum (ou équivalent). Les 8 questions présentées dans cet article peuvent aider les équipes à se préparer de manière efficace pour leur itération à venir. C’est pour ces raisons (mais pas que) qu’un sprint planning prend du temps, souvent plusieurs heures. En répondant à ces questions avec soin, en impliquant tous les membres de l’équipe (Product Owner compris), vous faites un pas de plus dans l’amélioration de la communication et de la collaboration de l’équipe pour faire un bon produit/projet.
Je vous souhaite de joyeux sprint planning 🙂
