Ghid Scrum | 40. Creșterea registrului de produse

Creșterea Product Backlog este una dintre sarcinile principale ale unui Product Owner. Procesul de hrănire include formularea, detalierea și adăugarea de noi povești de utilizator la Product Backlog. Cu toate acestea, cea mai importantă dintre sarcinile de nutrire este asigurarea faptului că intrările plasate în Backlog sunt în ordinea corectă, adică devin prioritizate.

Creșterea registrului de produse – cuprins:

1. Introducere
2. Scopul creșterii Product Backlog-ului
3. Erori în întreținerea Product Backlog
4. Întreținerea backlog vs. metrics utilizate în Scrum
5. rezumat

Introducere

Product Backlog este unul dintre artefactele Scrum. Conține o listă prioritizată a lucrărilor necesare pentru a crea un Produs. Cu alte cuvinte, este o listă de povești de utilizator necesare pentru atingerea obiectivului de produs. Puteți găsi o descriere detaliată a poveștilor utilizatorilor în acest articol. Și iată detalii despre caracteristicile și modul de întreținere a Product Backlog-ului.

Creșterea backlog-ului de produse poartă, de asemenea, următoarele denumiri:

• Prioritizarea backlog,
• Rafinarea backlog,
• Scalarea backlog.

Scopul creșterii Product Backlog-ului

Product Ownerul gestionează Product Backlog. Abilitățile cheie includ prioritizarea sarcinilor pe măsură ce se apropie data scadenței. Acest lucru se datorează faptului că scopul cultivării Product Backlog-ului este de a se asigura că funcționalitățile Produsului vin cu cea mai mare valoare de afaceri, adică cele mai esențiale din punctul de vedere al Clientului, sunt în fruntea listei de activități. Iar descrierea lor este clară și detaliată, astfel încât implementarea lor să poată începe chiar în următorul Sprint.

Product Backlog poate fi actualizat zilnic dacă este necesar. Proprietarul de produs poate adăuga noi Povești de utilizator în Product Backlog după ce a discutat cu Stakeholderii și Echipa de Dezvoltare sau prin tragerea de concluzii și reformularea User Stories deja scrise în Product Backlog.

Actualizarea obligatorie a Backlog-ului este una dintre sarcinile efectuate în timpul Sprint Review. Am descris acest proces în detaliu în acest articol. De obicei, în timpul acestei întâlniri, Echipa Scrum discută nu numai sarcinile de finalizat în următorul Sprint. De asemenea, specifică preliminar Poveștile utilizatorilor și implementarea lor în următoarele două sau trei Sprinturi. Acest mod de a face lucrurile permite echipei Scrum și activităților sale să aibă o viziune mai largă asupra direcției pe termen lung. Permite să ne gândim la sarcinile care sunt îndeplinite în prezent din perspectiva dezvoltării lor în Sprinturile ulterioare.

Erori în întreținerea Product Backlog

Una dintre cele mai frecvente probleme cu privire la cultivarea Product Backlog este să îi permită să se extindă necontrolat. Acest lucru se datorează faptului că în timpul lucrului la Produs apar în mod spontan diverse funcționalități și sarcini suplimentare propuse atât de părțile interesate, cât și de membrii echipei Scrum. Prin urmare, limitarea creșterii sferei Product Backlog (scope creep) este una dintre cele mai importante sarcini efectuate de Product Owner. Cele mai frecvente greșeli pe care le fac proprietarii de produse se referă:

1. Abaterea de la obiectivul de produs – adăugarea de prea multe idei la Product Backlog dincolo de obiectivul de produs de bază nu este o practică bună, deoarece îi reduce foarte mult lizibilitatea. Funcționează mai bine să colectezi idei pentru funcționalități suplimentare într-un document separat.
2. Duplicarea conținutului – introducerea ideilor repetate sau foarte similare de la diferiți stakeholderi în Backlog – înainte de a adăuga o altă intrare la Backlog, Product Owner trebuie să se asigure că noua intrare nu le dublează pe niciuna dintre cele existente.
3. Lipsa unei perspective mai largi – ar trebui să comandați intrările Product Backlog în funcție de valoarea lor în ceea ce privește obiectivul de produs. Totuși, rețineți că prioritizarea ar trebui să ia în considerare următoarele câteva Sprinturi, astfel încât sarcinile efectuate într-un anumit Sprint să fie perfect legate atât de Sprintul precedent, cât și de Sprintul imediat următor.

Nu poți evita astfel de greșeli. Cu toate acestea, conștientizarea apariției acestora îl poate face pe proprietarul produsului să fie mai precaut în ceea ce privește adăugarea de noi Povestiri de utilizator la Product Backlog pentru a găsi echilibrul potrivit. Acest lucru se datorează faptului că este, de asemenea, o greșeală să reduceți prea mult Backlog-ului și să eliminați intrările care conțin sarcini similare care diferă. De exemplu, descriind funcționalități similare ale produsului care diferă semnificativ în aplicație.

Întreținerea backlog vs. metrics utilizate în Scrum

Product Backlog conține o descriere a lucrărilor rămase de-a lungul proiectului. Cu toate acestea, doar un Backlog actualizat și alimentat în mod regulat poate estima cu exactitate raportul dintre cantitatea de muncă finalizată și totalul. Pentru a descrie cantitatea de muncă finalizată, ar trebui să aplicați graficul Burndown, despre care am scris în acest articol.

O altă măsură populară pentru a descrie munca în echipă Scrum este viteza. Puteți măsura prin compararea numărului de intrări Product Backlog convertite în Increment în timpul unui singur Sprint. Am descris Velocity mai detaliat în acest articol.

rezumat

Product Owner realizează Product Backlog Nurturing. Când Product Backlog-ul este bine întreținut, echipa Scrum are o vedere clară asupra muncii care mai rămâne. De asemenea, poate obține o perspectivă mai amplă și prospectivă a modului în care arată calea către obiectivul de produs. Acesta este motivul pentru care proprietarul produsului trebuie să se asigure că Poveștile utilizatorilor incluse în Product Backlog sunt în ordinea priorității pentru finalizare. Și, de asemenea, că sarcinile de finalizat în viitoarele Sprinturi sunt descrise în cele mai fine detalii.

Dacă vă place conținutul nostru, alăturați-vă comunității noastre de albine ocupate pe Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Caroline Becker

În calitate de manager de proiect, Caroline este expertă în găsirea de noi metode de a proiecta cele mai bune fluxuri de lucru și de a optimiza procesele. Abilitățile ei de organizare și capacitatea de a lucra sub presiunea timpului o fac cea mai bună persoană pentru a transforma proiectele complicate în realitate.

Vizualizați toate postările

Ghid Scrum:

1. Glosar de termeni de bază, roluri și noțiuni
2. Ce este Scrum?
3. Valorile Scrum
4. Cum implementezi Scrum în compania ta?
5. Echipa Scrum - ce este și cum funcționează?
6. Cine este un proprietar de produs?
7. Cele mai frecvente greșeli ale Product Ownerului
8. Cine este Scrum Master?
9. Caracteristicile unui bun Scrum Master
10. Cele mai frecvente greșeli ale Scrum Master
11. Ce statistici și valori ar trebui să urmărească Scrum Master?
12. Cooperare între Product Owner și Scrum Master
13. Echipa de dezvoltare în Scrum
14. Cele mai frecvente greșeli ale dezvoltatorilor
15. Artefacte Scrum
16. Scaling Scrum
17. Sprint Backlog
18. Ce este Product Backlog?
19. Ce sunt User Stories?
20. Crearea celei mai bune povești de utilizator cu INVEST
21. Cele mai frecvente greșeli ale User Story
22. Criterii de acceptare a poveștii utilizatorului
23. Estimare și Story Points în Scrum
24. Planificarea Pokerului
25. Joc de estimare a echipei
26. Definirea creșterii
27. Evenimente Scrum
28. Ce este Sprint în Scrum?
29. Angajamentele echipei Scrum - Obiectiv de produs, obiectiv de sprint și definiția finalizării
30. Ce este un grafic Burndown?
31. Cum se creează și se interpretează un grafic de ardere?
32. Avantajele și dezavantajele diagramei de ardere
33. Panouri Kanban în Scrum și Scrumban
34. Viteza în Scrum - Viteza echipei de dezvoltare
35. Scrum zilnic
36. Planificarea sprintului
37. Sprint Review
38. Ce este o retrospectivă Sprint?
39. Greșeli frecvente în timpul unei retrospective de sprint
40. Creșterea backlog-ului de produse