Guidul Scrum

Ghidul Absolut al Scrum:

Regulile Jocului

Iulie 2013

Dezvoltat i susinut de ctre Ken Schwaber i Jeff Sutherland

Cuprins
Scopul Ghidului Scrum..................................................................................................................... 3
Prezentare Scrum ............................................................................................................................ 3
Teoria Scrum.................................................................................................................................... 3
Echipa Scrum ................................................................................................................................... 4
Product Owner-ul ........................................................................................................................ 5
Echipa de Dezvoltare ................................................................................................................... 5
Scrum Master .............................................................................................................................. 6
Evenimentele Scrum (Scrum Events)............................................................................................... 7
Sprint-ul (The Sprint) ................................................................................................................... 7
Planificarea Sprint-ului (Sprint Planning) .................................................................................... 9
edina Scrum Zilnic (Daily Scrum) .......................................................................................... 10
Revizuirea Sprint-ului (Sprint Review) ....................................................................................... 11
Retrospectiva Sprint-ului (Sprint Retrospective)....................................................................... 12
Artefacte Scrum ............................................................................................................................. 13
Product Backlog ......................................................................................................................... 13
Sprint Backlog ............................................................................................................................ 14
Incrementul ............................................................................................................................... 15
Transparena artefactului.............................................................................................................. 15
Definiia strii Finalizat (Definition of Done) ...................................................................... 16
End Note ........................................................................................................................................ 16
Mulumiri....................................................................................................................................... 17
Oamenii ..................................................................................................................................... 17
Istoria......................................................................................................................................... 17
Traducerea................................................................................................................................. 17
Schimbri ale ghidului Scrum ntre 2011 i 2013 .......................................................................... 18

2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 2

Scopul Ghidului Scrum

Scrum-ul este un cadru pentru dezvoltarea i susinerea produselor 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
Dificil de stpnit

Scrum este un cadru pentru procese care a fost folosit n managementul dezvoltrii 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
s se poat face mbuntiri.
Cadrul Scrum const n Echipele Scrum i n rolurile, evenimentele, artefactele i regulile
asociate acestora. Fiecare component din cadru servete unui anumit scop i este esenial n
succesul i utilizarea Scrum-ului.
Regulile Scrum leag mpreun evenimentele, rolurile i artefactele, guvernnd relaiile i
interaciunea dintre ele. Regulile Scrum sunt descrise n interiorul acestui document.
Strategiile specifice de utilizare a cadrului Scrum variaz i vor fi descrise n alt parte.

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 pe baza a 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.
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 3

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 Finalizat trebuie mprtit de ctre cei care efectueaz
munca i cei care accept munca rezultat.

Inspecia
Utilizatorii Scrum trebuie s inspecteze n mod frecvent artefactele i progresul fcut, astfel
nct s detecteze variaiile. Inspecia lor nu trebuie s fie att de frecvent nct s afecteze
lucrul n general. 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. O ajustare trebuie fcut ct mai curnd posibil pentru a minimiza
deviaiile ulterioare.
Scrum recomand patru evenimente formale n cadrul unui Sprint, pentru inspecie i adaptare,
aa cum este descris n seciunea Evenimentele Scrum ale acestui document:

Planificarea Sprint-ului (Sprint Planning)

edina Scrum Zilnic (Daily Scrum)
Revizuirea Sprint-ului (Sprint Review)
Retrospectiva Sprint-ului (Sprint Retrospective)

Echipa Scrum
Echipa Scrum este alctuit din Product Owner, Echipa de Dezvoltare i Scrum Master. Echipele
Scrum se auto-organizeaz i sunt 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 interfuncionale au toate competenele necesare pentru a-i ndeplini munca fr 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.
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 4

Product Owner-ul
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;
Optimizarea 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 pn la nivelul necesar toate
elementele din Product Backlog.

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 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 este format din profesioniti care fac din activitatea de livrare un
potenial Increment, lansabil pe pia, al produsului Finalizat, la sfritul fiecrui Sprint. Numai
membrii Echipei de Dezvoltare creeaz Incrementul.
Echipa de Dezvoltare este structurat i mputernicit de ctre organizaie s-i organizeze i si gestioneze munca. Sinergia rezultat optimizeaz la nivel global eficiena i eficacitatea
Echipei de Dezvoltare.
Echipele de Dezvoltare au urmtoarele caracteristici:

2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 5

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;
Scrum nu recunoate sub-echipe ale Echipei de Dezvoltare, indiferent de anumite domenii
particulare cum ar fi testarea sau analiza afacerii; nu exist excepii de la aceast regul; i,
Diferii membri ai Echipei de Dezvoltare pot avea competene specializate i zone de
focalizare, dar responsabilitatea aparine Echipei de Dezvoltare ca un ntreg.

Dimensiunea Echipei de Dezvoltare

Dimensiunea optim a Echipei de Dezvoltare este suficient de mic nct echipa sa rmn agil
i suficient de mare nct s poat termina o munca semnificativ n cadrul unui Sprint. Dac
sunt mai puin de trei membri n Echipa de Dezvoltare, interaciunile sunt mai puine i rezult n
creteri productive mai mici. Echipele de Dezvoltare mai mici pot ntlni limitri ale abilitilor n
timpul Sprint-ului, cauznd inabilitatea livrrii unui potenial Increment gata de lansare. Dac
Echipa de Dezvoltare are mai mult de nou membri, este nevoie de prea mult coordonare.
Echipele de Dezvoltare mari genereaz prea mult complexitate ca s poate fi administrate de
un proces empiric. Rolurile de Product Owner i Scrum Master nu sunt incluse n aceast
numrtoare dect dac muncesc la elemente aflate n Backlog-ul Sprint-ului.

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 (servant-leader) 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.

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 Backlog-ului Produsului;

Ajutarea Echipei Scrum s neleag necesitatea de a avea elemente clare i concise n
Backlog-ul Produsului;
nelegerea planificrii produsului ntr-un mediu de dezvoltare empiric;
Asigurarea c Product Owner-ul tie cum s aranjeze Backlog-ul Produsului astfel nct s
maximizeze valoarea;

2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 6

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;

Ajutarea Echipei de Dezvoltare 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 i s adopte Scrum precum 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. Toate evenimentele sunt limitate ca timp, n aa fel nct fiecare are o
durat maxim. Odat ce Sprint-ul ncepe, durata lui este fix i nu poate fi micorat sau
mrit. Celelalte evenimente se pot termina atunci cnd scopul evenimentului a fost atins,
asigurndu-se ca se petrece suficient timp, 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.

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. Sprint2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 7

urile au durate consistente de-a lungul efortului de dezvoltare. Un Sprint nou ncepe imediat
dup tragerea 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;

Obiectivele de calitate nu scad; i,
Scopul poate fi clarificat i re-negociate ntre Product Owner i Echipa de Dezvoltare pe
msur ce mai multe informaii devin disponibile.

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 alocate 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 elementele din Backlog-ul Produsului 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 Backlog-ul Produsului
sunt re-evaluate i readuse n Backlog-ul Produsului. Lucrrile efectuate asupra lor se
depreciaz rapid i trebuie s fie frecvent re-evaluate.
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
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 8

Sprint. Anulrile Sprint-urilor sunt adesea traumatizante pentru Echipa Scrum, i sunt foarte rar
ntlnite.

Planificarea Sprint-ului (Sprint Planning)

Activitatea care urmeaz s fie efectuat n Sprint este planificat la edina de Planificare a
Sprint-ului. Acest plan este creat de munca coroborat a ntregii Echipe Scrum.
edina de Planificare a Sprint-ului este o ntlnire limitat la un maxim de 8 ore pentru un
Sprint de o lun. Pentru Sprint-uri mai scurte, evenimentul este de obicei mai scurt. Scrum
Master-ul se asigur c evenimentul are loc i c participanii i neleg scopul. Tot Scrum
Master-ul nva echipa s se menin n limita de timp stabilit.
edina de Planificare a Sprint-ului rspunde la urmtoarele ntrebri:

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?

Subiectul unu: Ce se va realiza n acest Sprint?

Echipa de Dezvoltare lucreaz pentru prognozarea funcionalitii ce va fi dezvoltat pe
parcursul Sprint-ului. Product Owner-ul discut despre Obiectivele ce trebuie atinse n cadrul
Sprint-ului, i despre elementele din Backlog-ul Produsului, care, dac vor fi finalizate, ar ajuta la
ndeplinirea Obiectivului. ntreaga Echip Scrum colaboreaz la nelegerea a ceea ce trebuie
realizat n cadrul Sprint-ului.
Datele de intrare la aceast ntlnire reprezint Backlog-ul Produsului, 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 Backlog-ul Produsului 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 Backlog-ul Produsului pe care le va
livra n Sprint, ntreaga Echip Scrum definete obiectivul Sprint-ului. Obiectivul Sprint-ului este
un el care va fi ndeplinit n Sprint prin implementarea Backlog-ului Produsului, i poate oferi
ndrumri Echipei de Dezvoltare asupra motivului realizrii Incrementului.

Subiectul doi: Cum se vor realiza activitile alese?

Dup selectarea Obiectivului Sprint-ului i a elementelor pentru Sprint-ul curent din Backlog-ul
Produsului, Echipa de Dezvoltare decide cum va implementa pe durata Sprint-ului aceast
funcionalitate ntr-un Increment al produsului avnd statusul Finalizat (Done). Elementele
din Backlog-ul Produsului selectate pentru acest Sprint, plus planul pentru livrarea lor se numesc
Backlog-ul Sprint-ului.
Echipa de Dezvoltare ncepe de obicei cu proiectarea sistemului i a activitilor necesare
convertirii Backlog-ului Produsului ntr-un Increment funcional al produsului. Activitatea poate
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 9

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 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 ajuta la clarificarea activitilor selectate din Backlog-ul Produsului i la
realizarea compromisurilor. 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 autoorganizat pentru a ndeplini obiectivul Sprint-ului i pentru a crea Incrementul anticipat.

Obiectivul Sprint-ului (Sprint Goal)

Obiectivul Sprint-ului este un el ce poate fi atins n cadrul Sprint-ului prin implementarea
Backlog-ului Produsului. El ghideaz Echipa de Dezvoltare ctre motivul pentru care se
construiete Incrementul. Este creat n timpul edinei de Planificare a Sprint-ului. Obiectivul
Sprint-ului confer Echipei de Dezvoltare un anumit grad de flexibilitate n ceea ce privete
funcionalitatea implementat n cadrul Sprint-ului. Elementele selectate din Backlog-ul
Produsului livreaz o funcionalitate coerent, care poate s fie obiectivul Sprint-ului. Obiectivul
Sprint-ului poate fi orice alt coeren care face ca Echipa de Dezvoltare s lucreze mpreun,
mai degrab dect la iniiative separate.
Pe msur ce Echipa de Dezvoltare lucreaz, ei au n vedere Obiectivul Sprint-ului. Pentru a
satisface Obiectivul Sprint-ului, se implementeaz funcionalitatea i tehnologia. n cazul n care
munca depus se dovedete a fi diferit de ceea ce Echipa de Dezvoltare a ateptat, echipa
colaboreaz cu Product Owner-ul pentru a negocia Obiectivul Sprint Backlog-ului n cadrul
Sprint-ului.

edina Scrum Zilnic (Daily Scrum)

edina Scrum Zilnic este un eveniment de 15 minute cu scopul ca Echipa de Dezvoltare s i
sincronizeze activitile i s i creeze 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 pana la urmtoarea ntlnire.
edina Scrum Zilnic se desfoar n aceeai locaie i la aceeai or n fiecare zi pentru a
reduce complexitatea. n timpul ntlnirii, fiecare membru al Echipei de Dezvoltare, detaliaz:
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 10

Ce am fcut ieri pentru a ajuta Echipa de Dezvoltare s ating Obiectivul Sprint-ului?

Ce voi face azi pentru a ajuta Echipa de Dezvoltare s ating Obiectivul Sprint-ului?
Vd vreun impediment care m-ar putea mpiedica pe mine sau pe Echipa de Dezvoltare
s atingem Obiectivul Sprint-ului?

Echipa de Dezvoltare utilizeaz ntlnirea zilnic pentru a evalua progresul realizat spre
Obiectivul Sprint-ului i tendina progresului spre finalizarea lucrrilor din Sprint Backlog.
ntlnirea optimizeaz probabilitatea ca Echipa de Dezvoltare s realizeze Obiectivul Sprint-ului.
n fiecare zi, Echipa de Dezvoltare trebuie sa neleag modul n care intenioneaz s lucreze
mpreun ca o echip auto-organizat pentru a realiza Obiectivul Sprint-ului i pentru a
crea Incrementul anticipat nainte de finalul Sprint-ului. Adesea, Echipa de Dezvoltare, sau unii
din membri ei, se ntlnesc dup aceast edin Scrum Zilnic pentru o discuie mai detaliat,
sau pentru a adapta sau replanifica munca rmas din Sprint.
Scrum Master-ul se asigur c Echipa de Dezvoltare se reunete, dar aceasta este
responsabil pentru desfurarea 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 raportare ci este adresat persoanelor
care transform elementele din Backlog-ul Produsului 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.

Revizuirea Sprint-ului (Sprint Review)

Aceast Revizuire a Sprint-ului (Sprint Review) 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, nu una de status, 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 evenimentul este de obicei i el mai scurt. Scrum Master-ul se asigur c evenimentul are
loc i c participanii i neleg scopul. Tot Scrum Master-ul i nva pe toi s menin timpul
alocat evenimentului.
edina de Revizuire a Sprint-ului cuprinde urmtoarele elemente:

2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 11

ntre participani sunt inclui Membrii echipei i acionarii principali invitai de Product
Owner;
Product Owner-ul explic care elemente din Product Backlog au fost "Finalizate" i care nu
au fost "Finalizate";
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
prezent (dac este necesar);
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;
Se revizuiete cum s-ar fi putut schimba piaa sau felul de folosire al produsului, care este
cel mai valoros lucru ce poate fi fcut n continuare; i,
Se revizuiete organizarea n timp, bugetul, potenialele capabiliti i piaa pentru
urmtoarea versiune a produsului.

Rezultatul Revizuirii 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.

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 Revizuirea Sprint-ului (Sprint Review) i nainte de
Planificarea Sprint-ului urmtor (Sprint Planning). Aceasta este o edin limitat la 3 ore pentru
Sprint-urile de o lun. Pentru Sprint-uri mai scurte, evenimentul este i el mai scurt. Scrum
Master-ul se asigur c evenimentul are loc i c participanii i neleg scopul. Tot Scrum
Master-ul i nva pe toi s menin timpul alocat evenimentului. Scrum Master-ul particip ca
membru egal din echip, din punctul de vedere al responsabilitii legate de procesul de Scrum.
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.

2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 12

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 Retrospective a Sprintului, 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 n aa fel nct
toi s aib aceeai nelegere legat de artefact.

Product Backlog
Product Backlog-ul este o list ordonat cuprinznd tot ce poate fi necesar n cadrul produsului
i este singura surs de cerine coninnd toate schimbrile care trebuie fcute produsului.
Product Owner-ul este responsabil de Backlog-ul Produsului, incluznd coninutul su,
disponibilitatea sa i ordinea sarcinilor.
Product Backlog-ul nu este niciodat complet. Cea mai timpurie dezvoltare a sa prezint
cerinele iniiale, cunoscute i cel mai bine nelese. Product Backlog-ul evolueaz odat cu
produsul i mediul n care acesta evolueaz. Product Backlog-ul este dinamic, se schimb
constant pentru a identifica ceea ce 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-ul listeaz toate caracteristicile, facilitile, funciile, cerinele, mbuntirile i
remedierile ce constituie schimbrile necesare a fi fcute produsului n versiunile viitoare.
Elementele din Product Backlog au atribute precum descrierea, ordinea, estimarea i valoarea.
Pe msur ce un produs este folosit i capt valoare, i rspunsul (feedback-ul) oferit de pia
crete, 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.

2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 13

Adesea, mai multe Echipe Scrum lucreaz mpreun la acelai produs. Un singur Product Backlog
este utilizat pentru a descrie munca ce urmeaz a fi fcut pe produs. Un atribut al Product
Backlog-ului care grupeaz elementele poate fi utilizat n acest caz.
Rafinarea 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 rafinrii Product Backlog-ului, elementele sunt reexaminate i revizuite.
Echipa Scrum decide cum i cnd este fcut rafinarea. Rafinarea nu consum de regul mai
mult de 10% din capacitatea Echipei de Dezvoltare. Totui, elementele Product Backlog-ului pot
fi actualizate n orice moment de timp de ctre Product Owner sau la discreia acestuia.
Elementele din Product Backlog ordonate n susul listei sunt mai clare i mai detaliate dect cele
ordonate n josul listei. Estimrile mai precise se bazeaz pe o claritate mrit i pe un nivel
crescut al detaliilor; cu ct ordinea elementului este n josul listei, cu att acesta este mai puin
detaliat. Elementele din Product Backlog care vor ocupa Echipele de Dezvoltare pentru
urmtoarele cteva Sprint-uri sunt att de rafinate nct orice element s poat fi Finalizat
(Done) n cadrul duratei unui Sprint. Elementele din Product Backlog care pot fi Finalizate de
ctre Echipa de Dezvoltare n cadrul unui Sprint sunt considerate pregtite (ready) sau gata
de aciune (actionable) pentru selectarea fcut la Planificarea Sprint-ului. Elementele din
Product Backlog ajung n mod normal la acest grad de transparen datorit activitilor de
rafinare descrise mai sus.
Echipa de Dezvoltare este responsabil pentru 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.

Monitorizarea Progresului ctre un Obiectiv

n 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 burn-down, burn-up 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 ale Product Backlog-ului selectate pentru Sprint,
plus un plan de livrare al Incrementului i de realizare a Obiectivului Sprint-ului. Sprint Backlog-ul
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 14

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 ntr-un
Increment Finalizat.
Sprint Backlog-ul asigur transparena muncii pe care Echipa de Dezvoltare o identific ca fiind
necesar pentru a ndeplini Obiectivul Sprint-ului.
Sprint Backlog-ul este un plan cu detalii suficiente astfel nct modificrile survenite pe parcurs
pot fi nelese n edinele Zilnice de Scrum. Echipa modific Sprint Backlog-ul de-a lungul Sprintului 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.

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.

Transparena artefactului
Scrum-ul se bazeaz pe transparen. Deciziile de a optimiza valoarea i de a controla riscul se
iau pe baza strii percepute ale artefactelor. n msura n care transparena este complet,
aceste decizii au o baz solid. n msura n care artefactele sunt incomplet transparente, aceste
decizii pot fi eronate, valoarea se poate diminua i riscul poate crete.
Scrum Master-ul trebuie s lucreze cu Product Owner-ul, Echipa de dezvoltare, precum i cu alte
pri implicate pentru a nelege dac artefactele sunt complet transparente. Exist practici
pentru a face fa transparenei incomplete; Scrum Master-ul trebuie s-i ajute pe toi s aplice
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 15

practicile cele mai adecvate n lipsa de transparen total. Un Scrum Master poate detecta
transparena incomplet inspectnd artefactele, sesiznd modelele, ascultnd cu atenie la ceea
ce se spune, i detectnd diferenele dintre rezultatele ateptate i cele reale.
Treaba Scrum Master-ului este de a lucra cu Echipa Scrum i cu organizaia pentru a crete
transparena artefactelor. Acest lucru implic, de obicei, nvare, convingere, i schimbare.
Transparena nu se ntmpl peste noapte, dar este o cale.

Definiia strii Finalizat (Definition of Done)

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 edinei 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 al Produsului n fiecare Sprint. Acest Increment
este utilizabil, deci Product Owner-ul poate decide s l livreze imediat. Dac definiia "finalizat"
(definition of "done") pentru un increment este parte din convenii, standarde sau ghiduri ale
organizaiei de dezvoltare, toate Echipele Scrum trebuie minimum s o urmeze. Dac definiia
"finalizat" pentru un increment nu este o convenie a organizaiei de dezvoltare, Echipa de
Dezvoltare trebuie s conceap o definiie "finalizat" adecvat pentru produs. Dac exist mai
multe Echipe Scrum care lucreaz mpreun la un sistem sau o versiune de produs, echipele de
dezvoltare din toate Echipele Scrum trebuie s conceap reciproc definiia "Finalizat".
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 Scrum 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. Orice proiect sau sistem ar trebui s aib o definiie a strii Finalizat ce este
standard pentru orice munc efectuat.

End Note
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.
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 16

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.

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).
Ghidul Scrum documenteaz Scrum aa cum a fost dezvoltat i susinut de 20 de ani de Jeff
Sutherland i Ken Schwaber. Alte surse v ofer modele, procese, i perspective care
completeaz cadrul Scrum. Acestea optimizeaz productivitatea, valoarea, creativitatea, i
mndria.

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, Ana Vintil, Petru Furescu, Marius Delc i Alexandra Suciu. La revizuire au participat
Radu Orjanu i Maria Diaconu.

2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 17

Schimbri ale ghidului Scrum ntre 2011 i 2013

1. Artefactele trebuie s fie transparente pentru ca mecanismele Scrum de inspecie i
adaptare s fie eficiente.
2. edina Scrum zilnic este un eveniment de planificare venit exact la momentul potrivit.
Informaiile ce intr trebuie s se refere la modul cum echipa reuete s ndeplineasc
Obiectivul Sprint-ului; Informaiile ce ies trebuie s se refere la un nou plan sau un plan
revizuit ce optimizeaz eforturile echipei n a ndeplini Obiectivul Sprint-ului. Toate
conversaiile sunt orientate spre noi, echipa dect spre eu, dezvoltatorul.
3. Planificarea Sprint-ului este acum un singur eveniment, nu divizat n dou evenimente
ce/cum. Dezvoltarea Obiectivului Sprint-ului pornete evenimentul i apoi se compar
ce este necesar pentru a ndeplini Obiectivului Sprint-ului cu ce va veni i cu capacitatea
posibil, i n final se dezvolt un plan de ndeplinire a Obiectivului Sprint-ului n timpul
Sprint-ului.
4. Backlog-ul Produsului este rafinat, mai degrab dect ntreinut (groomed). Elementele
rafinate ale Backlog-ului Produsului sunt transparente, suficient de bine nelese i
destul de granulare pentru a fi introduse n Planificarea Sprint-ului i pentru a fi
selectate n Sprint. Elementele Backlog-ului Produsului avnd aceast transparen sunt
aa numite Pregtite (Ready).
5. Toate evenimentele sunt limitate n timp. Durata de timp descris este durata maxim
alocat. De cele mai multe ori Sprint-urile cu o durat mai mic de o lun nu ajung la
durata maxim.
6. Rezultatul Revizuirii Sprint-ului (Sprint Review) este un Backlog al Produsului potenial
reorganizat unde elementele cu cea mai mare valoare sunt cel mai probabil s fie
selectate la viitoarea Planificare a Sprint-ului.
7. Planificarea Sprint-ului definete funcionalitatea n incrementul planificat, i planific
cum Echipa de Dezvoltare va crea acest increment. Obiectivul Sprint-ului este conceput
pentru a ncheia rezultatul acestei munci.

2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.

Page | 18