Cum estimezi corect velocitatea unei echipe (velocity)?
Velocity = media story points livrate în ultimele 3-5 sprinturi închise. Nu estimezi velocity teoretic — o măsori. Și nu o folosești ca țintă (Goodhart's law), ci ca input pentru planning.
Velocity este una dintre cele mai abuzate metrici în Scrum. Echipele o transformă în KPI ("trebuie să creștem velocity") și încep să umfle story points-urile — devine fără sens. Velocity bun este descriptiv (cât livrăm efectiv), nu prescriptiv (cât ar trebui). Servește pentru planning realist, nu pentru evaluarea echipei.
1. Velocity se măsoară, nu se estimează
Nu există "velocity teoretic". Velocity-ul echipei e media story points închiși cu Definition of Done satisfăcută în ultimele 3-5 sprinturi. Înainte să ai 3 sprinturi închise, nu ai velocity — folosești estimare prin t-shirt sizes sau prin reference stories.
O echipă nouă se calibrează în 4-6 sprinturi. În acest timp planning-ul e mai conservator și se ajustează după fiecare retro. Stakeholderii trebuie informați explicit: "Primele 5 sprinturi sunt perioadă de calibrare, nu evaluați velocity pe ele".
2. Story points sunt relative, nu absolute
Un story point nu e "o zi de muncă". E "complexitatea unui story de referință". Echipa alege un story mediu și îi dă 3 SP, apoi toate celelalte se estimează relativ la acel reference: "Asta e cam dublu", "Asta e jumătate".
Asta înseamnă că velocity-ul a două echipe diferite nu se compară. Echipa A face 35 SP/sprint, echipa B face 50 SP/sprint — nu rezultă că B e mai rapidă. Calibrarea lor de SP e diferită. Manageri care încearcă să compare velocity între echipe greșesc fundamental.
3. Velocity nu e KPI — e input
Cel mai des abuzat anti-pattern: "Trimestrul ăsta vrem velocity 45". Imediat ce velocity devine țintă, echipa începe să umfle estimările. Story-uri de 3 SP devin 5 SP. Sprintul închide cu velocity mai mare, dar livrarea nu crește efectiv. Goodhart's law: când o metrică devine țintă, încetează să mai fie o metrică bună.
Velocity bun e folosit pentru planning: "Capacitatea sprintului viitor e 35 SP (velocity istoric) × 0.85 (absențe și timp rezervat pentru urgențe) = 30 SP commit-abili". Atât. Nu pentru bonusuri, nu pentru OKR, nu pentru raport către CEO.
4. Ajustează pentru capacity-ul real al sprintului
Velocity istoric presupune capacity normal. Dacă sprintul viitor pierde 25% din capacity (absențe, urgențe de producție, training), scade commit-ul cu 25% — sau ajustează capacity-ul efectiv, nu velocity-ul abstract.
4myprojects nu știe cine lipsește — reducerea o faci tu. Ce îți dă sunt cifrele pe care o faci: velocity-ul real al ultimelor sprinturi și încărcarea fiecărui om din taskurile deja alocate. Echipele care sar peste pasul ăsta commit-ează ca pentru un sprint normal — apoi sunt surprinse când livrarea pică.
5. Cycle time e adesea mai util decât velocity
Pentru predictibilitate pe scop, cycle time (timpul mediu de la "In Progress" la "Done") e mai informativ decât velocity. Spune-i clientului: "85% din task-uri se închid în maximum 5 zile". Asta e o promisiune pe care o poți onora.
Velocity răspunde la "câte putem livra", cycle time la "în cât timp livrăm o cerere individuală". Echipele de support, ops sau care primesc cereri imprevizibile sunt mai bine servite de cycle time. Echipele cu sprinturi planificate folosesc velocity pentru capacity, cycle time pentru SLA.
Velocity calculat automat în 4myprojects
Velocity istoric pe ultimele 5 sprinturi, încărcarea fiecărui om din taskurile deja alocate, burndown pe sprintul curent, cycle time pe board cu distribuție p50/p85/p95 — toate fără SQL sau export Excel.