Els punts d'història no són hores (i per què importa)
Cada uns quants mesos es repeteix la mateixa escena. Un product manager entra a una reunió de planificació, l'equip assigna punts d'història a un grapat de tiquets i, tot seguit, algú treu un full de càlcul que converteix els punts en hores per poder prometre una data de lliurament als stakeholders.
I, així, sense més, tot el sentit dels punts d'història se'n va en orris.
Ho he vist passar a startups, a scale-ups i a empreses que ja n'haurien d'haver après. L'arrel del problema és sempre la mateixa: no entendre què se suposa que mesuren els punts d'història — i una cultura de gestió incapaç de resistir la temptació de traduir-ho tot a un calendari.
Què mesuren realment els punts d'història
Els punts d'història són una unitat de complexitat relativa. Comparen l'esforç d'una feina amb el d'una altra tenint en compte la complexitat, la incertesa i el risc — no les hores de rellotge.
Quan un equip diu «això és un 5 i allò un 2», el que afirma és que la primera tasca és aproximadament 2,5 vegades més complexa que la segona. No diu que la primera tasca requereixi 5 hores ni 5 dies. El número és relacional, no absolut.
Aquesta distinció importa perquè:
- Dos desenvolupadors poden completar la mateixa història de 5 punts en temps molt diferents. L'un coneix més bé la base de codi. L'altre depura més de pressa. La complexitat del problema és la mateixa per a tots dos.
- Una història de 5 punts d'aquest sprint pot trigar més que una de 5 punts de l'sprint passat. Canvis de context, incidents en producció, rotació a l'equip — tot això afecta la durada, però no la complexitat.
- La complexitat es pot estimar; la durada, no. Els enginyers són raonablement bons comparant la dificultat de dues tasques. Són pèssims a l'hora de predir quantes hores trigarà una cosa. Els punts d'història exploten la fortalesa i esquiven la debilitat.
El dia que comences a dir «1 punt = mig dia», has abandonat l'estimació relativa i has tornat a les estimacions de temps, però amb més voltes.
Per què els gestors converteixen punts en temps (i el mal que fa)
Ho entenc. Si ets product manager o CEO, has de respondre «quan estarà fet?». És una pregunta legítima. El problema és la drecera: agafar punts d'història i dividir-los per una «velocitat» per treure'n una data.
Això és el que passa de debò quan ho fas:
Els equips comencen a fer trampes amb els números. Si la direcció tracta els punts com si fossin temps, els enginyers aprenen a inflar les estimacions perquè no els pressionin per haver-se «compromès» a massa punts. El que era un 3 passa a ser un 5. El que era un 5 passa a ser un 8. Els números deixen de voler dir res.
La velocitat es converteix en una mètrica de rendiment. En lloc de ser una eina de planificació, la velocitat passa a ser un quadre de puntuacions. Es premia els equips que «lliuren» més punts. Els equips comencen a partir històries artificialment o a inflar estimacions per semblar més productius. Ja estàs mesurant el que no toca i incentivant el comportament que no toca.
La confiança s'erosiona. Els enginyers se senten vigilats, no pas dignes de confiança. Dediquen més energia a gestionar expectatives que a resoldre problemes. La planificació de l'sprint deixa de ser una conversa col·laborativa sobre què és realista i es torna una negociació on totes dues parts fan teatre.
La precisió de les estimacions empitjora, no millora. La ironia és cruel: com més pressiones per obtenir estimacions de temps precises, menys fiables són. La pressió introdueix biaix. El biaix destrueix el senyal.
Alternatives que sí que funcionen
Si al teu equip els punts d'història es fan servir malament, tens opcions. Hi ha equips que se'n surten més bé canviant d'enfocament del tot.
Talles de samarreta
En lloc de números, fes servir S/M/L/XL. És deliberadament imprecís, i precisament aquesta és la gràcia. Força converses sobre la mida relativa sense la il·lusió de precisió matemàtica. Un product owner pot mirar-se un full de ruta ple d'emes i d'eles i fer-se una idea aproximada de l'abast sense que ningú hagi de fingir que una L són exactament 3,5 dies.
El moviment «no estimates»
Aquest és més radical: deixa d'estimar històries una per una. Centra't, en canvi, a trossejar la feina en peces petites i de mida semblant, i a mesurar-ne el ritme de lliurament. Si el teu equip completa de mitjana 12 elements per sprint i el backlog en té 36 de mida similar, pots preveure «uns 3 sprints» sense haver posat mai cap número a cap història concreta.
Això funciona quan hi ha disciplina a l'hora de descompondre històries. Si n'hi ha de minúscules i n'hi ha d'enormes, la previsió basada en el ritme de lliurament s'ensorra.
Previsió per temps de cicle
És el meu enfocament preferit per a equips que tenen, com a mínim, uns quants mesos de dades històriques. En lloc d'estimar cap endavant, mires enrere: quant triga, de fet, la feina a sortir.
El temps de cicle és el que passa des que una feina comença fins que està acabada. Si el registres per història o per tiquet, pots calcular-ne 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?», dones una resposta probabilística: «Segons el nostre històric, hi ha un 85% de probabilitats que estigui acabat en 7 dies laborables.» És més honest, més defensable i més útil que qualsevol estimació basada en punts.
Eines com Jira, Linear o Shortcut poden generar dades de temps de cicle. No et cal res sofisticat: un full de càlcul amb la data d'inici i la d'acabament de cada història ja et dona el 80% del valor.
Quan estimar aporta valor
No estic en contra d'estimar. L'estimació és útil quan serveix un propòsit clar:
- Dimensionar grans iniciatives. Quan has de triar entre dos projectes que poden trigar 3 mesos o 9, una estimació aproximada ajuda a assignar recursos i a fixar expectatives. Aquí, les talles de samarreta o l'story mapping funcionen bé.
- Fer aflorar incògnites. Si l'equip no es posa d'acord sobre si una cosa és un 3 o un 13, el valor és justament aquest desacord. Fa sortir a la llum supòsits diferents, requisits que falten i complexitat amagada. La conversa al voltant de l'estimació val més que el número.
- Planificar la capacitat. Saber aproximadament quanta feina cap en un sprint ajuda els equips a no comprometre's més del compte. Però només funciona si evites que les estimacions es converteixin en terminis amb què pressionar.
Quan estimar és malbaratar el temps
L'estimació no aporta cap valor quan:
- Totes les històries fan si fa no fa la mateixa mida. Si l'equip ha après a trossejar la feina en parts petites, les estimacions sobren. Compta històries i prou.
- Les estimacions no alimenten cap decisió. Si ningú les fa servir per prendre cap decisió de planificació, esteu dedicant 30 minuts per sprint a un ritual que no serveix de res.
- Les estimacions serveixen per culpar, no per planificar. «Vas dir que era un 3 i ha trigat una setmana.» Si aquesta frase s'ha sentit mai al teu equip, el procés d'estimació fa més mal que bé.
L'objectiu de debò: previsibilitat, no precisió
Això és el que a la majoria se li escapa: 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 amb fiabilitat un conjunt de funcionalitats dins d'un trimestre. És un problema diferent, i es resol amb mètriques de flux, no endevinant millor.
Registra el temps de cicle. Mesura el ritme de lliurament. Vigila els límits de treball en curs. Són indicadors retardats que reflecteixen la realitat, no indicadors avançats que reflecteixen un desig.
Els equips amb què he treballat que lliuren amb més previsibilitat no són els que tenen els rituals d'estimació més sofisticats. Són els que mantenen la feina petita, limiten el WIP i fan servir dades històriques per preveure. Sense planning poker.
A Conectia, els enginyers sèniors que integrem als teus equips ho entenen, això. Han passat per prou equips per saber que el teatre de l'estimació fa perdre el temps a tothom, i porten hàbits pràctics — PRs petits, abast clar, ritme constant — que fan previsible el teu lliurament sense convertir la planificació de l'sprint en una negociació. Això és el que fan els enginyers amb experiència: fan funcionar el procés, no només el codi.
Cansat que el teatre de l'estimació freni el teu equip? Parla amb un CTO.
