Ghidul Scrum

Ghidul Absolut al Scrum: Regulile Jocului

Octombrie 2011

Dezvoltat i susinut de ctre Ken Schwaber i Jeff Sutherland

Cuprins
Scopul Ghidului Scrum............................................................................................................................3 Prezentare Scrum ...................................................................................................................................3 Cadrul Scrum ......................................................................................................................................3 Teoria Scrum...........................................................................................................................................4 Scrum ......................................................................................................................................................5 Echipa Scrum ..........................................................................................................................................5 Product Owner ...................................................................................................................................5 Echipa de Dezvoltare ..........................................................................................................................6 Scrum Master .....................................................................................................................................6 Evenimentele Scrum (Scrum Events)......................................................................................................7 Sprint-ul (The Sprint) ..........................................................................................................................8 edina de Planificare a Sprint-ului (Sprint Planning Meeting) ..........................................................9 edina Scrum Zilnic (Daily Scrum) ................................................................................................ 10 edina de Revizuire a Sprint-ului (Sprint Review) .......................................................................... 11 Retrospectiva Sprint-ului (Sprint Retrospective)............................................................................. 12 Artefacte Scrum ................................................................................................................................... 12 Product Backlog ............................................................................................................................... 12 Sprint Backlog .................................................................................................................................. 14 Incrementul ..................................................................................................................................... 15 Definiia strii Finalizat..................................................................................................................... 15 Concluzie ............................................................................................................................................. 15 Mulumiri............................................................................................................................................. 16 Oamenii ........................................................................................................................................... 16 Istoria............................................................................................................................................... 16 Traducerea....................................................................................................................................... 16

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 2

Scopul Ghidului Scrum

Scrum este un cadru pentru dezvoltarea i susinerea proceselor complexe. Acest ghid conine definiia Scrum-ului. Aceast definiie const n rolurile, evenimentele, artefactele Scrum-ului precum i regulile care le leag pe acestea mpreun. Ken Schwaber i Jeff Sutherland au dezvoltat Scrum-ul; Ghidul Scrum este scris i furnizat de ei. mpreun, ei stau n spatele Ghidului Scrum.

Prezentare Scrum
Scrum (subst.): un cadru n care oamenii i pot adresa probleme complexe de adaptare, livrnd n acelai timp, n mod productiv i creativ produse de cea mai mare valoare posibil. Scrum este: Uor Simplu de neles Extrem de dificil de stapnit

Scrum este un proces cadru utilizat pentru a gestiona dezvoltarea de produse complexe nc de la nceputul anilor 1990. Scrum nu este un proces sau o tehnic de construire a produselor; mai degrab este un cadru n care poi folosi diferite procese i tehnici. Scrum clarific eficacitatea relativ a managementului produsului i practicile de dezvoltare astfel nct se pot face mbuntiri.

Cadrul Scrum
Cadrul Scrum const n Echipele Scrum i n rolurile, evenimentele, artefactele i regulile asociate acestora. Fiecare component din cadru servete un anumit scop i este esenial n succesul i utilizarea Scrum-ului. Strategiile specifice de utilizare a cadrului Scrum variaz i vor fi descrise n alt parte. Regulile Scrum leag mpreun evenimentele, rolurile i artefactele, guvernnd relaiile i interaciunea dintre ele. Regulile Scrum sunt descrise n interiorul acestui document.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 3

Teoria Scrum
Scrum este bazat pe o teorie empiric de control a proceselor, sau empirism. Empirismul afirm faptul c sursa cunotinelor este experiena i luarea deciziilor se bazeaz pe ceea ce este tiut. Scrum folosete o abordare iterativ, incremental cu scopul de a optimiza predictibilitatea i de a controla riscul. Trei piloni susin orice implementare a controlului procesului empiric: transparena, inspecia i adaptarea.

Transparena
Aspecte semnificative ale procesului trebuie s fie vizibile celor responsabili de rezultate. Transparena necesit ca aceste aspecte s fie definite de un standard comun astfel nct observatorii s mprteasc puncte de vedere comune asupra a ceea ce vd. De exemplu: Un limbaj comun referitor la proces trebuie s fie mprtit de ctre toi participanii; i, O definiie comun a statusului Finalizat1 trebuie mprtit de ctre cei care efectueaz munca i cei care accept munca rezultat.

Inspecia
Utilizatorii Scrum trebuie s inspecteze n mod firesc progresul fcut ctre ndeplinirea obiectivului, astfel nct s detecteze abaterile nedorite. Inspecia lor nu trebuie s fie att de frecvent nct s afecteze modul de lucru. Inspeciile sunt cele mai benefice atunci cnd sunt efectuate n mod srguincios la locul de munc.

Adaptarea
Dac un inspector stabilete c unul sau mai multe aspecte ale procesului deviaz n afara unor limite acceptabile, i c produsul rezultat va fi inacceptabil, procesul sau materialul procesat trebuie s fie ajustat. Scrum recomand patru oportuniti formale pentru inspecie i adaptare, aa cum este descris n seciunea Evenimentele Scrum ale acestui document. edina de Planificare a Sprint-ului edina Scrum Zilnic Revizuirea Sprint-ului Retrospectiva Sprint-ului

Vezi Definiia strii Finalizat, p. 15.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 4

Scrum
Scrum este un cadru structurat n aa fel nct s susin dezvoltarea produselor complexe. Scrum const n Echipele Scrum i rolurile, evenimentele, artefactele i regulile asociate acestora. Fiecare component a cadrului servete un anumit scop i este esenial n succesul i utilizarea Scrum.

Echipa Scrum
Echipa Scrum este alctuit din Product Owner, Echipa de Dezvoltare i Scrum Master. Echipa Scrum se auto-organizeaz i este inter-funcional. Echipele auto-organizate mai degrab aleg ct de bine s-i fac munca dect s fie direcionai de alii din afara echipei. Echipele inter-funcionale au toate competenele necesare pentru a-i ndeplini munca far a depinde de alii care nu fac parte din echip. Echipa model n Scrum este proiectat astfel nct s optimizeze flexibilitatea, creativitatea i productivitatea. Echipa Scrum livreaz produsele n mod iterativ i incremental, maximiznd oportunitile de feedback. Livrrile incrementale de produse cu statusul Finalizat asigur c o versiune potenial folositoare a produsului n lucru este mereu disponibil.

Product Owner
Product Owner-ul este responsabil de maximizarea valorii produsului i a muncii Echipei de Dezvoltare. Modul n care acest lucru este fcut poate varia pe scar larg n funcie de organizaie, Echipa Scrum sau indivizi. Product Owner-ul este singura persoan responsabil de Product Backlog . Managementul Product Backlog-ului include: Exprimarea clar a elementelor din Product Backlog; Ordonarea elementelor din Product Backlog pentru a realiza cel mai bine obiectivele i misiunile; Garantarea valorii muncii produse de ctre Echipa de Dezvoltare; Garantarea faptului c Product Backlog-ul este vizibil, transparent i clar pentru toi, i c arat la ce va lucra Echipa Scrum n continuare; i, Garantarea faptului c Echipa de Dezvoltare nelege toate elementele din Product Backlog pn la nivelul necesar.

Product Owner-ul poate s fac activitile de mai sus sau poate delega Echipa de Dezvoltare s fac acest lucru. Totui, Product Owner-ul rmne responsabil. Product Owner-ul este o persoan, nu un comitet. Product Owner-ul poate reprezenta interesele unui comitet n Product Backlog, dar cei care vor s schimbe prioritatea elementelor din backlog trebuie s l conving pe Product Owner. Pentru ca Product Owner-ul s reueasc, ntreaga organizaie trebuie s-i respecte deciziile. Deciziile Product Owner-ului sunt vizibile n coninutul i ordinea elementelor din Product Backlog. Nimnui nu

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 5

i este permis s i spun Echipei de Dezvoltare s lucreze pe baza unui alt set de cerine, iar Echipei de Dezvoltare nu i este permis s acioneze la ceea ce spune oricine altcineva.

Echipa de Dezvoltare
Echipa de Dezvoltare const din profesioniti care fac din activitatea de livrare un potenial Increment, lansabil pe pia, al produsului Finalizat, la sfritul fiecrui Sprint. Echipa de Dezvoltare este structurat i mputernicit de ctre organizaie s-i organizeze i s-i gestioneze munca. Sinergia rezultat optimizeaz la nivel global eficiena i eficacitatea Echipei de Dezvoltare. Echipele de Dezvoltare au urmtoarele caracteristici: Ele se auto-organizeaz. Nimeni (nici mcar Scrum Master-ul) nu spune Echipei de Dezvoltare cum s transforme elementele din Product Backlog n poteniale Incrementuri ale funcionalitii ce pot fi lansate pe pia; Echipele de Dezvoltare sunt inter-funcionale i au toate competenele necesare ca echip pentru a crea un Increment al produsului; Scrum nu recunoate nici un titlu pentru membrii Echipei de Dezvoltare altul dect Dezvoltator, indiferent de munca care a fost efectuat de persoana respectiv; nu exist excepii de la aceast regul; Diferii membri ai Echipei de Dezvoltare pot avea competene specializate i zone de focalizare, dar responsabilitatea aparine Echipei de Dezvoltare ca un ntreg; i, Echipa de Dezvoltare nu conine sub-echipe dedicate unui domeniu particular cum ar fi testarea sau analiza afacerii.

Dimensiunea Echipei de Dezvoltare

Echipa de Dezvoltare optim este destul de mic nct s rmn agil i destul de mare nct s execute o munc semnificativ. Un numr mai mic de trei membri n Echipa de Dezvoltare scade interaciunea i rezult n ctiguri mici de productivitate. Echipele de Dezvoltare mai mici pot ntlni constrngeri legate de competene pe parcursul unui Sprint, cauznd ca Echipa de Dezvoltare s fie incapabil s livreze un potenial Increment lansabil pe pia. Cnd sunt mai mult de nou membri este necesar prea mult coordonare. Echipele de Dezvoltare mari genereaz prea mult complexitate de gestionat pentru un proces empiric. Rolurile de Product Owner i Scrum Master nu sunt luate n calcul dect dac ei execut i lucrri din Product Backlog.

Scrum Master
Scrum Master-ul este responsabil ca Scrum s fie neles i adoptat. Scrum Master-ul face acest lucru prin asigurarea c Echipa Scrum ader la teoria, practicile i rolurile Scrum. Scrum Master-ul este un servitor-conductor pentru Echipa Scrum. Scrum Master-ul i ajut pe cei din afara Echipei Scrum s neleag care din interaciunile lor cu Echipa Scrum sunt folositoare i care nu. Scrum Master-ul ajut pe toat lumea s schimbe aceste interaciuni astfel nct s maximizeze valoarea creat de Echipa Scrum.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 6

Serviciile Scrum Master-ului pentru Product Owner

Scrum Master-ul l ajut pe Product Owner n mai multe moduri, incluznd: Gsirea tehnicilor de gestionare eficace a Product Backlog-ului; Comunicarea clar a viziunii, obiectivelor i a elementelor din Product Backlog ctre Echipa de Dezvoltare; Instruirea Echipei Scrum n crearea clar i concis a elementelor din Product Backlog; nelegerea planificrii pe termen lung intr-un mediu de dezvoltare empiric; nelegerea i practicarea metodelor agile; i, Facilitarea evenimentelor Scrum dup cum este cerut sau necesar.

Serviciile Scrum Master-ului pentru Echipa de Dezvoltare

Scrum Master-ul ajut Echipa de Dezvoltare n mai multe moduri, incluznd: Antrenarea Echipei de Dezvoltare s foloseasc auto-organizarea i inter-funcionalitatea; Instruirea i direcionarea Echipei de Dezvoltare n aa fel nct s creeze produse de valoare mare; Eliminarea impedimentelor din calea progresului Echipei de Dezvoltare; Facilitarea evenimentelor Scrum dup cum este cerut sau necesar; i, Instruirea Echipei de Dezvoltare n mediile organizaionale unde Scrum nu a fost pe deplin adoptat sau neles.

Serviciile Scrum Master-ului pentru Organizaie

Scrum Master-ul ajut organizaia n mai multe moduri, incluznd: Direcionarea i pregtirea organizaiei n procesul de adoptare Scrum; Planificarea implementrilor Scrum n cadrul organizaiei; Ajutarea angajailor i a celor implicai s neleag precum i s adopte Scrum i dezvoltarea empiric a produselor; Cauzarea schimbrilor ce duc la creterea productivitii Echipei Scrum; i, Colaborarea cu ali Scrum Master-i pentru a crete eficacitatea aplicrii Scrum-ului n cadrul organizaiei.

Evenimentele Scrum (Scrum Events)

Evenimentele prestabilite n mod regulat din Scrum sunt utilizate pentru a minimiza necesitatea unor reuniuni ocazionale. n Scrum acestea sunt evenimente limitate n timp, astfel nct fiecare are o durat maxim. Aceasta asigur o cantitate adecvat de timp dedicat planificrii, fr a permite pierderi n procesul de planificare. n afara Sprint-ului propriu-zis, care este un container pentru toate celelalte evenimente, fiecare eveniment n Scrum reprezint o oportunitate formal de a inspecta i a adapta ceva. Aceste evenimente sunt concepute special pentru a permite o transparen decisiv i inspecie. Omiterea includerii oricruia dintre aceste evenimente duce la o transparen redus i de asemenea este o ocazie pierdut de a inspecta i a adapta.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 7

Sprint-ul (The Sprint)

Inima Scrum-ului este un Sprint, cu o durat de maxim o lun, n timpul cruia este creat un Increment al produsului, cu statusul "Finalizat" ("Done"), utilizabil i potenial livrabil. Sprint-urile au durate consistente pe toat durata efortului de dezvoltare. Un Sprint nou ncepe imediat dup aflarea concluziilor Sprint-ului anterior. Sprint-urile conin i constau din edina de Planificare a Sprint-ului (Sprint Planning Meeting), edina Scrum Zilnic (Daily Scrums), activitatea de dezvoltare, Revizuire a Sprint-ului (Review Meeting) i Retrospectiva Sprint-ului (Sprint Retrospective). n timpul Sprint-ului: Nu se aduc modificri care ar putea afecta obiectivul Sprint-ului; Componena echipei de dezvoltare rmne constant; Calitatea obiectivelor nu scade; i, Posibilitile (scope) pot fi clarificate i re-negociate ntre Product Owner i echipa de Dezvoltare (Development Team) pe masur ce se progreseaz.

Fiecare Sprint poate fi considerat un proiect cu un orizont de timp nu mai mare de o lun. La fel ca i proiectele, Sprint-urile sunt folosite pentru a realiza ceva. Fiecare Sprint are o definiie a ceea ce urmeaz s fie construit, un design i un plan flexibil, care l vor ghida n procesul de realizare ct i n produsul rezultat. Sprint-urile se limiteaz la o lun calendaristic. Atunci cnd orizontul de timp al Sprint-ului este prea lung, definirea a ceea ce este n curs de a fi construit se poate modifica i pot crete att complexitatea ct i riscul. Sprint-urile aduc predictibilitate prin asigurarea inspeciei i adaptarea a ceea ce se realizeaz spre un scop cel puin n fiecare lun calendaristic. De asemenea Sprint-urile limiteaz riscurile de cost la cel mult o lun calendaristic.

Anularea unui Sprint

Un Sprint poate fi anulat nainte de expirarea duratei limitate n care se ncadreaz Sprint-ul respectiv. Numai Product Owner-ul are autoritatea de a anula Sprint-ul, dei el sau ea pot face acest lucru sub influena celor implicai, Echipei de Dezvoltare sau a Scrum Master-ului. Un Sprint ar putea fi anulat i n cazul n care inta Sprint-ului devine perimat. Acesta s-ar putea ntmpla n cazul n care compania i schimb direcia sau n cazul n care condiiile de pia sau de tehnologie se schimb. n general, un Sprint ar trebui s fie anulat n cazul n care nu mai are sens, date fiind circumstanele. Dar anularea acestora are foarte rar sens, din cauza duratei reduse a Sprint-urilor. Atunci cnd un Sprint este anulat, toate activitile din Product Backlog completate i "Finalizate" ("Done") sunt verificate. Dac o parte a lucrrilor realizate sunt potenial livrabile, de obicei Product Owner-ul le va accepta. Toate prile incomplete din Product Backlog sunt re-evaluate i readuse n Product Backlog. Lucrrile efectuate asupra lor se depreciaz rapid i trebuie s fie frecvent reevaluate.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 8

Anulrile Sprint-urilor consum resurse, deoarece toat lumea trebuie s se regrupeze ntr-o alt edin de Planificare a Sprint-ului (Sprint Planning Meeting) pentru a ncepe un alt Sprint. Anulrile Sprint-urilor sunt adesea traumatizante pentru Echipa Scrum, i sunt foarte rar ntlnite.

edina de Planificare a Sprint-ului (Sprint Planning Meeting)

Activitatea care urmeaz s fie efectuat n Sprint este planificat la edina de Planificare a Sprintului. Acest plan este creat de munca coroborat a ntregii Echipe Scrum. edina de Planificare a Sprint-ului este o ntlnire limitat la 8 ore pentru un Sprint de o lun. Pentru Sprint-uri mai scurte, evenimentul este proporional mai scurt. De exemplu, un Sprint de dou sptmni va avea o edin de Planificare a Sprint-ului de patru ore. edina de Planificare a Sprint-ului este format din dou pri, fiecare fiind jumtate din durata ntregii ntlniri. Cele dou pri trebuie sa rspund la urmtoarele ntrebri, respectiv: Ce va fi livrat n Incrementul care rezult din Sprint-ul viitor? Cum va fi efectuat munca necesar pentru ca acest Increment s poat fi realizat?

Partea nti: Ce se va realiza n acest Sprint?

n aceast seciune, Echipa de Dezvoltare (Development Team) lucreaz pentru prognozarea funcionalitii care va fi dezvoltat pe parcursul Sprint-ului. Product Owner-ul prezint elementele ordonate din Product Backlog Echipei de Dezvoltare i ntreaga Echip Scrum colaboreaz la nelegerea a ceea ce trebuie realizat in cadrul Sprint-ului. Datele de intrare la aceast ntlnire sunt Product Backlog, cel mai recent Increment al produsului, capacitatea proiectat a Echipei de Dezvoltare n timpul Sprint-ului i performanele anterioare ale Echipei de Dezvoltare. Numrul de activiti (items) selectate din Product Backlog pentru Sprint este numai la latitudinea Echipei de Dezvoltare. Numai Echipa de Dezvoltare poate evalua ce poate realiza n Sprint-ul urmtor. Dup ce Echipa de Dezvoltare previzioneaz elementele din Product Backlog pe care le va livra n Sprint, ntreaga Echip Scrum definete obiectivul Sprint-ului. inta Sprint-ului este un obiectiv care va fi ndeplinit n cadrul Sprint-ului prin implementarea Product Backlog-ului i furnizeaz ndrumri Echipei de Dezvoltare despre motivul construirii Incrementului.

Partea a doua: Cum se vor realiza activitile alese?

Dup selectarea a ceea ce este de fcut n cadrul Sprint-ului, Echipa de Dezvoltare decide cum va implementa pe durata Sprint-ului aceast funcionalitate ntr-un Increment al produsului avnd statusul Finalizat (Done). Elementele din Product Backlog selectate pentru acest Sprint, plus planul pentru livrarea lor se numete Sprint Backlog. Echipa de Dezvoltare ncepe de obicei cu proiectarea sistemului i a activitilor necesare convertirii Product Backlog-ului ntr-un Increment funcional al produsului. Activitatea poate varia n funcie de dimensiuni sau efort estimat. Cu toate acestea, o activitate suficient este planificat n cursul Planificrii Sprint-ului pentru ca Echipa de Dezvoltare s previzioneze ceea ce este posibil de realizat

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 9

n urmtorul Sprint. Activitile planificate pentru primele zile ale Sprint-ului de ctre Echipa de Dezvoltare sunt descompuse n uniti de o zi sau mai puin pn la sfritul acestei reuniuni. Echipa de Dezvoltare se auto-organizeaz pentru ndeplinirea activitilor preluate din Backlog-ul Sprint-ului, aa cum este necesar, att n timpul Planificrii Sprint-ului ct i pe parcursul Sprint-ului. Product Owner-ul poate fi prezent n a doua parte a edinei de Planificare a Sprint-ului (Sprint Planning Meeting) pentru a clarifica activitile selectate din Product Backlog i pentru ajuta s se fac compromisuri. n cazul n care Echipa de Dezvoltare determin c e prea mult sau prea puin de lucru, se pot renegocia elementele din Sprint Backlog cu Product Owner-ul. De asemenea, Echipa de Dezvoltare poate invita alte persoane s participe, cu scopul de a oferi consultan tehnic sau de specialitate. Pn la sfritul Planificrii Sprint-ului, Echipa de Dezvoltare ar trebui s fie capabil s explice Product Owner-ului i Scrum Master-ului cum intenioneaz s lucreze ca o echip auto-organizat pentru a ndeplini obiectivul Sprint-ului i de a crea Incrementul anticipat.

Obiectivul Sprint-ului
Obiectivul Sprint-ului ofer Echipei de Dezvoltare un anumit grad de flexibilitate n ceea ce privete funcionalitatea implementat n cadrul Sprint-ului. Pe msur ce Echipa de Dezvoltare lucreaz, aceasta se va ghida dup acest obiectiv. n scopul de a ndeplini obiectivul Sprint-ului, aceasta implementeaz funcionalitatea i tehnologia. n cazul n care Echipa de Dezvoltare descoper c activitatea de dezvoltare se dovedete a fi altfel dect s-ar fi ateptat, atunci ea colaboreaz cu Product Owner-ul pentru a negocia obiectivul Sprint Backlog-ului, n cadrul Sprint-ului. Obiectivul Sprint-ului poate fi un jalon (milestone) n cadrul scopului mai mare al planului de produs.

edina Scrum Zilnic (Daily Scrum)

edina Scrum Zilnic este un eveniment de 15 minute pentru ca Echipa de Dezvoltare s i sincronizeze activitile i pentru a crea un plan pentru urmtoarele 24 de ore. Acest lucru se face prin inspectarea activitilor desfurate de la ultima ntlnire i prognozarea activitilor ce ar putea fi realizate nainte de urmtoarea ntlnire. edina Scrum Zilnic se desfaoar n aceeai locaie i la aceeai or n fiecare zi pentru a reduce complexitatea. n timpul ntlnirii, fiecare membru al Echipei de Dezvoltare, detaliaz: Ce s-a realizat de la ultima ntlnire? Ce va fi fcut pn la urmtoarea ntlnire? Ce obstacole sau piedici au aprut pe parcurs?

Echipa de Dezvoltare utilizeaz ntlnirea zilnic pentru a evalua progresul realizat spre Obiectivul Sprint-ului ct i pentru a evalua tendina progresului spre finalizarea lucrrilor din Sprint Backlog. ntlnirea optimizeaz probabilitatea ca Echipa de Dezvoltare s realizeze Obiectivul Sprintului. Adesea, Echipa de Dezvoltare se ntlnete dup aceast edin Scrum Zilnic pentru a replanifica restul lucrrilor din cadrul Sprint-ului. n fiecare zi, Echipa de Dezvoltare trebuie s fie

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 10

capabil s explice Product Owner-ului i Scrum Master-ului modul n care intenioneaz s lucreze mpreun ca o echip auto-organizat pentru a realiza scopul propus i pentru a crea Incrementul anticipat n perioada care a rmas din Sprint. Scrum Master-ul se asigur c Echipa de Dezvoltare se reunete, dar aceasta este responsabil pentru desfaurarea edinei Scrum Zilnice. Scrum Master-ul instruiete Echipa de Dezvoltare s in edina Scrum Zilnic n cadrul duratei de 15 minute. Scrum Master-ul impune regula ca numai membrii Echipei de Dezvoltare s participe la edina Scrum Zilnic. edina Scrum Zilnic nu este o ntlnire de reportare ci este adresat persoanelor care transform elementele din Product Backlog ntr-un Increment. edina Scrum Zilnic mbuntete comunicarea, elimin alte ntlniri, identific i ndeprteaz obstacolele, evideniaz i promoveaz luarea rapid a deciziilor i mbuntete nivelul de cunoatere a proiectului de ctre Echipa de Dezvoltare. Aceast ntlnire cheie este una de inspecie i de adaptare.

edina de Revizuire a Sprint-ului (Sprint Review)

Aceast edin de Revizuire a Sprint-ului (Sprint Review Meeting) este inut la sfritul Sprint-ului cu scopul de a se inspecta Incrementul i dac este necesar, se adapteaz Product Backlog-ul. n timpul edinei de Revizuire a Sprint-ului, Echipa Scrum i cei implicai colaboreaz cu privire la ceea ce s-a realizat n Sprint. Pornind de la aceast dezvoltare i de la orice alt modificare adus Product Backlog-ului n timpul Sprint-ului, participanii conlucreaz la aciunile urmtoare care ar putea fi realizate. Aceasta este o ntlnire informal, iar prezentarea Incrementului este destinat solicitrii de feedback i ncurajeaz colaborarea. Aceasta este o edin limitat la 4 ore pentru Sprint-urile de o lun. Pentru Sprint-urile mai scurte va fi alocat mai putin timp, n mod proporional. De exemplu, Sprint-urile de dou sptmni au edine de Revizuire a Sprint-ului de dou ore. edina de Revizuire a Sprint-ului cuprinde urmtoarele elemente: Product Owner-ul identific ceea ce a fost "Finalizat" i ceea ce nu a fost "Finalizat"; Echipa de Dezvoltare discut despre ceea ce a mers bine n timpul Sprint-ului, problemele de care s-a lovit i modul n care acele probleme au fost soluionate; Echipa de Dezvoltare demonstreaz lucrrile care au fost "Finalizate" i rspunde la ntrebri cu privire la Increment; Product Owner-ul discut Product Backlog-ul aa cum se prezint la momentul respectiv. El sau ea preconizeaz datele posibile de finalizare bazate pe progresele nregistrate pn n present; i, ntregul grup colaboreaz asupra a ceea ce urmeaz s fac n continuare, astfel nct aceast ntlnire asigur o contribuie valoroas pentru ulterioarele edine de Planificare ale Sprint-ului (Sprint Planning Meeting).

Rezultatul edinei de Revizuire a Sprint-ului este un Product Backlog revizuit care definete elementele probabile din cadrul acestuia pentru urmtorul Sprint. De asemenea, Product Backlog-ul poate fi revizuit pe ansamblu pentru a satisface noi oportuniti.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 11

Retrospectiva Sprint-ului (Sprint Retrospective)

Retrospectiva Sprint-ului reprezint o oportunitate pentru Echipa Scrum de a se auto-inspecta i de a crea un plan pentru mbuntiri care urmeaz s fie adoptate n cadrul Sprint-ului urmtor. Retrospectiva Sprint-ului are loc dup edina de Revizuire a Sprint-ului (Sprint Review Meeting) i nainte de edina de Planificare a Spint-ului urmtor (Sprint Planning Meeting). Aceasta este o edin limitat la 3 ore pentru Sprint-urile de o lun. n mod proporional se aloc mai puin timp Sprint-urilor mai scurte. Scopul Retrospectivei Sprint-ului este: De a inspecta modul n care ultimul Sprint a funcionat cu privire la oameni, relaii, proces, i instrumente; De a identifica i ordona elementele majore care au mers bine i mbuntirile poteniale; i, De a crea un plan pentru punerea n aplicare a mbuntirilor n modul n care Echipa Scrum i desfoar activitatea. Scrum Master-ul ncurajeaz Echipa Scrum s-i mbunteasc, n cadrul contextului Scrum, procesul su de dezvoltare i practicile sale, pentru ca acestea s devin mai eficiente i mai plcute n Sprint-ul urmtor. n timpul fiecrei edine Retrospective a Sprint-ului (Sprint Retrospective Meeting), Echipa Scrum planific moduri de cretere a calitii produselor prin adaptarea Definiiei "Finalizat", dup caz. La sfritul Retrospectivei Sprint-ului, Echipa Scrum trebuie s fi identificat mbuntirile pe care le va implementa n urmtorul Sprint. Punerea n aplicare a acestor mbuntiri n urmtorul Sprint reprezint adaptarea la auto-inspecie a Echipei Scrum nsi. Dei mbuntirile pot fi puse n aplicare n orice moment, Retrospectiva Sprint-ului este un eveniment formal, axat pe inspecie i adaptare.

Artefacte Scrum
Artefactele Scrum reprezint munca sau valoarea sub diverse forme care sunt folosite n asigurarea transparenei i a oportunitilor pentru inspecie i adaptare. Artefactele definite de Scrum sunt special concepute pentru a maximiza transparena informaiei, cheie necesar s asigure Echipelor Scrum succesul n livrarea unui Increment considerat "Finalizat".

Product Backlog
Product Backlog-ul este o list ordonat cuprinznd tot ce poate fi necesar n produs i este singura surs de cerine coninnd toate schimbrile care trebuie fcute produsului. Proprietarul Produsului (Product Owner) este responsabil de Product Backlog, incluznd coninutul su, disponibilitatea i ordinea sarcinilor. Product Backlog nu este niciodat complet. Cea mai timpurie dezvoltare a sa prezint cerinele iniiale, cunoscute i cel mai bine nelese. Product Backlog evolueaz odat cu produsul i mediul n care acesta evolueaz. Product Backlog este dinamic, se schimb constant pentru a identifica ceea ce

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 12

are nevoie produsul pentru a fi adecvat, competitiv i folositor. Atta timp ct un produs exist, va exista i Product Backlog-ul acestuia. Product Backlog listeaz toate caracteristicile, facilitile, funciile, cerinele, mbuntirile i remediile/reparaiile care constituie schimbrile necesare a fi facute produsului n release-urile viitoare. Elementele din Product Backlog au atribute precum descrierea, ordinea i estimarea. Product Backlog este adesea ordonat dup valoare, risc, prioritate i necesitate. Elementele cu cea mai mare prioritate vor fi dezvoltate imediat transformndu-se n activiti de dezvoltare. Cu ct mai mare este prioritatea, cu att elementul din backlog este mai urgent, cu att mai mult a fost analizat i exist mai mult consens privind valoarea sa. Elementele din Product Backlog cu prioritate mai mare sunt mai clare i mai detaliate dect cele de prioritate mai mic. Estimrile mai bune se fac atunci cnd elementul este definit clar i detaliat. Cu ct prioritatea elementului este mai mic, cu att acesta este mai puin detaliat, pn cnd devine foarte vag. Elementele din Product Backlog care vor ocupa Echipele de Dezvoltare pentru urmtoarele cteva Sprint-uri conin elemente prelucrate n amnunt, descompuse astfel nct orice element s poat fi Finalizat (Done) n cadrul duratei unui Sprint. Elementele din Product Backlog care pot fi Finalizate de Echipa de Dezvoltare n cadrul unui Sprint sunt considerate pregtite (ready) sau gata de aciune (actionable) pentru selectarea fcut la Planificarea Sprint-ului. Pe msur ce un produs este folosit i capt valoare, rspunsul (feedback-ul) oferit de pia crete iar Product Backlog-ul devine o list mai cuprinztoare i mai complet (exhaustiv). Sarcinile se modific n continuu astfel c Product Backlog-ul este un artefact viu. Schimbrile n cerinele de afaceri, condiiile de pia sau cele tehnologice pot cauza schimbri n Product Backlog. Adesea mai multe Echipe Scrum lucreaz mpreun la acelai produs. Un Product Backlog este utilizat pentru a descrie munca ce trebuie fcut pe produs. Un atribut al Product Backlog-ului care grupeaz elementele este n acest caz utilizat. ntreinerea Product Backlog-ului reprezint activitatea de adugare de detalii, estimri i ordonare a elementelor din Product Backlog. Acesta este un proces n continu desfurare n care Product Owner-ul i Echipa de Dezvoltare colaboreaz asupra stabilirii detaliilor din Product Backlog. n timpul ntreinerii Product Backlog-ului, elementele sunt reexaminate i revizuite. Totui, acestea pot fi actualizate la orice moment de timp de ctre Product Owner sau la discreia acestuia. ntreinerea este o activitate mprit n timpul Sprint-ului ntre Product Owner i Echipa de Dezvoltare. Adesea, Echipa de Dezvoltare are cunotinele de domeniu necesare pentru a realiza aceast ntreinere de una singur. Cum i cnd ntreinerea este facut se decide de ctre Echipa Scrum. Aceast ntreinere nu consum de regul mai mult de 10% din capacitatea Echipei de Dezvoltare. Echipa de Dezvoltare este responsabil de toate estimrile. Product Owner-ul poate influena Echipa de Dezvoltare prin a o ajuta s neleag i s selecteze compromisurile, dar membrii echipei care vor lucra efectiv fac estimrile finale.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 13

Monitorizarea Progresului ctre un Obiectiv

La orice moment de timp, volumul de munc rmas pentru a atinge obiectivul poate fi nsumat. Product Owner-ul urmrete acest volum de munc rmas cel puin la fiecare Revizuire a Sprintului (Sprint Review). Product Owner-ul compar acest volum de munc rmas cu volumul de munc rmas de la edinele de Revizuire Sprint anterioare (Sprint Reviews) cu scopul de a evalua progresul fcut spre finalizarea activitii planificate n funcie de timpul dorit pentru atingerea obiectivului. Aceast informaie este transparent pentru toate prile interesate. Diverse diagrame burndown, burnup i alte practici de proiecie au fost folosite pentru a se previziona progresul. Acestea s-au dovedit folositoare. Totui, acestea nu nlocuiesc importana empirismului. n mediile complexe, ceea ce se va ntmpla este necunoscut. Numai ceea ce s-a ntmplat deja poate fi utilizat n viitoarele luri de decizii.

Sprint Backlog
Sprint Backlog-ul reprezint un set de elemente/activiti ale Product Backlog-ului selectate pentru Sprint, plus un plan de livrare al Incrementului cu scopul de a realiza Obiectivul Sprint-ului. Sprint Backlog-ul reprezint o prognoz dat de Echipa de Dezvoltare cu privire la funcionalitatea cuprins n urmtorul Increment precum i de munca necesar pentru a livra aceast funcionalitate. Sprint Backlog-ul definete activitatea Echipei de Dezvoltare ce se va efectua pentru a transforma elementele din Product Backlog ntr-un Increment Finalizat. Sprint Backlog-ul asigur transparena muncii pe care Echipa de Dezvoltare o identific ca fiind necesar pentru a ndeplini Obiectivul Sprintului. Sprint Backlog-ul este un plan cu detalii suficiente astfel nct modificrile survenite pe parcurs pot fi nelese n Sedinele Zilnice de Scrum. Echipa modific Sprint Backlog-ul de-a lungul Sprint-ului i astfel se contureaz Sprint Backlog-ul. Aceast definire apare pe msur ce Echipa parcurge activitile din Sprint i i d seama de munca necesar pentru a atinge Obiectivul Sprint-ului. Echipa de Dezvoltare adaug la Sprint Backlog activitile noi ce apar de-a lungul unui Sprint. Pe msur ce activitile sunt efectuate sau finalizate i estimarea muncii rmase este actualizat. Elementele planului considerate inutile vor fi eliminate. Numai Echipa de Dezvoltare poate schimba Sprint Backlog-ul n timpul unei iteraii. Sprint Backlog-ul este vizibil, reprezint o imagine n timp real a muncii pe care Echipa de Dezvoltare intenioneaz s o realizeze n timpul Sprint-ului i aparine exclusiv Echipei de Dezvoltare.

Monitorizarea Progresului ntr-un Sprint

n orice moment din Sprint se poate nsuma munca total rmas a activitilor din Sprint Backlog. Echipa de Dezvoltare monitorizeaz aceast munc zilnic, cu ajutorul edinelor Zilnice de Scrum. Echipa monitorizeaz munca rmas zilnic cu scopul de a estima ct mai realist probabilitatea de realizare a Obiectivului din Sprint dar i pentru a-i gestiona progresul. Scrum-ul nu ia n considerare timpul consumat pentru lucrul la elementele din Product Backlog. Timpul de lucru rmas i data sunt singurele variabile de interes.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 14

Incrementul
Incrementul reprezint suma tuturor elementelor din Product Backlog finalizate de-a lungul unui Sprint alturi de toate Sprint-urile anterioare. La sfritul unui Sprint, noul Increment trebuie s fie n stadiul de Finalizat, ceea ce nseamn c trebuie s fie utilizabil i n concordan cu ceea ce Echipa Scrum identific ca fiind definiia strii Finalizat. Incrementul trebuie s fie utilizabil indiferent de decizia Product Owner-ului de a-l livra sau nu.

Definiia strii Finalizat

Cnd un element din Product Backlog sau un Increment este descris ca Finalizat, toi trebuie s neleag aceast stare. Dei definiia strii Finalizat difer de la o Echip Scrum la alta, membrii trebuie s aib o nelegere comun a ceea ce nseamn lucrul care urmeaz s fie terminat, pentru a asigura transparen. Aceasta este definiia strii Finalizat folosit de Echipa Scrum pentru a determina cnd munca este complet pentru Increment. Aceeai definiie ndrum Echipa de Dezvoltare n a ti cte activiti din Product Backlog poate selecta n cadrul Sedinei de Planificare a Sprint-ului. Scopul fiecrui Sprint este de a obine Incrementuri potenial livrabile, n starea Finalizat conform cu definiia Echipei Scrum. Echipa de Dezvoltare furnizeaz un Increment de Produs n fiecare Sprint. Acest Increment este utilizabil, deci Product Owner-ul poate decide s l livreze imediat. Fiecare Increment se adaug la toate Incrementurile anterioare i este testat amnunit pentru a verifica dac toate Incrementurile din care este compus funcioneaz mpreun. Pe msur ce Echipa acumuleaz experien este de ateptat ca definiia strii Finalizat s se extind pentru a include criterii mai stricte, cu scopul de a asigura o calitate superioar a Incrementului.

Concluzie
Scrum-ul este gratuit i oferit n acest ghid. Rolul Scrum-ului, artefactele, evenimentele i regulile sale sunt imuabile. Dei punerea n aplicare a doar o parte din Scrum este posibil, rezultatul nu este Scrum. Scrum exist numai n toate elementele sale i funcioneaz precum un container pentru alte tehnici, metodologii i practici.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 15

Mulumiri
Oamenii
Din miile de persoane care au contribuit la Scrum, ar trebui s-i evideniem pe cei care au avut un rol n primii zece ani. La nceput a fost Jeff Sutherland, care a lucrat cu Jeff McKenna, i Ken Schwaber, care a lucrat cu Mike Smith i Chris Martin. Muli alii au contribuit n anii care au urmat i fr ajutorul lor Scrum nu ar fi fost att de perfecionat precum este n ziua de astzi. David Starr a furnizat perspective cheie i competene editoriale n formularea acestei versiuni a Ghidului Scrum.

Istoria
Ken Schwaber i Jeff Sutherland au fost primii care au co-prezentat Scrum la conferina OOPSLA n 1995. Aceast prezentare a documentat n mod esenial nvturile pe care Ken i Jeff le-au dobndit n cei civa ani anteriori de aplicare a Scrum-ului. Istoria Scrum este deja considerat lung. Pentru a onora primele locuri unde a fost ncercat i perfecionat, menionm Individual, Inc., Fidelity Investments, i IDX (astzi GE Medical).

Traducerea
Acest ghid a fost tradus din versiunea Englez original, furnizat de Ken Schwaber i Jeff Sutherland. Printre cei care au contribuit la traducerea n limba Romna se numr: Monica Ipate, Petru Furescu, Marius Delc i Alexandra Suciu. La revizuire a participat Raluca Lefticaru.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 16

Revisions
Acest Ghid Scrum din Octombrie 2011 este diferit de predecesorul su, Ghidul Scrum din Februarie 2010. n particular, am ncercat s eliminm tehnicile i practicile cele mai bune din nucleul Scrum. Acestea vor varia n funcie de circumstane. Vom ncepe un compendiu Best Practices ulterior, pentru a mprti o parte din experiena acumulat. Ghidul Scrum documenteaz Scrum aa cum a fost dezvoltat i susinut de mai mult de 20 de ani de ctre Jeff Sutherland i Ken Schwaber. Alte surse furnizeaz modele, procese i perspective despre cum practicile, nlesnirile i uneltele complementeaz cadrul Scrum. Acestea optimizeaz productivitatea, valoarea, creativitatea i onoarea.

1991-2011 Ken Schwaber i Jeff Sutherland, Toate drepturile rezervate

Page | 17