Els Punts d'Història No Són Estimacions de Temps (I Per Què Importa)
Cada pocs mesos, es repeteix la mateixa escena. Un product manager entra en una reunió de planificació, l'equip assigna punts d'història a un conjunt de tiquets, i llavors algú treu un full de càlcul convertint aquests punts en hores per poder prometre una data de lliurament als stakeholders.
I així, tota la finalitat dels punts d'història col·lapsa.
He vist passar això en startups, en scale-ups i en empreses que haurien de saber-ho millor. La causa arrel és sempre la mateixa: una incomprensió fonamental del que se suposa que mesuren els punts d'història — i una cultura de gestió que no pot resistir traduir-ho tot en una línia de temps.
El Que Realment Mesuren els Punts d'Història
Els punts d'història són una unitat de complexitat relativa. Comparen l'esforç d'una peça de treball amb una altra, tenint en compte la complexitat, la incertesa i el risc — no les hores del rellotge.
Quan un equip diu "això és un 5 i allò és un 2", estan dient que la primera tasca és aproximadament 2,5 vegades més complexa que la segona. No estan dient que la primera tasca porta 5 hores o 5 dies. El número és relacional, no absolut.
Aquesta distinció importa perquè:
- Dos desenvolupadors podrien completar la mateixa història de 5 punts en quantitats de temps molt diferents. Un coneix millor la base de codi. L'altre és més ràpid depurant. La complexitat del problema és la mateixa per a tots dos.
- Una història de 5 punts aquest sprint podria trigar més que una història de 5 punts de l'últim sprint. Canvis de context, incidents en producció, canvis d'equip — tot això afecta la durada però no la complexitat.
- La complexitat és estimable; la durada no ho és. Els enginyers són raonablement bons comparant la dificultat de dues tasques. Són terribles predient quantes hores trigarà alguna cosa. Els punts d'història aprofiten el punt fort i eviten el punt feble.
En el moment en que comences a dir "1 punt = mig dia", has abandonat l'estimació relativa i estàs de tornada a les estimacions de temps amb passos addicionals.
Per Què els Gestors Converteixen els Punts en Temps (I El Dany que Fa)
Ho entenc. Si ets un product manager o un CEO, necessites respondre "quan estarà fet?" Aquesta és una pregunta legítima. El problema és la drecera: agafar punts d'història i dividir-los per una "velocitat" per produir una data.
Aquí és el que realment passa quan fas això:
Els equips comencen a manipular els números. Si la gestió tracta els punts com a temps, els enginyers aprenen a inflar les estimacions per no ser pressionats per "comprometre's" a massa punts. El que era un 3 es converteix en un 5. El que era un 5 es converteix en un 8. Els números deixen de significar res.
La velocitat es converteix en una mètrica de rendiment. En lloc de ser una eina de planificació, la velocitat es converteix en un marcador. Els equips que "lliuren" més punts es recompensen. Els equips comencen a dividir les històries artificialment o a inflar les estimacions per semblar més productius. Ara estàs mesurant la cosa equivocada i incentivant el comportament equivocat.
La confiança s'erosiona. Els enginyers se senten vigilats en lloc de ser de confiança. Gasten més energia gestionant expectatives que resolent problemes. La planificació del sprint deixa de ser una conversa col·laborativa sobre el que és realista i es converteix en una negociació on tots dos bàndols fan teatre.
La precisió de l'estimació empitjora, no millora. La ironia és cruel: com més pressiones per a estimacions de temps precises, menys fiables es tornen les teves estimacions. La pressió introdueix biaix. El biaix destrueix el senyal.
Alternatives que Realment Funcionen
Si s'estan malutilitzant els punts d'història al teu equip, tens opcions. Alguns equips ho fan millor canviant a un enfocament diferent del tot.
Mides de Samarreta
En lloc de números, usa S/M/L/XL. És deliberadament imprecís, que és la qüestió. Força les converses sobre la mida relativa sense la il·lusió de precisió matemàtica. Un product owner pot mirar un roadmap de mitges i grans i tenir una idea aproximada de l'abast sense que ningú fingeixi que una L és exactament 3,5 dies.
El Moviment No-Estimates
Aquest és més radical: deixa d'estimar les històries individuals del tot. En canvi, centra't a desglossar el treball en peces petites de mida similar i en mesurar el rendiment. Si el teu equip completa una mitjana de 12 elements per sprint i el backlog té 36 elements de mida similar, pots preveure "aproximadament 3 sprints" sense assignar mai un número a cap història individual.
Això funciona millor quan tens disciplina en la descomposició de les històries. Si algunes històries són minúscules i altres enormes, la previsió basada en rendiment es trenca.
Previsió del Temps de Cicle
Aquest és el meu enfocament preferit per a equips que tenen almenys uns mesos de dades històriques. En lloc d'estimar cap endavant, mires enrere a quant temps triga realment el treball.
El temps de cicle és la durada des que comença el treball fins que s'acaba. Si fas el seguiment d'això per història o per tiquet, pots calcular percentils:
- "El 85% de les nostres històries es completen en 7 dies."
- "El 50% es completen en 3 dies."
Ara quan algú pregunta "quan estarà fet?" dónes una resposta probabilística: "Basant-nos en la nostra història, hi ha un 85% de probabilitats que estigui fet en 7 dies laborables." Això és més honest, més defensable i més útil que qualsevol estimació basada en punts.
Eines com Jira, Linear i Shortcut poden generar dades de temps de cicle. No necessites res sofisticat — un full de càlcul fent el seguiment de la data d'inici i la data de finalització per història t'aportarà el 80% del valor.
Quan l'Estimació Afegeix Valor
No estic en contra de l'estimació. L'estimació és útil quan serveix un propòsit clar:
- Definint el scope de grans iniciatives. Quan necessites decidir entre dos projectes que podrien trigar 3 mesos versus 9 mesos, l'estimació aproximada ajuda a assignar recursos i establir expectatives. Les mides de samarreta o el story mapping funcionen bé aquí.
- Identificant incògnites. Si l'equip no pot acordar si alguna cosa és un 3 o un 13, aquest desacord és el valor. Surfacia suposicions diferents, requisits que falten i complexitat oculta. La conversa al voltant de l'estimació és més valuosa que el número.
- Planificació de capacitat. Saber aproximadament quant treball cap en un sprint ajuda els equips a evitar sobrecomprometir-se. Però això només funciona si protegeixes les estimacions de ser convertides en armes com a terminis.
Quan l'Estimació És Pur Malbaratament
L'estimació no afegeix cap valor quan:
- Totes les històries són aproximadament de la mateixa mida. Si el teu equip s'ha tornat bo en desglossar el treball en petits trossos, les estimacions son redundants. Simplement compta les històries.
- Les estimacions no alimenten cap decisió. Si ningú usa les estimacions per prendre una decisió de planificació, estàs gastant 30 minuts per sprint en un ritual que no produeix res.
- Les estimacions s'usen per culpar, no per planificar. "Vas dir que era un 3 i va trigar una setmana." Si aquesta frase s'ha pronunciat mai en el teu equip, el teu procés d'estimació fa més mal que bé.
L'Objectiu Real: Previsibilitat, No Precisió
Aquí hi ha el que la majoria de la gent no veu: l'objectiu de qualsevol pràctica d'estimació és la previsibilitat, no la precisió. No necessites saber que la Funcionalitat X trigarà exactament 14 dies. Necessites saber que el teu equip pot lliurar de manera fiable un conjunt de funcionalitats dins d'un trimestre. Això és un problema diferent, i es resol amb mètriques de flux, no amb millors endevinalles.
Fes el seguiment del temps de cicle. Mesura el rendiment. Monitora els límits de treball en curs. Aquests són indicadors retardats que reflecteixen la realitat, no indicadors avançats que reflecteixen l'esperança.
Els equips amb els quals he treballat que tenen la major previsibilitat de lliurament no són els que tenen els rituals d'estimació més sofisticats. Són els que mantenen el treball petit, limiten el WIP i usen dades històriques per preveure. No cal el planning poker.
A Conectia, els enginyers sèniors que integrem als teus equips entenen això. Han treballat en prou equips per saber que el teatre de l'estimació malbarata el temps de tothom, i aporten hàbits pràctics — PRs petits, abast clar, rendiment consistent — que fan que el teu lliurament sigui previsible sense convertir la planificació del sprint en una negociació. Això és el que fan els enginyers experimentats: fan funcionar el procés, no només el codi.
Cansat del teatre de l'estimació que alenteix el teu equip? Parla amb un CTO — els nostres enginyers sèniors de LATAM aporten els hàbits de lliurament que fan de la previsibilitat un subproducte, no una batalla.
