Ghid Scrum | 19. Poveștile utilizatorilor – ce sunt acestea?

Povestea utilizatorului este o scurtă descriere a unei noi funcționalități de produs sau a îmbunătățirii acesteia. Nu conține o soluție tehnică, dar abordează întrebări referitoare la funcționalitate: Cine este utilizatorul? Ce face Produsul? Și care este scopul ei? Povestea utilizatorului descrie produsul în limbajul de zi cu zi sau de afaceri, deși indică și sarcinile echipei Scrum care sunt menite să îmbunătățească performanța echipei.

Ce sunt User Stories? - Cuprins:

1. Introducere
2. Povestea utilizatorului. A cui poveste este?
3. Cum se utilizează User Stories?
4. Criteriul de acceptare
5. rezumat

Introducere

Povestea utilizatorului este cel mai comun mod de a formula sarcinile efectuate de Echipa Scrum. O singură poveste de utilizator definește o mică funcționalitate a produsului. Descrie cel mai mic obiectiv semnificativ, parțial al produsului. Din acest motiv, User Stories sunt foarte scurte.

Poveștile utilizatorilor sunt create pe parcursul întregului timp de lucru la Produs. Ele sunt create continuu, din momentul in care se ia decizia de a incepe lucrul, pana la realizarea Scopului Produsului.

Crearea poveștilor utilizatorilor este sarcina unui proprietar de produs. Pe baza unei conversații cu un Client, formulează răspunsuri la întrebări care permit crearea User Story și le introduce în Product Backlog. Cu toate acestea, User Stories reflectă nu numai nevoile clienților.

Povestea utilizatorului. A cui poveste este?

Echipa Scrum creează o poveste de utilizator pentru a defini nevoile utilizatorului și de aceea este scrisă în limbajul de afaceri. Cu alte cuvinte, indică beneficiile pe care implementarea sa le va aduce utilizatorului produsului. Cu toate acestea, în Product Backlog, pot exista și povești de utilizator care descriu nevoile echipei de dezvoltare, de exemplu îmbunătățirea fluxului de lucru între Dezvoltatori sau descriind nevoile Product Owner-ului, de exemplu organizarea Product Backlog-ului. În astfel de cazuri, utilizatorul din povestea utilizatorului este Dezvoltatorul și Proprietarul produsului.

Puteți descrie o poveste de utilizator răspunzând la întrebările 3W :

• OMS?
• Ce face?
• De ce?

Povestea utilizatorului este apoi conținută într-o formulă:

Ca [tip de utilizator], vreau [să fac ce?] Pentru că [de ce? De ce?].

Exemple de povești ale utilizatorilor despre funcționalitatea unui magazin online scrise în acest formular sunt ilustrate în tabelul de mai jos:

Această formulă permite nu numai să se formuleze o poveste de utilizator, ci și să traducă relativ ușor limbajul tehnic în afaceri și invers . Ca rezultat, atât Dezvoltatorii, cât și Părțile interesate văd clar Scopul și etapele progresului acestuia. Vom acoperi, de asemenea, crearea unor povești de utilizator bune folosind metoda INVEST într-un articol separat din seria Scrum Guide.

Cum se utilizează User Stories?

Crearea unei povești schematice de utilizator este doar începutul. Sunt semnale și puncte de plecare pentru discuții despre probleme și soluțiile acestora. Discutarea poveștilor utilizatorilor are loc în timpul Sprint Planning pentru a rezolva problemele tehnice pe care echipa de dezvoltare le va adăuga la Sprint Backlog.

De obicei, în spațiul fizic, poveștile utilizatorilor sunt scrise pe cartonașe mici, colorate fixate la locul de muncă. Cu toate acestea, în spațiul digital, tablele digitale, partajate de echipa Scrum, funcționează cel mai bine.

Salvarea poveștilor utilizatorului în acest mod are mai multe avantaje deoarece:

• Subliniază autonomia fiecărui User Story – fiecare are un cadru separat și poate fi executat independent de ceilalți
• Subliniază dinamica User Stories – ordinea realizării lor este renegociată de către Echipa Scrum iar ordinea actuală de realizare este vizibilă pe tablă datorită aranjamentului fizic al cardurilor cu User Stories
• Servește ca memento – datorită reprezentării vizuale a poveștilor utilizatorului, echipa Scrum are la vedere un indicator pentru a le reaminti obiectivul atunci când creează soluții detaliate.

Echipa de dezvoltare estimează efortul necesar pentru a finaliza o poveste de utilizator cu zile, ore de lucru sau puncte de poveste.

Criteriul de acceptare

O poveste de utilizator trebuie să aibă anumite criterii de acceptare chiar în momentul în care este acceptată pentru dezvoltare de către Echipa de dezvoltare. Criteriile de acceptare determină în ce moment poate fi considerată finalizată lucrul pe o poveste de utilizator.

În acest fel, atât clientul, cât și dezvoltatorii știu cum munca lor se va traduce în valoare de afaceri. De obicei, o poveste de utilizator este considerată finalizată atunci când utilizatorul specificat în ea poate efectua acțiunea descrisă. Folosind exemplul de mai sus, aruncați o privire la această poveste de utilizator cu conținutul:

Un client poate cumpăra o baghetă magică cu un singur clic.

Este finalizat atunci când pe pagina magazinului online apare un buton funcțional „Cumpără acum” , care utilizează informațiile implicite de plată și livrare pentru utilizatorul conectat.

rezumat

O poveste de utilizator este o descriere concisă a unei noi funcționalități sau îmbunătățiri de produs. Acesta servește drept cel mai mic obiectiv exprimat în limbajul de afaceri, adică din perspectiva valorii afacerii și a utilizatorului. Ajută la definirea clară a sarcinii care trebuie îndeplinită, precum și a criteriilor pentru îndeplinirea acesteia.

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