Sprintul

Sprinturile sunt evenimente cu durată fixă de o lună sau mai puțin pentru a crea o cadență consistentă de livrare și feedback pentru echipa Scrum. Cu cât durata Sprintului este mai scurtă, cu atât mai rapidă este bucla de feedback. De exemplu, Scrum Inc. lucrează în Sprint-uri de o săptămână.

Sprint-ul este un container al tuturor celorlalte evenimente. Un nou Sprint începe imediat după încheierea Sprintului anterior, iar fiecare Sprint începe de obicei cu Sprint Planning și se termină cu Sprint Review & Retrospectiva Sprintului. În timpul fiecărei zile a Sprintului, are loc un scurt eveniment numit Daily Scrum, care are rolul de a menține echipa aliniată și de a descoperi impedimentele pe care echipa le întâmpină legate de realizarea de progrese în Sprint Backlog. Toate activitățile și evenimentele necesare pentru a atinge Sprint Goal, inclusiv Sprint Planning, Daily Scrums, Sprint Review și Sprint Retrospective, au loc în cadrul Sprint-urilor.

Ciclul Sprint regulat servește la:

• Focalizarea livrării pe Sprint Goal. În fiecare Sprint, echipa ar trebui să dezvolte un increment potențial livrabil de software, o iterație utilizabilă a unui produs hardware sau, în cele din urmă: valoare distinctă pentru client.
• Dă echipei un feedback regulat și de înaltă calitate din partea clientului cu privire la valoarea livrată. Echipa poate apoi să inspecteze și să își adapteze atât procesul, cât și produsul, pe baza contribuțiilor reale și acționabile ale clienților.
• Măsurați producția echipei pe o perioadă consistentă și recurentă. Această măsurare a producției se numește Viteza echipei. Echipa poate folosi Velocity pentru a-și prognoza capacitatea de a livra munca în timp și pentru a crea planuri de sprint realiste pe baza datelor istorice.

Sprints permite predictibilitatea prin asigurarea inspecției și adaptării progresului către Product Goal cel puțin în fiecare lună calendaristică. Sprinturile mai scurte pot genera mai multe cicluri de învățare și pot limita riscul de cost și efort la un interval de timp mai mic. Atunci când orizontul unui Sprint este prea lung, Sprint Goal poate deveni invalid, complexitatea poate crește, iar riscul poate crește. Fiecare Sprint poate fi considerat un proiect scurt și poate fi anulat în cazul în care Sprint Goal devine caduc. Numai Product Owner are autoritatea de a anula sprintul.

.