Da li u toku razvoja mogu da se menjaju stavke Product Backloga koje su izabrane za Sprint Backlog?

Dobio sam danas email sa pitanjima o Scrum-u od jednog kolege koji se sprema za polaganje ispita za Scrum Mastera na scrum.org. Email mi je bio izuzetno zanimljiv pa ga navodim u celosti kao i moje odgovore.

Email koji sam dobio:

“Pročitao sam The Scrum Guide i The Scrum Master Training Manual, pa imam par pitanja:

Što znači rečenica “Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.” – znači da se Sprint backlog može mijenjati tijekom sprinta – čini mi se da smo o otme pričali i da sam se tome čudio, ali ajde da svejedno pitam. A opet tu je ispred te rečenica “No changes are made that would endanger the Sprint Goal”, koja nije tako striktna ne kaže da se ne može mijenjati, samo kaže da se ne smije ugroziti cilj sprinta, a i dalje ide u smjeru mijenjanja sprint backloga “”If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.” Nije li to u suprotnosti sa prilično striktnom rečenicom “An important point is that we do not change the items of the Sprint Backlog after the Sprint is started and the plans are set.”, doduše u drugoj knjizi, ali za isti certifikat (prve rečenice su iz The Scrum Guide sa scrum.org, a zadnja rečenica je iz The Scrum Master Training Manual)?

Pišem ovaj mail kako čitam The Scrum Guide (satima, da ne kažem danima :-), pa sad još nađem “As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed.” Da li se to misli na nove taskove iz product backloga ili na nove taskove koji bolje opisuju story koji se radi u sprintu – to bi mi bilo logično.”

Moj email sa odgovorima:

Jedan od problema Scrum-a (ako ne i najveći) je nekonzistentnost ne samo različitih autora već i istih autora ne samo u različitim knjigama, blog postovima itd. već vrlo često i u okviru iste knjige ili posta.

Što se tiče dela Sprinta koji se najčešće naziva “Razvoj”, ono što ga karakeriše, kad su stavke Sprint Backlog-a u pitanju, je sledeće:

– Na Sprint Planning-u se definiše Cilj Sprinta i biraju se stavke Product Backlog-a koje će biti realizovane u fazi Razvoj-a a da bi se ispunio Cilj Sprint-a,

– Od izabranih stavki Product Backlog-a Development Tim radi dekompoziciju na Sprint Backlog stavke samo toliko da je dovoljno samo prvi dan ili za prvih par dana Razvoja,

– Sprint Backlog je živ dokument koji Development Team stalno dorađuje u toku Razvoja,

– U slučaju nejasnoća oko stavki Product Backlog-a, koje su izabrane za konkretan Sprint da bi se isunio definisani Cilj Sprint-a, Product Owner objašnjava Development Timu te nejasnoće i time pomaže Development Timu da što bolje definiše stavke Sprint Backlog-a ali samo ako je Development Tim to tražio od njega.

Ono što proizilazi iz ovoga je:

– Stavke Product Backlog-a, koje se biraju za Sprint Back-log, se biraju samo tokom Sprint Planning-a koji traje najviše 8 sati,

– Za vreme trajanja Razvoja se stalno doradjuje Sprint Backlog ali samo na osnovu već izabranih stavki iz Product Backlog-a,

– Product Owner, ako proceni da su izabrane stavke Product Backlog-a, za konkretan Sprint, postale nepotrebne i ne treba da se dalje radi na njima u fazi Razvoja, može SAMO da prekine Sprint.

Ovo što sam prethodno naveo je u skladu sa Scrum-om koji je definisan Scrum Guide-om (jul 2013) na scrum.org.

Menjanje stavki Product Backlog-a, koje su izabrane za konkretan Sprint, je nemoguće u fazi Razvoja jer vraća ceo tim na Sprint Planing što nije u skladu sa Scrum-om.

Takođe ne treba zaboraviti da:

– Stavke Product Backlog-a su kratke definicije većih funkcionalnosti i nemoguće je za takve izmene izdvojiti malo vremena,

– Bilo kakve Sprint Planning aktivnosti u sred faze Razvoja, remete ritam i fokus Development Tima što dovodi do smanjenja produktivnosti Development Tima.

Čuo sam na konferencijama razne prakse ljudi koji se bave Scrum-om i nekima od njih je najnormalnije da u sred Razvoja rade Sprint Planning ali to po meni definitivno nije Scrum.

Leave a Reply

%d bloggers like this: