Tous s’accorde sur la pertinence d’une estimation “just bare enough”. Mais après avoir lu cet article et ses références je serais à l’aise à travailler dans une équipe qui ne veut plus faire d’estimation. A tout le moins, plus d’estimation numérique.
Quelle est l’utilité du poids d’une story? Le poids estimé nous sert à:
- Connaître la charge de travail disponible dans le backlog, pour vérifier la progression du projet.
- Mesurer la vélocité d’une équipe à un moment t, pour servir d’argument au calcul de la capacité.
- Évaluer la capacité, pour nous aider à déterminer la prochaine charge de travail sur laquelle l’équipe peut s’engager.
La finalité de l’estimation, c’est d’évaluer la capacité, dans le but de préparer le prochain sprint. La qualité de l’estimation n’augmente pas la productivité de l’équipe et n’ajoute pas de valeur au produit livré. Pire, tenter d’obtenir un estimé juste risque d’amputer sur le temps de développement. Et un estimé faux incite à la ré-estimation: une autre source d’effort et de temps.
Si on décide de ne plus baliser les sprints dans une boîte de temps, avons-nous encore besoin dévaluer la capacité d’une équipe pour planifier un sprint? Avons-nous encore besoin d’estimer les stories?
Réalisation d’un sprint et cadence de l’équipe
La notion de sprint ajoute la notion de cadence à une équipe: elle peut mesurer ses réalisations à la fin de tous les sprints. Même si le but n’est pas de rapporter le travail des développeurs, on peut quand même l’observer pour évaluer la santé et la maturité d’une équipe lors de la rétrospective. On peut aussi informer le client de la capacité de l’équipe lors de la séance de planification.
En supprimant les estimés, on ne supprime pas la notion de cadence de développement: au lieu de mesurer des points/heures, on peut mesurer des features/heures. Par exemple, une équipe de 6 développeurs pourrait avoir une vélocité de 2 features pour 2 jours. On pourrait alors prévoir que dans deux semaines, l’équipe réalisera 15 features. Inversement, si le client priorise le backlog et sélectionne les 10 premières features, l’équipe prévoira environ 7 jours pour les réaliser. Au lieu de se fixer une date de réalisation, on a fixé un périmètre avec une date approximative de livraison.
Avec un sprint limité dans le temps, trois cas de figure se présentent:
- l’équipe a réalisé le sprint en utilisant tout le temps prévu: Dans ce cas, le temps et la charge de travail sont équivalent.
- l’équipe a réalisé le sprint plus tôt que prévu: Ici, le périmètre a été sous évalué. L’équipe peut en profiter pour réduire de la dette technique (je ne relance pas le débat du pourquoi il existe une dette). Sinon, l’équipe pourrait prendre un nouvel item priorisé dans le backlog. Il n’est pas certain que l’item choisi soit le plus prioritaire. Ce choix dépendra du poids des stories et du temps disponible avant la fin du sprint. Avec un sprint balisé par le périmètre, l’équipe aurait terminé avec le dernier item planifié. Du coup, elle serait prête à démontrer leur réalisation et à planifier le prochain sprint.
- l’équipe n’a pas terminé le sprint parce que l’un de ses items était sous-évalué ou une contrainte inconnue est apparue: Mis à part le fait que l’équipe ne gagne pas ses points et qu’ils ne peuvent pas démontrer la story, il reste le problème de terminer le travail. De mon expérience, le product owner choisi habituellement de finir la story au sprint suivant. Mais pas toujours. Du coup, le projet s’endette avec un lot de “in-progress”. Si le sprint était balisé par le périmètre, l’équipe aurait terminé l’item avant de passer au prochain sprint.
Le but d’un sprint balisé par le périmètre n’est pas de réussir le lot en temps, mais de réussir le lot. Et pour mesurer la vélocité, on n’utilise plus l’unité du sprint, mais plutôt les features.
La séance de planification
En adoptant des sprints balisés par un périmètre, la séance de planification se modifie. Le but n’est plus de “remplir” des semaines de travail avec des items prioritaires mais plutôt de déterminer le prochain lot d’items prioritaires. Le résultat est semblable, parce qu’on se base sur des critères similaires: une charge de travail prévisible et réalisable que l’on puise dans un backlog priorisé.
Le client perdra l’impression d’avoir à combler tout le temps disponible du sprint. De mon expérience, lorsqu’il reste quelques points à planifier dans un sprint, le PO cherche à les combler avec de plus petite stories, parfois moins prioritaires. Même dans le cas où l’on offre une tranche de points (e.x. 35 à 45 points), le client est tenté de s’approcher le plus possible de la borne supérieure. C’est normal, puisqu’on lui présente le sprint comme un récipient à remplir d’items. En retirant la contrainte de temps, je pense qu’il est plus facile pour le PO de se limiter à ses priorités.
ROI
En balisant les sprints par le périmètre, l’estimation ne sert plus à mesurer la capacité de l’équipe ou à mesurer la progression d’un projet. Mais pour planifier son sprint, le client a toujours besoin de stories estimées pour faire ses choix en fonction de la priorité et du coût de développement. Cette estimation doit provenir d’une lecture des stories par l’équipe de développement.
La séance d’estimation semble donc toujours nécessaire pour la planification. De plus, elle est un bon moment pour augmenter le lien de collaboration entre lui et les développeurs et donner une vision à ces derniers des prochains travaux, pour leur permettre de réussir le sprint courant, avec l’objectif de réussir le prochain.
Comment réduire le coût tout en gardant les avantages de ces séances. Une solution est d’éliminer l’échelle numérique. Le problème avec une échelle numérique, c’est qu’elle permet toujours de faire des calculs et amène forcément à la planification chiffrée. C’est la même argumentation lorsqu’une équipe choisi d’évaluer en jour idéal ou en story points.
Certaines équipes utilisent plutôt un échelle T-Shirt pour évaluer les stories (e.g. S, M, L, XL). A priori, c’est suffisant pour informer le client, et assez précis pour générer des discussions entre les membres de l’équipe et le client. C’est Fibonnacci sans les chifffres!
Pour aller plus loin: le Kanban
Sans entrer dans le détail, cet article explique comment le taskboard de la méthode Scrum est une simplification du kanban.
There is a strict discipline of running Kanban, called “six rules of Kanban”:
1. Customer(Downstream) processes withdraw items in the precise amounts specified on the Kanban.
2. Supplier(Upstream) produces items in the precise amounts and sequences specified by the Kanban
3. No items are made or moved without a Kanban.
4. A Kanban should accompany each item, every time.
5. Defects and incorrect amounts are never sent to the next downstream process.
6. The number of Kanbans is reduced carefully to lower inventories and to reveal problems.
En résumé, le kanban est un modèle “pull”. Dans un contexte de développement, l’entrée dans la chaine peut être le client qui a un besoin de features. Le client (Downstream) “pull” de l’équipe de développement (Upstream) un lot de feature à livrer (Withdraw). Ensuite, l’équipe fait un “pull” dans le backlog pour obtenir les specifications des items du kanban. La granularité du kanban pourrait être un sprint ou tout simplement une feature.
C’est étrange de considérer le Scrum comme une chaîne puisque le responsable des entrées et sorties de l’équipe de développement dépendent de la même personne: le PO. Mais nous répondons quand même au grand principle: le PO tire un sprint planifié de l’équipe de développement, qui elle même tire ses spécifications d’un backlog en amont de la chaîne. Lorsque le lot est terminé, on en tire un nouveau sprint de l’équipe de développement.
La différence entre le Scrum et le Kanban, c’est que le withdraw (kanban) n’est pas timeboxé et que le sprint (scrum) est timeboxé. En retirant la notion d’estimation et de sprint balisé par le temps, on s’approche beaucoup plus du modèle Kanban: produire à la demande au lieu de pousser des sprints à terminer. Au final, c’est le même logiciel, mais la mentalité lors de sa réalisation et la collaboration avec le client est différente.
Si on pousse plus loin, on peut même supprimer la notion de sprint et alimenter l’équipe directement avec le backlog. Avec 6 développeurs travaillant en paires, on peut considérer qu’on a trois boîtes de travail. Par sa priorisation, le client demande la livraison de 3 features. L’équipe vide ses boîtes au fur et à mesure qu’elles se remplissent. Pour éviter les temps d’attente à la livraison d’une feature, on peut prévoir une queue un peu plus grande, maintenue en continue par le PO.
La vélocité se mesure par la moyenne de temps nécessaire pour qu’un item du backlog traverse la chaîne de livraison. On peut vérifier la progression du projet en comparant à un moment t les items restant du backlog avec la vélocité.
Chez OLM, ce modèle aurait pu nous aider à mieux satisfaire le client: des stories avaient souvent des pré-requis dépendant d’entités externes, qui allaient se résoudre pendant le sprint, mais qui ne peuvaient pas attendre les trois semaines prévues par le sprint pour être commencées. Avec un modèle “pull”, une fiche aurait été élligible au développement dès que sa spécification aurait été complète et ses pré-requis résolus.
En résumé
L’estimation est un processus coûteux qui peut prendre une forme plus légère, par exemple en estimant sur une échelle T-Shirt. Comme l’estimé ne peut plus servir à mesurer la capacité d’une équipe dans le temps, on peut remettre en question la durée du sprint: pourquoi ne pas se limiter au périmètre au lieu de baliser le sprint dans le temps.
En théorie, l’équipe ne travaillera pas plus vite. Mais en réduisant le temps des séances d’estimations, elle aura plus de temps disponible au développement. Les séances de planification seront axé sur le livrable, en retirant la notion de combler la boîte de temps
Pour faire le suivi d’un projet, on mesurera le temps moyen de réalisation des features pour faire des prévisions avec les items restant du backlog.
En poussant plus loin, on peut réduire la planification à une queue de production, au lieu d’utiliser le sprint comme unité d’entrée à l’équipe de développement.
