Préparer le PRÊT - Itérer jusqu'à TERMINÉ
Auteur : Serge Beaumont
Source : Flow to READY, Iterate to DONE
Date : 04/07/2009
Traducteur : Fabrice Aimetti
Date : 13/07/2009
Traduction :
Lors d'un précédent billet, j'ai introduit la définition de PRÊT. Préalablement au présent billet, je souhaitais en écrire un sur la différence entre les notions de flux ("kanban") et d'itération. Cependant, j'avais beaucoup plus à dire que prévu sur le sujet qui a finalement pris une toute autre dimension. Je rassemblerai mes idées plus tard et cela fera l'objet d'un autre billet. Soyez donc un peu patient avec moi : je trouve que le travail de Product Owner est beaucoup mieux réalisé en adoptant la notion de flux. Et puisque mon collègue Lars Vonk m'a dit qu'il attendait de lire ce billet, j'expliquerai ici juste comment s'y prendre. Lars, on peut démarrer... :)
Les items d'un backlog ne sont pas tous égaux. Un item de backlog commence sous la forme d'une ébauche (la classique strophe "En tant que... Je veux... Pour...") et nécessite d'être détaillé jusqu'à ce qu'il soit positionné dans un sprint par l'équipe. Un Product Owner gère un workflow de la même manière qu'une équipe pour Terminer ses tâches. Scrum ne dispose d'aucun support spécifique pour le Product Owner : d'une manière ou d'une autre, le Backlog Produit "apparaît" d'un seul coup. Dans ce billet, je vais essayer de combler cette lacune concernant le processus que peut suivre un Product Owner.
Je présenterai un mode de partitionnement du backlog appliqué à la notion de flux, la nature de ces partitions et la manière de procéder pour obtenir suffisamment de choses Prêtes pour que l'équipe les sélectionne dans le Sprint suivant.
Préparer le PRÊT
Le flux de travail consiste dans la définition de nouveaux items par le rôle Product Owner, leur préparation pour qu'ils soient PRÊTS, leur sélection par le rôle Équipe pour qu'ils les TERMINENT. Notez que je parle explicitement de "rôle" ici : les membres de l'équipe ont un rôle à jouer pour soutenir le rôle Product Owner à définir et préparer des items PRÊTS.
Partitionner le backlog
Un backlog peut être grossièrement partitionné en 4 régions basées sur le flux de travail :
- les items dans le Sprint en cours,
- les items dans l'état Prêt,
- les items en cours de préparation pour être Prêts, et
- le reste : nouveaux besoins.
Évidemment, il s'agit d'une vision idéalisée des choses. Dans la pratique, les choses sont plus nuancées parce que les priorités associées aux différentes étapes du workflow ne sont pas aussi nettes que vous le souhaitez. Les nouveaux items peuvent avoir une très haute priorité et venir s'insérer dans les items PRÊTS. D'un autre côté, cette façon de voir le backlog peut vous aider à respecter l'ordre des priorités : quelque chose de PRÊT peut par définition avoir une priorité plus haute que quelque chose qui n'est pas dans cet état.
Du partitionnement au flux
Si nous reconsidérons les différentes étapes du flux précédemment décrit et que nous les mettons côte à côte, nous obtenons :
Le fait d'utiliser la même couleur pour "Nouveau" et "Prêt", et une autre couleur pour "En préparation" et "Dans le Sprint actuel" n'est pas une coïncidence. "Nouveau" et "Prêt" sont des buffers priorisés, "En préparation" et "Dans le Sprint actuel" sont des tâches en cours (Work-In-Progress). Parcourons le flux étape par étape.
Buffer priorisé : Nouveau
Les items du backlog dans l'état Nouveau sont ceux que vous n'avez pas encore traités, en tout cas pas suffisamment pour qu'ils soient PRÊTS. Malgré tout, en pratique, j'ai constaté qu'il est sage d'effectuer un tri minimum sur ces items : si vous avez des idées dans tous les sens, vous serez très vite submergé par une avalanche d'items. Les parties prenantes ont tendance à dire "J'ai un millier d'idées !", mais la plupart d'entre elles sont juste des idées. Seule une petite portion de ces idées sont vraiment réalistes et utiles à implémenter. Ce tri initial devrait être simple, mais il requiert déjà une certaine discipline de la part des parties prenantes pour analyser leurs besoins. Ne vous inquiétez pas trop des plaintes des parties prenantes, en général une partie prenante appréciera toujours de savoir ce qu'elle peut faire pour que ces besoins soient pris en compte. Pour qu'un item soit pris en compte dans le backlog Nouveau, une partie prenante devrait fournir les informations suivantes :
- une story, uniquement en termes d'expérience métier, qui décrit leur expérience et leur besoin sans mentionner la manière dont le produit l'implémentera
- la classique strophe de la user story (En tant que... Je veux... Pour...)
- une (grossière) évaluation du bénéfice
- une grossière indication de la taille (c-à-d le coût) : petit, moyen, grand. (Notez que l'estimation est meilleure lorsque le membre de l'équipe ou le product owner ont discuté avec les parties prenantes qui ont plus de connaissance sur le produit attendu).
L'urgence métier vous donne un niveau grossier de la priorité, ce qui vous permet de décider quel item prendre en premier.
Tâches en cours (WIP) : Préparation
Cette étape est la plus importante pour le Product Owner : c'est le moment où l'essentiel du travail du Product Owner est réalisé.
Le Product Owner est le point d'entrée unique pour toutes les parties prenantes, et c'est bien sûr intentionnel. Il doit y avoir un seul point focal pour les exigences et les priorités, sinon cela risque d'incomber au rôle de l'équipe; le rôle Product Owner est donc tout sauf inutile. Un malheureux effet secondaire pour notre pauvre Product Owner est qu'il subit constamment les exigences et les pressions de toutes les parties prenantes. Le Product Owner tente de faire face à ce dilemme. Je pense que c'est exactement à ce moment que le style flux/kanban excelle : limiter explicitement le nombre de tâches en cours (WIP) est l'un des meilleurs outils à utiliser pour apporter un peu de bon sens dans la vie du Product Owner.
Le Product Owner traite les items dans l'étape de Préparation selon la capacité. Exactement comme une équipe qui prend du travail jusqu'à atteindre sa capacité maximale et qui ne change rien tant que le Sprint n'est pas terminé, un Product Owner prend un certain nombre d'items (j'ai constaté 2 items par personne dans le rôle de Product Owner, mais je ne sais pas s'il s'agit d'une règle générale), les traite jusqu'à ce qu'ils soient PRÊTS, et prend uniquement de nouveaux items lorsque qu'un espace se libère dans l'étape de préparation.
Le Product Owner n'a pas besoin de (et dans le plupart des cas ne peut pas) fournir toutes les informations, mais il est responsable de s'assurer que quelqu'un peut le faire, et que l'item du backlog passera dans l'état Prêt. Cela signifie que le Product Owner discutera avec les parties prenantes pour leur demander des informations, avec l'Équipe pour fournir une estimation de la complexité de l'implémentation, et avec toute personne nécessaire pour fournir de la clarté et de l'information. C'est un vrai boulot, et dans de grandes organisations, il n'est pas inhabituel de voir plusieurs personnes (souvent des analystes) tenir ce rôle.
Grâce à cette étape explicite dans le flux, il est maintenant possible de mesurer le niveau de performance du Product Owner. L'équivalent de la vélocité dans le style flux/kanban est le temps de cycle : le temps moyen nécessaire pour porter un item du backlog de l'état Nouveau à l'état Prêt. Un item bloqué dans le backlog sera facilement reconnaissable puisqu'il restera dans l'étape Préparation plus longtemps que d'habitude. Cela permet également d'estimer la capacité du Product Owner. Comparer le temps de cycle avec le nombre d'items du backlog consommés par Sprint par l'équipe, aide à déterminer si le Product Owner est assez rapide pour maintenir un bon rythme.
La vitesse du Product Owner n'est pas mesuré en story points d'items du backlog mais en nombre d'items du backlog car la quantité de travail de chaque item est grossièrement la même : chaque item requiert des questions quel que soit sa taille. De grands items de backlog nécessite peut-être plus de travail, mais dans la plupart des cas ils seront divisés en plus petites tailles gérables par l'équipe. Ceci se traduit en un plus grand nombre d'items de backlog qu'au départ. Les grands items sont refactorés de cette manière.
Lorsqu'un item du backlog est Prêt, il peut être déplacé dans la buffer Prêt.
Buffer priorisé : Prêt
J'ai trouvé très utile de considérer la liste des items Prêts comme un buffer. La productivité d'un Product Owner nécessite d'être telle que ce buffer doit être suffisamment rempli pour que le prochain Sprint commence. Observer la taille du buffer (en story points, puisque maintenant c'est la capacité de l'Équipe qui est pertinente) est un très bon moyen de voir si le Product Owner a des problèmes. Vous pouvez utiliser un burndown chart, un burnup chart, ou simplement une courbe de suivi de la taille du buffer, sachant que je pense qu'il est profitable pour un Product Owner d'accéder aux mêmes types d'information de suivi que les Équipes lorsqu'elles utilisent des burndown charts.
On distingue deux niveaux pour l'état Prêt : chaque item du backlog nécessite d'être Prêt, mais le backlog nécessite aussi d'être Prêt, juste avant le prochain Sprint. Un Backlog Prêt signifie que le buffer Ready est suffisamment rempli pour une quantité de travail équivalente à une itération, plus quelques tâches supplémentaires en cas de renégociation, décisions de dernière minute, idées ou changements de priorités. En pratique, une bonne cible est d'aller jusqu'à une quantité de travail équivalente entre 1,5 à 2 itérations. Le contraire est également vrai : si le buffer est vraiment plein, plus de 2 Sprints d'items Prêts, vous perdez probablement votre temps puisque la réalité va changer avant même que vous traitiez les derniers items du buffer (les items repassent dans l'état non prêt), vous contraignant à fournir plus de travail. Dans ce cas, il est plus intéressant d'augmenter la capacité de l'Équipe ou d'utiliser ce temps libre pour des activités de divination ou études de marché. :)
Tâches en cours (WIP) : Dans le Sprint en cours
Cette étape est bien évidemment relativement facile à décrire puisque c'est le moment où tout le matériel Scrum entre dans le paysage. :) En tant que Product Owner, vous suivrez les items du Sprint en cours, mais votre travail ne s'arrête pas là. Pour reprendre une citation employée dans la conception : "une bonne conception ne dépend pas d'une seule grande décision, mais d'une centaine de petites décisions", une Équipe a donc besoin que vous soyez présent à proximité pour les débloquer en prenant les bonnes décisions. Durant un Sprint, une Équipe vous détaillera différents scénarios d'implémentation. Souvent, ces scénarios ont un impact sur le résultat final : il pourrait y avoir une option de facilité par rapport à ce qui avait été initialement discuté, ou une partie de l'implémentation est bien plus dure que prévue. Dans ce cas, vous devez être présent aux alentours pour aider l'Équipe à avancer.
Résumé
Le backlog peut être partitionné en 4 parties que l'on peut intégrer dans un flux (style kanban). Puisque ce billet commence à être trop long, j'en rédigerai un autre pour décrire comment outiller ce processus avec un tableau Kanban et des logiciels.
