'Y'

Zero refinement in Scrum

Prietenul meu, Steve Porter, a scris de curand pe Twitter despre perfectionarea Product Backlog: Refinement isnt an event in Scrum. Its not mandatory and there are no hard and fast rules for when and how much. Zero refinement is acceptable, as is spending a majority of your Sprint on it. Figure out what works for you.

Mar 28, 2019 620
Prietenul meu, Steve Porter, a scris de curand pe Twitter despre perfectionarea Product Backlog: Refinement isnt an event in Scrum. Its not mandatory and there are no hard and fast rules for when and how much. Zero refinement is acceptable, as is spending a majority of your Sprint on it. Figure out what works for you. Prima mea reactie a fost una de indoiala, dar Steve este unul dintre putinii care intelege cu adevarat ce este Scrum (este trainer Scrum si e membru al echipei Scrum.org ). Asa ca am decis sa ma gandesc profund la asta si sa incerc sa imi dau seama ce cred despre acest lucru.

Trebuie sa definim cu claritate despre ce vorbim, asadar as vrea sa incep de la un citat din Ghidul Scrum, care defineste ce este filtrarea Product Backlog:

In cadrul Product Backlog refinement adaugam detalii, estimari si facem ordine in item-urile din Product Backlog. Acesta este un proces continuu in care Product Owner-ul si Echipa de Dezvoltare colaboreaza la detaliile elementelor din Product Backlog. In timpul Product Backlog refinement itemii sunt revizuiti si corectati. Scrum Team decide cum si cand se face refinement. Refinement-ul consuma, de obicei, nu mai mult de 10% din capacitatea Echipei de Dezvoltare. Cu toate acestea, elementele din Product Backlog pot fi actualizate oricand de Product Owner sau la discretia Product Owner.

Zero refinement in Scrum 960.png


Apoi am vrut sa-mi dau seama de lucrurile cu care suntem de acord. Ghidul Scrum nu defineste Product Backlog refinement ca un eveniment. Mai degraba este un proces continuu. Deci, suntem de acord cu asta. Acelasi lucru cu acceptabilitatea de spending a majority of your Sprint on it; refinement care usually consumes no more than 10% of the capacity of the Development Team, ceea ce nu inseamna ca ar trebui sa consume exact sau nu mai mult de 10%. Deci mi se pare ca suntem de acord ca there are no hard and fast rules for when and how much.

Dar cand vine vorba de zero refinement is acceptable, am o opinie diferita. Da, Scrum este un cadru care se foloseste in medii complexe, iar complexitatea implica faptul ca totul este extrem de dependent de context si nimic nu este one-size-fits-all. Trebuie sa abordam lucrurile cu curiozitate si cu mintea deschisa si sa incercam sa ajutam echipa sa-si dea seama ce functioneaza cel mai bine in situatia lor particulara (si sa nu uitam sa revedem deciziile, deoarece lucrurile se schimba si solutiile ar trebui sa se adapteze). Si da, Ghidul Scrum nu solicita in mod explicit ca o echipa Scrum sa faca filtrarea Product Backlog. Ceea ce ma face sa nu fiu de acord este insasi definitia refinement ca fiind the act of adding detail, estimates, and order to items in the Product Backlog.

Daca definim refinement asa, atunci "zero refinement" va insemna ca Product Backlog este setat o data pentru totdeauna. Nu adaugam niciun detaliu, nici estimari si nici nu schimbam ordinea sa. Si acest lucru contrazice insasi ideea unui Product Backlog ca o entitate dinamica care evolueaza pe masura ce produsul si mediul in care o sa fie folosit evolueaza. Mai mult decat atat, ideea ca un Product Backlog poate fi stabilit odata pentru totdeauna incalcand definitia de Product Backlog. Sa citam din nou din Ghidul Scrum:

The Product Backlog is an ordered list of everything that is known to be needed in the product.
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

Cerintele nu se opresc niciodata din a se schimba, asa ca Product Backlog este un artefact viu. Schimbarile privind cerintele clientului, conditiile de piata sau tehnologia pot provoca modificari in Product Backlog.

Deci, daca un Product Backlog nu se schimba, atunci acesta nu este un Product Backlog Scrum si de aceea nu avem de-a face cu Scrum, deoarece Scrums roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

Imi pot imagina companii unde unde un asemenea backlog este posibil, si probabil ca este ceva intr-un domeniu simplu, iar in acest domeniu probabil ca nu este nevoie de Scrum (pentru ca nu este nevoie de inspectie si adaptare). Sau este posibil ca o echipa sa ignore modificarile sau sa nu primeasca feedback care sa ii permita sa vada acele modificari. Reformuland o gluma veche.If you dont see any changes, you are right: you dont see the changes.

Dupa cum a subliniat Steve in ultima noastra discutie, exista (cel putin) doua optiuni de luat in considerare:

  1. Unii oameni sugereaza ca refinement tine in mod special de Product Owner si Echipa de Dezvoltare lucrand impreuna la Product Backlog. Daca un Product Owner actualizeaza elementele din Product Backlog de unul singur, nu este vorba despre refinement.
  2. Pot exista cazuri in care un Product Backlog este foarte mic si foarte slab definit. Este doar o lista de obiective sau experimente. In acest caz, singura actiune necesara la Product Backlog este adaugarea de elemente noi sau renuntarea la elemente care nu sunt necesare.

In ceea ce priveste optiunea A, Steve nu este sigur daca este de acord cu acest punct de vedere a refinement, dar, dupa cum el spune, just because I dont agree with it doesnt make it wrong. As fi de acord cu el, tinand seama de definitia refinement din Ghidul Scrum: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. De asemenea, as spune ca aceasta notiune de filtrare, atunci cand este amestecata cu ideea "zero refinement", poate aduce multa complexitate.

Daca un Product Owner actualizeaza propriul Product Backlog, iar Product Ownerul si Echipa de Dezvoltare nu lucreaza impreuna la Product Backlog, acest lucru ar putea insemna ca singurul mod in care Product Ownerul si Echipa de Dezvoltare comunica despre elementele die Backlog este prin intermediul insusi Product Backlog-ului. Acest lucru ar putea duce la tot felul de neintelegeri. Imi imaginez cum ar putea functiona bine, dar o astfel de modalitate de comunicare conduce la atatea probleme incat unul dintre Principiile din Agile Manifesto vorbeste despre asta (Cea mai eficienta si mai de succes metoda de transmitere a informatiilor catre si in cadrul unei echipe de dezvoltare este conversatia fata-n fata).

Optiunea B ar putea functiona, dar poate aduce si o multime de probleme legate de produs (comunicarea necorespunzatoare din cauza elementelor Product Backlog vagi este doar una dintre ele, o alta posibilitate este o problema cu potrivirea elementelor din Product Backlog intr-un Sprint pentru a obtine un Increment cu potential de lansare la sfarsitul fiecarui Sprint).

Pentru a rezuma toate cele de mai sus, in trei idei principale:

  • in cazul in care echipa dvs. are zero refinement, as sugera sa revizuiti definitia echipei dvs. privind refinement si mecanismele de feedback ale echipei (inclusiv comunicarile din cadrul Echipei Scrum) exista o probabilitatea rezonabila ca una dintre acestea sa nu functioneze asa cum ar trebui
  • daca mecanismele de feedback ale unei echipe sunt functionale si echipa are un refinement "ScrumGuide-ish" zero (adica nu adauga detalii, estimari si ordine pentru elementele din Product Backlog) si functioneaza bine pentru echipa respectiva toate bune pentru ei! Dupa cum spune Steve, its possible and I dont want people not trying it because of something they read in the Scrum Guide.
  • inainte de a schimba Scrum asigurati-va ca nu faceti schimbarea pentru a ascunde problemele, ci pentru a le rezolva.

Daca iti place acest articol, distribuie-l si prietenilor tai!




Mai ai intrebari?
Contacteaza-ne.
Thank you.
Your request has been received.