Ghid Scrum | 22. Criterii de acceptare a poveștii utilizatorului

User Story este o tehnică care permite companiilor să livreze produse și servicii care satisfac nevoile clienților la maximum. Criteriile de acceptare User Story îmbunătățesc evaluarea noilor funcționalități ale Produsului din punctul de vedere al utilizatorului.

Criterii de acceptare a poveștii utilizatorului – cuprins:

1. Introducere
2. Cum se formulează criteriile de acceptare a poveștii utilizatorului?
3. Criterii de acceptare a poveștii utilizatorului vs. Definiția Terminat
4. rezumat

Introducere

Am acoperit povestea utilizatorului și problemele de abordat la crearea acesteia în articolele anterioare. Astăzi, însă, ne vom concentra pe criteriile de acceptare a User Story.

Criteriile de acceptare ar trebui să respecte aceste linii directoare:

• descrieți funcționalitatea nouă și îmbunătățită a Produsului din punctul de vedere al utilizatorului
• fi unic pentru fiecare User Story

Ghidul oficial Scrum nu definește User Story și criteriile de acceptare ale acesteia. Sunt elemente opționale, dar foarte comune ale lucrului Scrum. Totuși, pentru a ușura curiozitatea cititorilor noștri, îi vom prezenta astfel: Condițiile pe care trebuie să le îndeplinească o îmbunătățire a unui produs în timpul unui anumit Sprint pentru a obține aprobarea de la Utilizator.

Cum se formulează criteriile de acceptare a poveștii utilizatorului?

O poveste de utilizator bine scrisă conține o descriere clară a contextului sau situației pe care o privește, întrunind astfel criteriile de acceptare. Totuși, este doar o propoziție scurtă, prea vagă și ambiguă pentru a identifica clar considerațiile necesare.

Claritatea și accesibilitatea criteriilor de acceptare

Prin urmare, pentru a preveni ambiguitățile, conduceți și înregistrați o conversație detaliată cu clientul pentru a determina scopul soluției implementate. Rețineți că formularea finală a criteriilor de acceptare aparține Product Owner-ului.

Notează-le împreună cu criteriile User Story înainte de Sprint Planning. Fiecare membru al echipei Scrum trebuie să îl citească și să confirme că înțeleg și este de acord cu criteriile de acceptare a User Story. De obicei, criteriile de acceptare sunt pe cealaltă parte a cardului User Story.

Criteriile de acceptare formulate corect permit utilizatorului să verifice dacă testarea User Story urmează descrierea acesteia. Criteriile pot lua forma unei liste de verificare cu puncte de bifat atunci când sunt completate în timpul testării produsului la sfârșitul unui Sprint.

Problema este simplă dacă funcționarea Produsului este transparentă pentru Utilizator. Cu toate acestea, cu cât produsul este mai complex, cu atât devine mai dificil de testat. Luați software complexe sau servicii la scară largă. Prin urmare, în majoritatea cazurilor, un instrument util pentru validarea User Story este pregătirea unui test de acceptare.

Test de admitere

Dacă decideți să dezvoltați un test de acceptare, puneți-l pe cealaltă parte a cardului care conține Povestea utilizatorului. Ulterior, echipa Scrum sau o echipă externă QA o poate realiza.

Testul trebuie să conțină în primul rând o declarație clară cu privire la faptul dacă Produsul eșuează sau trece testul. Nu poate conține declarații procentuale sau evaluare intermediară.

Dacă User Story are mai mult de un criteriu de acceptare, fiecare necesită testare separată. În acest fel, este mult mai ușor să determinați ce funcționalitate de produs necesită îmbunătățire sau rafinare și este deosebit de important dacă noile funcționalități incluse în User Story se suprapun sau sunt independente unele de altele.

Criterii de acceptare a poveștii utilizatorului vs. Definiția Terminat

Definiția Terminat este o parte integrantă a lucrului în Scrum, care este echivalentul tehnic al criteriilor de acceptare. Cu toate acestea, nu ar trebui să le confundați pe acestea două, deoarece ele denotă angajamente diferite. Care este definiția lui Done și cum și când să o formulăm este o problemă pe care am abordat-o într-o postare separată?

Aici, vom menționa doar că Definiția de Efectuat este o descriere clară și transparentă a stării așteptate a Produsului după finalizarea Creșterii în Backlog-ul Produsului. Acesta descrie îmbunătățirile aduse în cadrul Creșterii. Acest lucru este în contrast cu criteriul de acceptare corespunzător Povestirii utilizatorului, care descrie funcționalitatea Produsului creată în timpul ultimului Sprint așa cum este percepută de către Client.

De exemplu, luați această poveste de utilizator cu conținutul:

În calitate de client conectat la un magazin online, vreau să cumpăr o baghetă magică cu un singur clic.

Definiția finalizării pentru povestea utilizatorului de mai sus poate include următoarele:

• crearea unui panou de autentificare pentru clienții magazinului
• integrarea sistemului de plată
• adăugarea butonului de plată instantanee la șablonul de pagină de produs

Pe de altă parte, criteriile de acceptare a clienților sunt următoarele:

• posibilitatea de a vă conecta la magazin
• posibilitatea definirii unei metode de plată implicite
• funcţionează butonul „Cumpără acum” pentru produsul „baghetă magică”.

rezumat

Criteriile de acceptare sunt un set de condiții care funcționează ca o modalitate de a evalua implementarea Poveștii utilizatorului. Prin descrierea performanțelor produse noi și îmbunătățite din punctul de vedere al utilizatorului, această metodă devine un instrument eficient de lucru cu Clientul. Prezintă performanța echipei Scrum din punctul de vedere al utilizatorului.

Criteriile de acceptare bine formulate, de exemplu sub forma unui test de acceptare, ne permit, de asemenea, să verificăm în timpul unui Sprint dacă funcționalitatea creată îmbunătățește satisfacerea cerințelor Clientului.

Criteriile de acceptare diferă de Definiția de făcut în primul rând în perspectiva pe care o adoptă în exprimare. Acestea nu conțin o descriere a cerințelor tehnice pe care ar trebui să le îndeplinească noua soluție, ci doar funcțiile pe care ar trebui să le prezinte produsul după actualizarea noii Povești utilizator.

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