Cadre de travail

Ce que ce cadre cherche à obtenir

Trois objectifs, dans cet ordre : fiabiliser le chiffrage, lire notre capacité réelle, connaître le coût d'une fonctionnalité.

• Fiabiliser le chiffrage. Savoir ce que coûte réellement un lot, pour engager des délais tenables au lieu de les deviner.
• Lire la capacité réelle. Savoir ce qu'une équipe absorbe vraiment dans un cycle, une fois déduits les bugs, la dette, les réunions et les interruptions.
• Connaître le coût d'une fonctionnalité. Pour arbitrer entre ce qu'on construit et ce qu'on abandonne, en connaissance de cause.

Les trois reposent sur une seule et même chose : pouvoir relier une estimation à un temps réellement passé. Ce qui suppose que les tickets soient estimés, qu'ils se terminent, et que le temps atterrisse au bon endroit. Tout le reste du document décrit comment y arriver.

Everhour mesure le temps. Il ne produit ni les estimations ni les clôtures : celles-là dépendent de nos habitudes, et l'annexe B liste les quatre conditions sans lesquelles la donnée restera illisible.

Les objets Linear

Un concept, un objet. Linear n'a pas d'objet « epic », il faut donc choisir où il vit, et s'y tenir.

Trois règles non négociables

• Un Project est un lot qui se termine. Les domaines permanents (Agent, Tools, Dashboard, Dette technique, Paramètres généraux) ne sont pas des projets : ce sont des vues filtrées ou des labels. On ne peut pas poser un budget en heures sur quelque chose qui ne finit jamais.
• Le label Epic disparaît. Une issue étiquetée Epic remonte au niveau Project ou Milestone. Un seul niveau pour un seul concept.
• Une sous-issue appartient toujours au projet de son parent. Un enfant rangé ailleurs que son parent rend le reporting illisible.

Le workflow d'un ticket

« Bloqué » n'est pas un statut mais un label : un statut, on y stationne confortablement. Et l'état est mis à jour par celui qui fait, au moment où il le fait. Fermer les tickets en lot une fois par mois rend toute mesure de délai fausse : un ticket clos trois semaines après sa mise en production ne dit plus rien de sa durée.

Le cycle de vie d'un projet

To scope est le seul statut que nous ajoutons. Le besoin est accepté, le lot n'est pas encore cadré : la session de cadrage n'a pas eu lieu, ou les US ne sont pas estimées. C'est la phrase à mettre dans la description du statut, dans les réglages du workspace.

Un Project naît donc avant son cadrage, et non au grooming. La raison est comptable : le temps d'instruction et de session est du coût du lot (section 3), et sans projet il n'aurait nulle part où se poser. Le coût d'une fonctionnalité exclurait alors sa partie la plus en amont.

• Backlog, c'est une idée ; To scope, c'est une décision. Dans l'un, personne n'a rien tranché et personne n'est dessus. Dans l'autre, le besoin est accepté, un responsable est nommé, un cadrage est à caler. C'est cette frontière qui empêche To scope de devenir un deuxième backlog.
• Ce n'est pas « on attend une spec ». Ce qui sort de la session, ce sont des décisions et une estimation ; la spec s'écrit après, sur les US.
• Ce n'est pas « en cours ». Rien ne se construit pendant qu'un projet est To scope.
• Les statuts de projet sont communs à tout le workspace. Cette définition vaut pour toutes les équipes, pas seulement pour la nôtre.

Cadrer et concevoir un lot

Ce qui se passe avant qu'une US existe. Cette section ne concerne que les lots : une US isolée s'écrit en cinq minutes et complète ce qui manque en grooming.

Quand on déclenche ce processus

Dès qu'au moins l'une de ces conditions est vraie. Si aucune ne l'est, on n'en fait rien.

• Plusieurs solutions sont plausibles et le choix a des conséquences durables
• Le sujet traverse plusieurs services (Gateway, back, front)
• Il touche un modèle ou un contrat existant : rôles et permissions, facturation, modèle de données
• Il a besoin de maquettes avant de pouvoir être spécifié
• Le découpage lui-même est une question ouverte

La séquence

Le plus souvent, c'est le décideur qui arrive avec un besoin, formulé comme une intention. Ça devient une entrée en Triage, rien de plus, et surtout pas un ticket de travail.

Cette demande initiale est tracée comme une entrée, avec sa source, et reste distincte des observations que l'instruction produira. C'est ce qui permettra plus tard de dire si une décision reposait sur une conviction ou sur un constat.

Si la CP accepte le besoin au triage, le Project est créé en To scope, avec un ticket de cadrage dedans. C'est sur ce ticket que se pose le temps de tout ce qui suit, jusqu'au grooming.

Puis :

Au total, moins de deux heures de réunion pour un lot, plus les 45 minutes d'instruction.

Les livrables

Deux exigences de format

• Les décisions sont attribuées, partout. Sans cette séparation entre constats et décisions, personne ne pourra dire dans six semaines qui a tranché quoi, ni distinguer une décision prise avec le client d'une hypothèse raisonnable écrite un mardi soir.
• Les options écartées sont un livrable, pas une note de bas de page. C'est ce qu'on regrette toujours de ne pas avoir six mois plus tard, quand quelqu'un propose exactement ce qui avait déjà été écarté.

Où se branche un outil de spec-driven development

Au niveau de l'US, jamais au niveau du lot. Le processus ci-dessus produit les US ; ensuite, chaque US est un cycle complet de l'outil : la spécification est déjà faite, l'US est le spec, et on enchaîne sur le plan, les tâches et l'exécution.

Où va ce temps

L'instruction, la session et le découpage sont du coût du lot, pas du temps interne. Ils vont sur le ticket de cadrage du Project, timeboxé et sans points, comme un spike. C'est pour ça que le Project existe dès l'acceptation du besoin, en To scope : au moment du cadrage, il faut déjà un endroit où poser ce temps.

C'est important précisément parce que l'IA raccourcit ces étapes : sans les tracer, on ne saura jamais combien on a gagné, et le ratio heures/point deviendra incomparable d'un lot à l'autre selon qu'on aura utilisé l'outil ou non.

Où s'arrête l'IA

La frontière ne passe pas entre le cadrage et la conception, mais à l'intérieur de chacun des deux. C'est ce qui la rend difficile à tenir intuitivement.

Le critère : d'où vient la réponse

Le test pratique, en une question : si je conteste cette phrase, sur quoi peut-on s'appuyer pour me répondre ? Si on peut pointer un fichier, un log, une requête sur la donnée d'usage, c'est du territoire IA. Si la seule réponse possible est « on a décidé ça », c'est du territoire humain, et il faut alors savoir qui a décidé.

Noter que « quels clients ont demandé ça » est trouvable : c'est dans le backlog Linear, dans Slack et dans ce que le CSM a noté, et une IA le lira mieux que nous. Alors que « quelle approche retenir sachant qu'on veut pouvoir migrer dans six mois » est une décision, bien qu'elle soit purement technique. D'où le fait que la frontière traverse les deux activités au lieu de les séparer.

Ce qui rend la frontière tenable

Un critère sans mécanisme ne survit pas trois semaines, et une règle du type « ne pas laisser l'IA décider » est inapplicable : au moment où elle décide, ça ne se voit pas.

La frontière ne se garde pas par la discipline, elle se garde par la structure du document produit. Quel que soit l'outil, un spec sépare trois blocs :

• Constats, chacun avec son pointeur : un fichier, une ligne, un ticket. Vérifiable en deux minutes.
• Décisions, chacune avec qui l'a prise, quand, et sur quoi elle se fonde : une donnée d'usage, une demande client identifiée, ou une conviction. Les trois sont acceptables, une conviction produit est parfois exactement ce qu'il faut. Ce qui ne l'est pas, c'est de ne plus pouvoir les distinguer. C'est le seul bloc que la CP relit, et ça lui prend cinq minutes au lieu de trente pages.
• Questions ouvertes : ce que ni l'IA ni son pilote ne peuvent trancher seuls.

Avec cette séparation, la relecture devient assez bon marché pour être réellement faite. C'est tout l'enjeu.

Les deux instructions à donner à l'outil

Quand l'IA pose une question, elle a déjà bien travaillé : elle a identifié un point de décision. Le risque n'est jamais dans les questions qu'elle pose, il est dans celles qu'elle ne pose pas, parce qu'elle a trouvé un défaut plausible. Ces deux instructions attaquent exactement cela.

Trois choses hors périmètre, quel que soit l'outil

• L'estimation. Un nombre plausible sans origine connue contamine le grooming, pour la raison exposée à la section 5.
• L'arbitrage de priorité. C'est un jugement de valeur, il n'est trouvable nulle part.
• Le choix du découpage en US. Celui-là est moins évident : il ressemble à un exercice technique alors que c'en est un de valeur. Découper verticalement, c'est décider ce qu'on accepterait d'abandonner, et l'IA ne sait pas ce que le client tolérerait de perdre. Elle peut proposer trois découpages, ce qui est très utile ; c'est l'humain qui choisit, et le critère de choix n'est pas technique.

Le parcours d'une US

Six étapes, dans l'ordre. C'est la seule séquence numérotée de ce document, parce que l'ordre y porte du sens.

Ce parcours est celui d'une US, un ticket de type Feature ou Improvement. Les étapes 5 et 6, développement et saisie, valent pour tous les tickets sans exception. Les étapes 1 à 4 changent pour un bug, une dette ou un spike : c'est l'objet de la section 6.

Bugs, dette et spikes

Leur imposer les règles de l'US ne marcherait pas. On ne demande pas de critères d'acceptation à un bug, et on ne cote pas ce qu'on n'a pas encore diagnostiqué.

Le bug

Un bug ne s'estime pas avant d'être diagnostiqué. L'inconnue, c'est justement le diagnostic, coter un bug non diagnostiqué, c'est estimer un spike en l'appelant autrement. La règle : diagnostic timeboxé à deux heures, puis de deux choses l'une. Soit le correctif tient dans la foulée et le ticket se ferme, soit on sait maintenant ce qu'il faut faire et on crée un ticket estimable.

Conséquence : les bugs ne portent pas de points, on leur réserve de la capacité. Environ 20 % du cycle au démarrage, à ajuster. C'est plus honnête que de coter ce qu'on ne connaît pas, et ça évite un effet pervers classique : une équipe qui estime ses bugs affiche une vélocité qui monte quand la qualité baisse.

Le hotfix

Un hotfix ne passe ni par le grooming ni par le cycle : il est créé, corrigé, déployé. La seule exigence, non négociable, il est créé quand même, et le temps y est saisi. Un correctif urgent traité sans ticket disparaît du décompte, et c'est précisément ce qui rend une capacité réelle incompréhensible. Il rejoint ensuite le cycle courant pour que son temps soit rattaché quelque part.

La dette technique

Elle s'estime, contrairement au bug : on sait ce qu'on va faire. Elle passe donc en grooming comme une US, et elle a sa capacité réservée (environ 15 %), sinon elle ne passe jamais. Le tech lead propose, la CP arbitre.

Le ticket porte le label Dette et vit dans le projet qu'il concerne, pas dans un projet « Dette technique » fourre-tout : celui-là ne se termine jamais, donc aucun budget ne peut s'y poser. Un vrai chantier de refonte, lui, est un lot livrable comme un autre.

Et un ticket de dette dit ce qui coince et le coût de ne rien faire. Sans cette seconde phrase, il ne sera jamais priorisé.

Le spike

Un spike est un ticket d'investigation à durée fixée, dont le livrable est une réponse écrite, pas du code. On en crée un quand on ne peut pas estimer parce qu'on ne sait pas encore.

Nous en faisons déjà, sans lui donner ce nom : un ticket « documenter et estimer le coût du remplacement de telle librairie » est exactement cela.

Le problème qu'il résout : en grooming, quelqu'un demande « combien pour remplacer cette librairie ? » et personne ne sait, ça dépend du nombre d'écrans concernés, de leur couplage, de ce que couvre l'alternative. Trois réponses sont possibles, deux sont mauvaises.

• Deviner un chiffre. Il entre dans l'historique et plus personne ne saura que c'était une devinette. C'est ainsi qu'on fabrique un ratio heures/point faux.
• Refuser de planifier. Le sujet reste au backlog indéfiniment.
• Acheter la réponse à prix fixe : « on prend quatre heures pour aller voir, jeudi prochain on saura chiffrer ». C'est le spike.

Les quatre règles qui le distinguent d'un ticket normal

• Une seule question, écrite avant de commencer. « Combien d'écrans utilisent cette librairie, et lesquels portent de la logique custom ? », pas « regarder la librairie ».
• La timebox est décidée à l'ouverture, et elle est ferme. Quatre heures pour une question technique, deux à trois jours pour un spike conception qui produit des maquettes : la durée varie, le caractère ferme non. À la fin on s'arrête et on rapporte ce qu'on a, y compris « c'est plus gros que prévu », qui est une réponse utile. Un spike qui déborde devient le travail lui-même sans que personne l'ait décidé : c'est l'échec classique.
• Le livrable est écrit, en commentaire du ticket. Le code produit pendant un spike est jetable par défaut : on l'a écrit pour comprendre, pas pour livrer.
• Pas de points, mais le temps est saisi. La timebox est l'estimation. Et un spike ne rentre pas dans la vélocité pour une raison de fond : l'exploration et le développement n'ont pas le même rapport au temps, donc les mélanger fausserait le ratio heures/point.

À la fin, on crée le vrai travail, et cette fois il est estimable.

Les rituels

Le rythme hebdomadaire ne dépend pas de la longueur du cycle. Seuls le planning et la rétro la suivent.

Quatre règles qui font tout le travail

• On n'estime jamais en planning. Le backlog y arrive déjà estimé, grâce au grooming hebdomadaire. Estimer en planning, c'est estimer sous la pression du « il faut que ça rentre », soit exactement l'effet d'ancrage qu'on cherche à éviter.
• Le grooming ne déborde pas. Quarante-cinq minutes, chrono. Ce qui n'est pas passé attend jeudi prochain. C'est le seul mécanisme qui oblige à préparer en amont. Un pré-tri CP + tech lead de quinze minutes la veille garde la session courte.
• La rétro s'ouvre en vérifiant les deux actions de la précédente. Maximum deux actions, chacune avec un porteur et une date. Sans cette ouverture, une rétro devient un rituel de plainte et ne mérite pas son heure.
• Le directeur de projet n'est ni au daily ni à la rétro. En rétro sa présence tue la parole ; au daily elle transforme un point de flux en reporting.

Ce qui sort d'un grooming

Chaque ticket passé en revue ressort dans l'un de ces trois états. Les nommer à voix haute évite qu'une session se termine sur du flou.

• Prêt, estimé, il peut entrer dans un prochain cycle.
• Question ouverte simple, la CP complète, il revient jeudi prochain. On ne l'estime pas d'ici là.
• Incertitude sur le comment, il part en spike, ou en session de cadrage si c'est un lot. On ne l'estime surtout pas : c'est là qu'on fabriquerait un chiffre faux pour toujours.

La semaine type

Tout est en début de journée ou juste après le déjeuner, jamais à 11h ni à 16h : ce sont les seules plages où l'on code vraiment. Grouper les cérémonies vaut mieux que les répartir « pour équilibrer ».

Ce que ça coûte réellement

La CP et le tech lead sont plutôt à quatre heures. Le directeur de projet à une heure, et c'est volontaire. Ce chiffre est aussi une des composantes du coefficient de charge qui servira aux chiffrages.

Qui décide quoi

Trois personnes peuvent légitimement dire « fais plutôt ça ». C'est le principal risque, et il se règle par un tableau.

• Le directeur de projet ne réordonne pas le backlog en cours de cycle. Il arbitre en amont et lit le consommé dans Everhour. S'il court-circuite, les devs reçoivent deux signaux et les écarts deviennent illisibles, on mesurera du désordre organisationnel en croyant mesurer du chiffrage.
• Une seule personne ordonne le backlog : la CP. Et quand le besoin est porté en interne, son rôle n'est pas de recueillir ce besoin mais de le contester : c'est ce qui rend sa propriété du backlog réelle plutôt que formelle.
• Personne ne fait Scrum Master. Protéger le cycle des interruptions et faire tenir les rituels n'est pas optionnel : les interruptions sont l'une des quatre causes d'écart qu'on analysera en rétro. Cette fonction est portée par le tech lead. Si on ne nomme personne, elle n'est pas faite.
• À trancher avant le démarrage : est-ce que assignee veut dire « qui fait » ou « qui suit » ? La réponse change complètement la façon de lire Everhour, et elle doit être la même pour tout le monde.

Les signaux que suit le tech lead

Ils viennent tous de Linear ou de GitHub, jamais d'Everhour. Ils sont objectifs, ils ne se déclarent pas, et chacun ouvre une conversation précise au lieu d'un jugement.

« Ton ticket est en revue depuis six jours » ouvre une conversation utile. « Tu as saisi vingt-huit heures cette semaine » n'ouvre rien.

Linear source de vérité

Une règle de discipline. Elle ne tient que si l'on en paie le prix.

Une seule source par type d'information

• Interdiction du tableur de suivi parallèle. Le jour où un Excel apparaît, il y a deux vérités, elles divergent en trois semaines, et c'est toujours Linear qu'on accuse d'être faux. Si quelqu'un a besoin d'une vue, elle se construit dans Linear ou dans Everhour.
• Slack ne crée pas de travail. Une demande en message direct n'existe pas tant qu'elle n'a pas d'issue. L'intégration Slack de Linear (créer une issue depuis un message) rend la règle tenable plutôt que moralisatrice.
• Une colonne Triage pour tout ce qui arrive de l'extérieur, que la CP vide deux fois par semaine. Sans elle, soit ça pollue le backlog, soit ça repart en message direct. Vider, c'est trancher : un besoin accepté devient un Project en To scope avec son ticket de cadrage ; les autres sont fermés ou gardés au backlog, avec la raison.
• Automatiser l'état via Git : branche créée depuis Linear, PR liée qui bascule le ticket en In review, merge qui le passe en Done. C'est la mesure la plus rentable de la liste : elle rend « Linear = vérité » gratuit au lieu de coûteux, et fiabilise les dates de fin.

La boucle d'apprentissage

Sans elle, tout ce qui précède ne sert à rien. C'est le seul endroit où le chiffrage progresse.

Chaque mois, 30 minutes, en rétro

Les cinq plus gros écarts entre estimé et réel. Une seule question : la cause est-elle un sous-scoping, des interruptions, des critères d'acceptation flous, ou du temps non saisi ? On cherche la cause, jamais le responsable.

Chaque trimestre

• Recalcul du ratio heures/point de l'équipe. Il est propre à cette équipe et ne se partage jamais avec une autre.
• Mise à jour des tâches étalons.
• Mise à jour du coefficient de charge (temps produit sur temps total) qui alimentera les devis.

Au bout de trois mois, on obtient la seule chose qui compte vraiment : quand cette équipe dit huit points, ça coûte X jours. C'est ça, l'outil de chiffrage, pas une table de conversion décidée à l'avance.

Du point au chiffrage

Comment on passe d'une estimation en points à un devis en jours, sans jamais estimer un ticket en heures.

Complexité au niveau du ticket, temps au niveau du lot

C'est le principe qui lève la contradiction apparente entre les deux outils. Nous n'avons pas besoin de convertir un ticket en heures : nous avons besoin de chiffrer un lot. Ce ne sont pas les mêmes exigences de précision.

• Un ticket porte des points, dans Linear. Personne ne l'estime en heures.
• Un lot porte un budget en heures, dans Everhour, avec une alerte à 80 %. C'est le seul niveau où Everhour pose un budget de toute façon. Il est posé au grooming, quand le lot sort de To scope, jamais avant : avant l'estimation, il n'y a rien à budgéter.

Il n'y a donc pas de double estimation à produire. Saisir une estimation en heures ticket par ticket serait du travail en double, et surtout sans valeur : celui qui vient de dire « 3 points » écrira mécaniquement « 9 heures ». La seconde estimation n'apporte aucune information indépendante, elle recopie la première : c'est le même effet d'ancrage que partout ailleurs dans ce document.

Un ratio heures/point est une distribution, pas une conversion

C'est le malentendu à dissiper. Après vingt tickets, on n'obtient pas « 1 point = 3 heures ». On obtient : les tickets à 3 points ont pris entre 5 et 14 heures, médiane 9 heures. Cette dispersion n'est pas un défaut de mesure, c'est la nature de la chose.

Et c'est exactement pour cette raison que le procédé fonctionne sur un lot et pas sur un ticket : sur quarante points, les écarts individuels se compensent. Une somme de nombreuses estimations imprécises mais non biaisées est bien plus fiable que chacune prise isolément. Un point ne dira jamais ce que coûte ce ticket, il dira ce que coûte ce lot, ce qui est la seule chose nécessaire pour un devis.

La formule

Le second terme se mesure, il ne se modélise pas

C'est ici que les capacités réservées cessent d'être des hypothèses. Everhour dira, semaine après semaine, comment le temps d'une équipe de quatre devs se répartit réellement :

Seule la dernière ligne alimente la formule. Les trois autres ne sont pas des pertes : ce sont les raisons pour lesquelles une équipe de quatre devs ne produit pas 140 heures d'US par semaine, et pour lesquelles un planning qui l'oublie se trompe systématiquement d'un facteur deux.

Le calcul, en entier

Un lot à 40 points, ratio médian de 3 h/point, soit 120 heures de travail. Divisé par 64 heures-US par semaine : 1,9 semaine.

Et on annonce une fourchette, jamais un chiffre. Avec un ratio compris entre 3 et 4 h/point (la médiane et le haut de la distribution), le même lot pèse 120 à 160 heures, soit 1,9 à 2,5 semaines. C'est cette fourchette qui part dans le devis, et le budget Everhour du projet se cale sur son haut.

Ce qu'on ne fait pas

• Convertir les points en heures par une formule. Points et heures restent deux mesures distinctes ; seul le ratio observé les relie.
• Estimer un bug avant de l'avoir diagnostiqué. C'est un spike déguisé, et ça fausse la vélocité dans le mauvais sens.
• Changer l'échelle d'estimation en même temps que tout le reste. Choix assumé : on garde le linéaire. Trois quarts des tickets ne sont pas estimés du tout : c'est ça le sujet, pas la forme de l'échelle.
• Viser 100 % du temps tracké. On obtiendrait du déclaratif faux.
• Activer le facturable / non facturable. On ne refacture pas : ce serait une décision de plus à chaque saisie, pour zéro valeur.
• Faire porter des points ou du temps à une sous-issue. L'estimation et le temps vivent sur l'US, toujours au même niveau, sinon aucun total n'est honnête.
• Afficher la vélocité comme un objectif. Une mesure qui devient une cible cesse d'être une bonne mesure.
• Déployer sur toute l'équipe d'un coup. Deux cycles de rodage d'abord, le bucket Interne est toujours faux au premier essai.

Un cas d'exemple, de bout en bout

Une fonctionnalité fictive mais réaliste, suivie de la demande initiale jusqu'au temps saisi. Toutes les règles de ce document y passent, dans l'ordre.

1 · La demande arrive

Le décideur arrive avec un besoin, formulé comme une intention : « On devrait pouvoir mettre une campagne en pause. »

À ce stade il n'y a rien d'exploitable. Pas de ticket, donc pas de travail, mais aussi, et surtout, pas assez de matière pour en écrire un. La CP crée une entrée en Triage, avec le décideur pour source.

Au triage, elle accepte le besoin : le Project Pilotage des campagnes est créé en To scope, avec son ticket de cadrage. Deux critères de déclenchement sont réunis (le sujet traverse le front, la gateway et le moteur d'appel, et il touche le modèle de campagne), donc la session est calée.

2 · L'instruction

Quarante-cinq minutes, la CP seule avec l'IA et le code. Elle ne décide rien : elle rassemble les pièces. La note de constats, postée en commentaire du ticket de cadrage, ressemble à ceci.

Chaque constat a son pointeur. Ce qui n'en a pas n'entre pas dans la note : c'est une opinion, et elle aura sa place au temps 1, attribuée à quelqu'un.

3 · La session, temps 1 : la conception fonctionnelle

Vingt minutes, le décideur, la CP et le tech lead. Pas de dev dans la salle, et personne ne parle de coût. On reprend les questions de la note une par une. Ce qui en sort, ce ne sont pas des descriptions mais des décisions ; voici les cinq qui ont le plus de conséquences :

• Qui peut mettre en pause ? L'admin du compte uniquement. Un viewer ne voit pas l'action.
• Que deviennent les appels déjà lancés ? On les laisse aller à leur terme. Les interrompre dégraderait l'expérience du contact.
• Les contacts pas encore appelés ? Ils restent en file, la reprise repart de là.
• Et les crédits ? Rien n'est décompté pendant la pause.
• Combien de temps une campagne peut-elle rester en pause ? Sept jours, au-delà elle s'arrête d'elle-même.

Chaque décision est notée avec ce qui la fonde : une donnée d'usage, une demande identifiée, ou une conviction assumée. Sans cette session, chacune de ces questions serait tombée sur un dev en cours de développement, et aurait été tranchée par lui, seul, sans que personne ne le sache.

4 · La session, temps 2 : l'estimation

Les devs rejoignent, pour quarante minutes. L'IA sort les constats techniques et les approches possibles, avec leur ampleur. La question restée non établie à l'instruction revient aussitôt : le moteur d'appel sait-il s'arrêter proprement en cours de campagne ? Personne dans la salle ne sait. On ne devine pas, on crée un spike.

Approche retenue : un état paused sur la campagne, que le worker vérifie entre deux lots. Elle part dans le plan technique, dans le repo, avec les options écartées ; les décisions fonctionnelles vont dans le spec, en Linear Doc rattaché au projet.

Ce qui a bougé entre les deux temps : la pause programmée à l'avance, voulue au temps 1, est abandonnée pour raison de coût. C'est noté, avec la raison, et on la retrouvera dans le hors-périmètre de l'US.

5 · Le découpage

C'est ici que tout se joue. Voici les deux découpages possibles du même travail.

6 · L'US écrite

Voici US 1 telle qu'elle doit apparaître dans Linear. C'est le format à reproduire.

Sept critères testables, un hors-périmètre explicite. C'est le hors-périmètre qui empêchera la discussion « ah mais je pensais que… » trois semaines plus tard.

7 · L'estimation en grooming

US 1 est présentée. Un dev annonce 5, un autre 2.

On ne fait pas la moyenne, on cherche l'écart : celui qui disait 5 pensait qu'il fallait gérer l'arrêt au milieu d'un lot. Le spike a montré que non. On converge à 3.

C'est la vraie fonction du grooming. Un écart entre deux estimations n'est presque jamais un problème de calibrage : c'est une différence de compréhension du périmètre. La révéler avant le développement coûte deux minutes ; la découvrir après en coûte des jours.

Les quatre US estimées, le Project passe de To scope à Planned, et son budget en heures est posé dans Everhour. Le temps déjà saisi sur le ticket de cadrage et sur le spike y figure : il fait partie du coût du lot.

8 · La cinématique

US 1 traverse le workflow. Voici qui fait quoi, et où va le temps.

Trois personnes ont saisi du temps sur le même ticket, et aucune ne l'a fait sur un ticket qui lui était propre. C'est exactement l'intention : le temps se pose sur l'unité de valeur, pas sur les gens.

9 · Ce que le ticket nous a appris

• La revue a coûté 2 h 30, soit 24 % du ticket. Sans la règle « la revue et les retours vont sur l'US », on aurait enregistré 7 h 45 au lieu de 10 h 15. Le biais serait constant, donc invisible, et donc impossible à corriger. C'est la seule raison pour laquelle cette règle existe.
• Estimé 3 points, réalisé 10 h 15. Un point ne vaut rien tout seul : c'est en accumulant vingt tickets comme celui-ci qu'on obtient un ratio heures/point utilisable pour chiffrer les projets suivants.
• Le spike a économisé une reprise en recette. Quatre heures dépensées pour éviter une promesse intenable et une US à ré-estimer.
• Rien dans ce parcours n'est attribuable à quelqu'un. Le ticket porte le temps de trois personnes ; les 1 h 30 de correction ne sont ni une faute du Dev A ni un mérite du Dev B, c'est le coût normal d'une revue qui sert à quelque chose.
• Si on avait découpé horizontalement, on saurait aujourd'hui ce qu'a coûté « le front » sur ce lot. On ne saurait toujours pas ce que coûte une mise en pause de campagne, la seule chose dont on ait besoin pour chiffrer la prochaine.

Les quatre conditions

Quatre conditions à remplir avant de brancher Everhour. Sans elles, l'outil produira de la donnée illisible, et les deux dernières conditionnent directement le ratio de la section 11.

Le volume embarqué dans un cycle et la fluidité de la validation sont un chantier séparé, plus lourd. Ils ne bloquent pas le démarrage d'Everhour, mais ils reviendront en rétro tant qu'ils ne seront pas traités.

Questions ouvertes

Ce qui suit se décide avec l'équipe, pas à sa place. Ce qui n'y figure pas n'est pas ouvert, et la dernière partie dit lesquelles et pourquoi.

Chaque question est accompagnée de pistes avec leurs avantages et leurs inconvénients. Elles servent à démarrer la discussion, pas à la borner : une réponse qui ne figure pas dans la liste est un bon signe. Cette annexe sert une fois, à l'atelier de lancement ; le reste du document sert tous les jours.

Ce que l'équipe décide

Les paramètres que nous avons devinés

Aucun de ces paramètres ne repose sur une mesure. L'usage les corrigera en quelques cycles, mais votre intuition vaut mieux que la nôtre en attendant.

Les cas de saisie que nous n'avons pas tranchés

Les quatre qui décideront de l'adoption

Celles-ci ne portent pas sur les règles, et ce sont les seules qui prédisent si le dispositif tiendra.

Ce qui n'est pas ouvert

Le dire franchement vaut mieux qu'une fausse consultation, qui se repère en trois minutes et coûte plus cher que de ne rien demander.