Cum planifici un sprint Scrum care chiar se livrează?
Sprint planning bun înseamnă scope realist pe capacitatea echipei, obiective măsurabile și dependențe rezolvate înainte de prima zi — nu un meeting în care fiecare se angajează "ce intuiește".
Sprint planning prost este sursa #1 de sprinturi ratate. Echipa intră într-un meeting de 2 ore, fiecare estimează "din burtă", PO-ul împinge scope-ul peste capacitate, iar pe ziua 8 toată lumea știe că ceva nu intră — dar nimeni nu retează formal scope-ul. Un sprint planning bun arată complet diferit: vine cu un backlog deja refinat, cu capacitate calculată per persoană, cu dependențe rezolvate și cu un singur Sprint Goal care servește drept criteriu de decizie la fiecare alegere ulterioară.
1. Refinement înainte de planning, nu în planning
Sprintul nu se planifică pe un backlog crud. Cu 2-3 zile înainte ții o sesiune de refinement în care PO-ul prezintă top 10-15 story-uri din backlog, iar echipa le clarifică acceptance criteria, le sparge dacă sunt prea mari și le estimează (story points sau t-shirt sizes). Regula: orice item de pe lista candidaților pentru sprint trebuie să aibă DoR (Definition of Ready) îndeplinită — fără DoR satisfăcut, item-ul nu intră la planning, oricât de important pare.
Refinement-ul este și momentul în care identifici dependențele externe (alte echipe, vendori, decizii legal/security) și le pui în mișcare. O dependență descoperită la planning înseamnă deja un risc semnificativ pentru sprint.
2. Capacity reală, nu velocity istorică
Velocity istorică e un input util, dar nu și suficient. Calculează separat capacity-ul concret al sprintului: zile lucrătoare × ore disponibile per persoană, minus concedii, minus on-call, minus context switching pentru bug-fixing din producție. Rezultatul este capacity-ul real.
Dacă echipa are velocity istorică 35 SP per sprint, dar acest sprint pierde 2 zile pe concedii și are 3 PR-uri urgente moștenite din ultimul, capacity-ul real este aproape de 25 SP, nu 35. Sprintul se umple la capacitatea reală, nu la cea ideală. Promisiunile către stakeholderi se fac pe baza acestui număr, nu a unei medii care nu reflectă realitatea săptămânii.
3. Un singur Sprint Goal, scris în limbaj de business
Sprint Goal-ul nu e "să terminăm 8 tichete". Sprint Goal-ul e un rezultat de business: "Reducem timpul de checkout cu 25% pe mobile" sau "Permitem importul facturilor din SmartBill pentru noii clienți". Un singur goal, scris într-o singură propoziție pe care orice membru o poate repeta din cap.
Goal-ul devine criteriul de decizie: dacă în ziua 5 trebuie să alegi între două task-uri, alegi cel care contribuie la goal. Dacă în ziua 8 trebuie să negociezi scope-ul în jos, păstrezi ce ține de goal și retezi ce nu. Echipele fără goal clar ajung mereu să livreze "ceva", dar rar "ceea ce contează".
4. Tasks vs story points: descompunere ulterioară
Story-urile selectate intră în sprint cu estimare în story points. Sparge-le în tasks tehnice (4-8 ore fiecare) în prima zi de sprint, nu în planning. Planning-ul se concentrează pe scope și risc, nu pe descompunere tehnică detaliată.
Această distincție menține meeting-ul de planning sub 2 ore pentru un sprint de 2 săptămâni. Echipele care încearcă să descompună totul în tasks de 1 oră în timpul planning-ului pierd 4-5 ore cu un meeting care îi epuizează pe toți și produce o estimare falsă-precisă.
5. Buffer pentru imprevizibil
Lasă 15-20% din capacity neangajat. Nu pentru "extra story", ci pentru bug-fixing urgent, întâlniri tehnice de design, code review, ajutor între membri. Echipele care umplu 100% din capacity ratează sistematic pentru că orice mică perturbare devine criză.
Aceste 15-20% nu sunt timp "pierdut" — sunt timpul în care echipa de fapt produce calitate. Dacă într-un sprint nu ai folosit deloc buffer-ul (rar), poți trage un story extra din backlog în ziua 7-8 ca stretch goal.
Planifici sprintul în 4myprojects
Backlog cu refinement vizibil, capacity calculat din concedii și status istoric, Sprint Goal pe board, sparge-story-în-tasks dintr-un click — și AI care îți spune înainte de planning dacă scope-ul depășește capacitatea.