Cum planifici un sprint Scrum care chiar se livrează?

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 absențele deja știute, minus timpul rezervat pentru urgențe de producție, minus context switching. Rezultatul este capacity-ul real.

Dacă echipa are velocity istorică 35 SP per sprint, dar acest sprint pierde 2 zile pe absențe planificate ș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, story points și etichete pe fiecare item, Sprint Goal pe board, sparge-story-în-tasks dintr-un click — și velocity din sprinturile deja închise, ca reper concret la planning.

Citește în continuare