Product Backlog-ul a fost format pe baza seciunilor ce urmau s intre n dezvoltare,

materializndu-se ntr-un document Excel. Story-urile trecute n document conineau doar titlul
seciunii, specificaiile trebuind s fie formulate nainte de prima edin de planificare sub
forma minimalista de wireframe.

Fig. 7 - Product Backlog

Product Backlog-ul este un document de nivel nalt pentru ntreg proiectul. El conine
specificaiile detaliate pentru toate funcionalitile cerute i lucruri care vor fi dezvoltate n
viitor, prioritizate n funcie de valoarea business pe care o dein. n principiu conine ceea ce
urmeaz a fi dezvoltat. Product Backlog-ul este proprietatea Product Owner-ului, acesta
determinnd valoarea business n timp de echipa determin necesarul de efort pentru fiecare
element din document.
Sprint Backlog-ul este considerat de echipa analizat unul din cele mai importante
elemente ale metodologiei Scrum. Analiznd acest document, ei i pot determina velocitatea
echipei, pot analiza situaiile n care viteza de dezvoltare a sczut i cauzele acestei scderi i

pot oferi o previziune privind modul n care se va ncheia Sprint-ul i elementele care nu vor
putea fi finalizate.
Analiznd performanta echipei n ambele cazuri, s-a czut de acord la stabilirea duratei
unui Sprint de dou sptmni.
Sprint-urile sunt formate din edina de planificare, dezvoltarea propriu-zis, edina de
Sprint Review i edina de retrospectiv. Iteraiile se deruleaz fr pauze ntre ele.

3.3 Sprint 1
Durata unui Sprint este fixat la dou sptmni. Deoarece Project Managerul nu a
dorit initial redactarea anterioara a specificatiilor tehnice, fiecare story ce intra in sprintul
respectiv era dezbatut amanuntit in sedinta de planificare. Detaliile erau notate proiectul creat
in sprintometru. Story-urile aveau intotdeauna specificata prioritatea.

3.3.1 Sedinta de planificare

Datorita dezbaterii asupra story-urilor, avand in vedere lipsa documentatiei tehnice si
doar prezentarea wireframe-urilor, sedinta de planificare a depasit 8 ore, fiind prelungita a doua
zi.
Dup ce toate story-urile din Product Backlog au fost detaliate, echipa ncearc s ofere
o estimare iniial a lor, Product Owner-ul fiind cel care a determinat ce elemente a dorit
finalizate n Sprint-ul urmtor. In mod normal, dac story-urile alese de Product Owner nu pot
fi dezvoltate i lansate n totalitate n urmtoarea iteraie, acesta trebuie s se hotrasc pe care
le vrea primele lansate, celelalte rmnnd n Product Backlog pentru Sprint-urile viitoare.
In prima sedinta membrii echipei s-au confruntat cu estimarile diferite pentru taskuri si
dezbaterea lor, dezbaterea neavand foarte multe argumente, deoarece nu existau specificatii
create pentru story-uri. Din aceasta cauza, sedinta de panificare s-a marit considerabil.
Toate story-urile care au fost incluse in primul sprint au fost trecute in sprintometru,
impreuna cu estimarea si developerul care si-a asumat taskul respectiv. Cu toate ca
metodologia spune ca taskurile nu se asigneaza la inceputul sprintului, echipa a vrut ca fiecare
developer sa stie ce are de facut in perioada sprintului.
2

Fig. 8 Sprint 1 Backlog

Sprint Backlog-ul este un document care conine informaii despre modul n care echipa
o s implementeze funcionalitile care trebuie realizate n sprintul urmtor. Elementele mari
sunt mprite n task-uri. Aceste task-uri primesc un numr de puncte care reflect timpul
necesar realizrii.
Prin intermediul acestui nivel de detaliere, toat echipa nelege ce are de fcut i
oricine pooate s aleag un task din lista pentru a-l realiza. Conform metodologiei, task-urile
din backlog nu sunt niciodat atribuite de altcineva, acestea fiind preluate de membrii echipei
pe msur ce trebuie ndeplinite, conform cu prioritatea acestora i cu nivelul de pregtire al
persoanei care realizeaz task-ul respectiv.

Sprint Backlog-ul este proprietatea echipei,

estimrile task-urilor realizndu-se tot de ctre echipa.

3

3.3.2 Desfasurare sprint

Pentru a putea actualiza zilnic Sprint Backlog-ul, Scrum Master-ul a scazut punctele
lucrate de fiecare membru al echipei din document. La sfritul zilei de lucru, nainte de
edina zilnic, fiecare membru al echipei compunea un e-mail n care specifica la ce task-uri a
lucrat n ziua respectiv i cte puncte trebuie sczute la task-urile respective. n modul acesta,
Scrum Master-ul actualiza Sprint Backlog-ul nainte de edin, echipa avnd n fata
documentul actualizat n momentul n care ncepea s discute.
Deoarece specificatiile nu au fost complete, de-a lungul sprintului au aparut foarte
multe intrebari si nelamuriri, ceea ce a dus la diverse intarzieri provocate de raspunsurile de la
Project Manager, prin intermediul Scrum masterului.

In cazul unui story (Dezvoltarea

sectiunii comentarii), specificatiile in timpul sprintului au fost schimbate in proportie de 70%.

A fost singurul caz in care i s-a permis Project Managerului schimbarea specificatiilor, avand
in vedere ca proiectul era la inceput si nu existau conexiuni intre componente.
Datorita acestor modificari si intarzieri, 4 taskuri de dezvoltare si 2 de testing nu au fost
finalizate, ele fiind incluse si in sprintul urmator.

Fig.9 Desfasurare Sprint 1

3.3.3 Sedinta de retrospectiva

La sfarsitul sprintului, scopul lui a fost atins in procent de 67%:

Fig.10 Sedinta Retrospectiva Sprint 1

La sedinta de retrospectiva, s-au analizat taskurile finalizate si au fost lansate in environmentul
de productie, s-au prezentat Product Ownerului si s-au discutat impresiile despre metodologie,
iar fiecare membru al echipei si-a exprimat parerea in legatura cu Scrum. Toti developerii au
sustinut necesitatea specificatiilor tehnice inainte de inceperea sprintului si interzicerea
schimbarii lor in perioada unui sprint.
Product Ownerul a fost de acord ca pentru al doilea sprint sa realizeze specificatiile in
avans si sa le furnizeze echipei de dezvoltare in ziua planificarii sprintului. De asemenea, a
fost de acord cu pastrarea specificatiilor neschimbate in perioada sprintului.
Membrii echipei au apreciat ca noul mod de lucru a consolidat comunicarea in echipa,
fiecare membru fiind nevoi sa participle la sedintele zilnice, la sedinta de planificare,
intelegand astfel toate taskurile in ansamblu si participand cu idei la realizarea lor.
6

De asemenea, membrii echipei au hotarat ca toate ideile despre imbunatatirea procedului sa

fie adaugate pe tabla din biroul echipei de dezvoltare si dezbatute in cadrul sedintei de
retrospectiva.

3.4 Sprintul 2
3.4.1 edina de planificare
edina de planificare in cadrul acestui sprint a respectat n mare trsturile existente n
metodologie. Perioada de timp n care s-a desfurat a fost ntre 4 i ase ore, n funcie de
complexitatea elementelor ce au fost preluate n Sprint i de gradul de noutate pe care acestea
le-au adus n proiect. Un alt factor care a influenat durata edinei de planificare a fost
dependenta ntre elementul din Product Backlog care a urmat a fi dezvoltat i celelalte
elemente din site.
Fiecare element din Product Backlog a fost analizat de echip, membrii punnd
ntrebri Product Owner-ului cu referire la funcionalitile pe care trebuie s le ndeplineasc
componenta respectiv. Story-urile din Product Backlog au o mic descriere si specificatii
tehnice dezvoltate anterior de Product Owner impreuna cu Scrum Master, necesare pentru a
putea mpri elementul respectiv n task-uri i pentru a putea evalua corect task-urile.
Echipa a incheiat prima parte a edinei cunoscnd n detaliu toate specificaiile
necesare dezvoltrii elementelor preluate n Sprint.
n a doua parte a edinei, Scrum Master-ul mpreun cu echipa a ntocmit Sprint
Backlog-ul. Fiecare story a fost mprit n task-uri, acestea fiind estimate de fiecare membru al
echipei. Dup ce toi membrii echipei au terminat estimrile, acetia au nceput s discute
fiecare task n parte, discutnd mai n detaliu acele task-uri la care estimrile membrilor au fost
diferite. n acest mod, echipa a reuit s creeze un mod propriu de estimare, ncercnd s
ajung la situaia ideal n care toi membrii ofer acelai numr de puncte unui task. De data
7

aceasta, nelamuririle au fost clarificate inca din sedinta d eplanificarea deoarece toate
specificatiile au fost realizate inainte.

3.4.2 Sprint Backlog-ul

Fig. 11 Sprint 2
Story-urile i task-urile sunt afiate sub forma unui tabel. Task-urile scrise cu culoarea
neagr sunt task-uri de programare, iar cele scrise cu albastru deschis sunt task-uri de design.
Se poate observa estimarea iniial i progresul zilnic al fiecrui task n parte.

3.4.3 Derularea Sprint-ului

De data aceasta, dezvoltarea propriu-zis a elementelor din Sprint s-a realizat n condiii
normale, fr intervenii din afar i fr schimbri majore n obiectivele ateptate. Cand
membrii echipei au ajuns ntr-un punct n care aveau nevoie de informatii din partea Product
Owner-ului, Scrum Master-ul a solicitat furnizarea acestor informaii prin intermediul unui email. De obiecei, aceast cerere de specificaii s-a facut nainte ca vreun membru al echipei s
rmn n imposibilitatea de a continua lucrul, fiecare dezvoltator analiznd task-urile pe care
8

le va aborda cu una sau mai multe zile nainte. Astfel, Product Owner-ul a dispus de timpul
necesar elaborrii raspunsurile la solicitari, fr a ncetini munca echipei.
De fiecare dat cnd un membru al echipei a observat ceva ce poate fi mbuntit n
proces sau ceva ce a funcionat bine n Sprint-ul curent, acesta a notat aceast observaie pe o
tabl n birou. Scopul tablei a fost de a pstra ideile membrilor i de a-i motiva pe acetia s
discute despre aspectele notate n timpul edinei de retrospectiva.
Echipa a respectat o parte mare din caracteristicile edinei zilnice definite de
metodologia Scrum, inclusiv regula de a sta in picioare in timpul edinei dailymeeting. Acest
lucru a determinat c edina s se menin n limita de timp definit, adic nu mai mult de un
sfert de or.
n plus, fiecare membru al echipei i-a ateapt rndul pentru a putea rspunde la cele
trei ntrebri. Doar dup ce un membru a terminat ce a avut de zis poate fi ntrerupt de
altcineva pentru a rspunde la o ntrebare. Comunicarea este astfel mai eficient, realizndu-se
ntr-un mod disciplinat, membrii echipei respectndu-se ntre ei.
Progresul poate fi urmrit uor cu ajutorul diagramei oferite de Sprintometer:

Fig. 12 Diagrama Sprint 2

9

Cu galben sunt evideniate punctele aprute n urma unor schimbri n Product

Backlog. Programul mai deine o funcie util care calculeaz deviaia n zile de la deadline-ul
Sprint-ului, adic intervalul de timp n care se poate ncheia Sprint-ul avnd toate story-urile
finalizate.
Diagrama Burn Down este un grafic public care arat ct mai este de realizat din Sprint
Backlog. Aceasta este o modalitate uoar de a urmri progresul sprintului, fiind actualizat
zilnic. Exist i alte tipuri de diagrame, ca de exemplu Release Burndown Chart care arat ct
mai este de lucru pn la finalizarea i lansarea unui produs sau a unei pri dintr-un produs.
Doar echipa i Scrum Master-ul sunt obligai s participe la edin, prezenta Product
Owner-ului fiind facultativ. n anumite cazuri, dac Product Owner-ul considera c neles
progresul nregistrat de echipa doar din citirea Sprint Backlog-ului, acesta poate decide c nu
mai este nevoie s participe la edina zilnic. Dei conform metodologiei, Product Owner-ul
nu are voie s vorbeasc n timpul edinei, uneori membrii echipei i adreseaz ntrebri
referitoare la specificaiile anumitor task-uri, uurnd astfel efortul depus pentru finalizarea
componentei.

3.4.5 edinele de review i de retrospectiv

Cele dou edine de review i de retrospectiva au loc n ziua urmtoare ncheierii
Sprint-ului, nainte de edina de planificare pentru urmtoarea iteraie.
Story-urile din Sprint Backlog sunt luate n ordinea n care sunt trecute n document, iar
n cazul n care numrul de puncte atins la final de dezvoltare este 0, acestea sunt demonstrate
n fata Product Owner-ului. Datorit programului n care este inut Sprint Backlog-ul, storyurile finalizate sunt mult mai uor de identificat.

10

Fig. 13 Statusul elementelor din Sprint Backlog Sprint 2

n cazul n care un story nu este finalizat n totalitate, acesta este preluat cu punctele
rmase n Sprint-ul urmtor.

Conform metodologiei Scrum, echipa trebuie s dezvolte o funcionalitate a produsului

n fiecare Sprint. Aceasta funcionalitate trebuie s fie livrabil, Product Owner-ul avnd
posibilitatea de a solicita lansarea ei imediat. Pentru a putea realiza acest lucru, acest element
trebuie s reprezinte o parte integrabil a produsului. Trebuie s fie done. Fiecare
funcionalitate lansat trebuie s fie compatibil toate elementele produsului i s fie testat n
detaliu, asigurnd astfel buna funcionare a software-ului.
Defintia de done trebuie perceput n acelai fel de toi membrii echipei. De cele mai
multe ori, un element din Product Backlog este done dup ce a fost dezvoltat, testat de
dezvoltatori, compilat i acceptat pentru lansare.

11

Dup ncheierea edinei de review urmeaz edina de retrospectiva. Dei nu este n

concordan cu metodologia Scrum, la aceast edin participa i Product Owner-ul. Membrii
echipei i exprima punctul de vedere cu privire la ce a mers bine i ce a mers prost n timpul
ultimului Sprint i ncearc s gseasc o soluie pentru a mbunti derularea Sprint-ului
urmtor.
Modificarea velocitii echipei de la Sprint la Sprint poate fi analizat folosind tab-ul de
Summary Report din Sprintometer.

Fig. 14 Summary Report Sprint 2

Tot prin intermediul acestui tab se poate observa i deviaia n zile de la deadline,
nsemnnd de cte zile ar mai fi fost nevoie pentru a finaliza toate elementele din Sprint
Backlog.
Dup ce au fost discutate toate aspectele legate de Sprint-ul ncheiat, edina de
retrospectiva ia sfrit i ncepe edina de planificare pentru noul Sprint.

12