Équipe Starleads · Linear × Everhour
La vue d'ensemble du fonctionnement, et un cas concret déroulé de bout en bout. Le détail des règles est dans le cadre de travail.
↓ ou espace pour avancer · 13 écrans
02 · Pourquoi
Les trois reposent sur une seule chose : pouvoir relier une estimation à un temps réellement passé. C'est tout ce que le dispositif cherche à rendre possible.
03 · Le principe
Ce qu'on mesure, ce sont des tickets et des lots. Pas des personnes.
Il suit comment chacun avance, c'est son travail. Mais le signal vient du flux des tickets : un ticket immobile trois jours, trois allers-retours en revue, un ticket bloqué depuis une semaine. Ça se voit dans Linear, ça ne se déclare pas.
Le temps saisi ne sert jamais à comparer deux personnes, ni dans une évaluation ni dans un tableau. Pas par principe : parce qu'une donnée déclarative que chacun sait lue individuellement converge en trois semaines vers ce qu'on attend d'elle.
« Ton ticket est en revue depuis six jours » ouvre une conversation utile.
« Tu as saisi vingt-huit heures cette semaine » n'ouvre rien.
04 · Qui fait quoi
Ne réordonne pas le backlog en cours de cycle, et n'est ni au daily ni à la rétro.
N'estime jamais, et ne donne aucun chiffre indicatif : une seule phrase suffit à fausser un grooming.
N'estime pas seul : il estime avec ceux qui feront.
05 · Qui intervient quand
Les cases vides sont la partie utile du tableau.
Les devs ne sont ni à l'instruction ni au temps 1. Leur présence rendrait intenable la règle « on ne parle pas de coût » : ce n'est pas un manque de discipline, c'est un réflexe.
Anthony s'arrête après le temps 2. Il tranche la conception fonctionnelle et arbitre le périmètre. Il ne découpe pas, n'estime pas, et ne réordonne pas le backlog en cours de cycle.
06 · Les rituels
Ce que ça coûte : 2 h 25 à 2 h 50 par dev et par semaine, plus 1 h 30 par cycle. Environ 10 % du temps.
La durée du cycle reste à trancher. Le rythme hebdomadaire ne bouge pas ; seuls le planning et la rétro la suivent.
07 · Cas d'exemple
Une fonctionnalité inventée pour l'exercice, suivie de la demande initiale jusqu'au temps saisi.
Anthony arrive avec un besoin : « on devrait pouvoir mettre une campagne en pause ». C'est une intention, pas encore un sujet.
Elle est tracée comme telle : demande initiale, source Anthony. Distincte des observations que l'instruction produira.
une entrée en Triage. Acceptée, elle devient un Project en To scope, avec son ticket de cadrage
On instruit un dossier : on rassemble les pièces avant de trancher. Ce que le produit fait déjà, ce que la donnée d'usage montre, ce que le backlog contient sur le sujet, ce que ça touche techniquement.
Elle ne décide rien. Elle produit des constats sourcés, chacun avec son pointeur (un fichier, une requête, un ticket), et la liste des questions à trancher. Plus ce qu'elle n'a pas pu établir, qui reste une décision.
Lue par tous 24 h avant la session. Sans ça, les vingt minutes du temps 1 ne tiennent pas.
la note de constats, en commentaire du ticket de cadrage
La conception fonctionnelle : on tranche les questions de l'instruction, sans parler de coût. Seul l'admin peut mettre en pause, les appels déjà lancés vont à leur terme, aucun crédit n'est décompté pendant la pause, et au bout de sept jours la campagne 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.
rien encore. Les huit décisions sont prises, le spec est rédigé après la session et relu le lendemain
08 · Cas d'exemple
L'IA sort les constats techniques et les approches possibles, avec leur ampleur. Le sujet traverse le front, la gateway et le moteur d'appel. Et il bute aussitôt sur une inconnue : le moteur sait-il s'arrêter proprement en cours de campagne ? Personne ne sait.
La pause programmée à l'avance, voulue au temps 1, est abandonnée ici pour raison de coût. C'est noté, avec la raison.
le spec fonctionnel arrive en Linear Doc. Le plan technique va dans le repo
Question posée : à quel moment le moteur peut-il être interrompu sans perdre de contacts ? Réponse trouvée : il consomme la file par lots de cinquante, donc la pause prend effet en deux minutes au maximum.
Cette réponse change la décision produit : on ne peut pas promettre un arrêt instantané, on affichera la latence. Sans le spike, on l'aurait découvert en recette.
le ticket de spike, et sa réponse en commentaire
Quatre US verticales, dont la valeur décroît : mettre en pause et reprendre 3 pts, voir l'état dans la liste 2 pts, expiration automatique 2 pts, prévenir le client 1 pt.
On peut abandonner les deux dernières sans rien casser. C'est le seul vrai test d'un bon découpage.
les 4 US, créées mais pas encore estimées
US 1 est présentée. Un dev annonce 5, un autre annonce 2. On ne fait pas la moyenne : celui qui disait 5 pensait qu'il fallait gérer l'arrêt au milieu d'un lot, et le spike a montré que non. On converge à 3.
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, et la révéler coûte deux minutes.
les points posés, le Project passe de To scope à Planned, le budget en heures dans Everhour
09 · Cas d'exemple
| Statut | Qui | Ce qui se passe | Temps saisi |
|---|---|---|---|
| In Progress | Le dev | Développe back et front | 6 h 45 |
| In review | Johan | Relit la PR, demande des changements | 45 min |
| In Progress | Le dev | Corrige les retours | 1 h 30 |
| In review | Johan | Relit à nouveau, approuve, merge | 15 min |
| Test Dev | Le dev | Vérifie sur l'environnement de dev | 30 min |
| Test Fonctionnel | Juliette | Déroule les sept critères d'acceptation | 30 min |
| Total sur l'US | Trois personnes, un seul ticket | 10 h 15 |
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, donc impossible à corriger.
Et rien de tout cela n'est attribuable à quelqu'un : les 1 h 30 de correction ne sont ni une faute du dev ni un mérite du relecteur, c'est le coût normal d'une revue qui sert à quelque chose.
10 · Le contre-exemple
Le même processus, mais la conception ne pèse pas le même poids.
Si la conception demande plus d'une session, elle devient un spike conception. Si elle demande plus d'un cycle, elle devient un lot à part entière, avec son propre budget.
Une durée décidée à l'ouverture et ferme. Un livrable nommé avant de commencer : une réponse écrite, ou les maquettes validées. Pas de points, mais le temps est saisi.
11 · À trancher ensemble
Nos pistes sont là pour démarrer la discussion, pas pour la fermer.
12 · À trancher ensemble
Définir l'échec à l'avance, c'est ce qui évite le process zombie que plus personne n'ose remettre en cause. Deux cycles d'essai, puis une revue avec l'option d'arrêter.
13 · À vous
Qu'est-ce qui va vous empêcher de saisir votre temps ? Pas « êtes-vous d'accord », à quoi tout le monde répond oui.
Qu'est-ce que vous voulez en tirer, vous ? Si rien ne vous revient, c'est une taxe et elle sera contournée.
Les cas de saisie et la place de l'IA sont détaillés aux deux écrans précédents.