Ghid Scrum | 21. Greșeli în povestea utilizatorului

Poveștile utilizatorilor descriu cum funcționează o nouă funcționalitate de produs în limbajul de zi cu zi sau de afaceri. Cu toate acestea, pregătirea lor necesită mult timp, efort și gândire. În articolul de astăzi, subliniem cele mai frecvente greșeli din User Story și sugerăm cum să le rezolvăm.

Cele mai frecvente greșeli din User Story - cuprins:

1. Introducere
2. Probleme cu 3W
3. Probleme cu 3C
4. Greșeli din povestea utilizatorului – Rezumat

Introducere

Povestea utilizatorului poate fi un instrument excelent pentru a motiva echipa să propună noi soluții la problemele prezentate din perspectiva utilizatorului. Am scris despre ce este User Story într-o intrare separată. Și în acest articol, am introdus INVEST, care este o metodă populară de a scrie povești bune de utilizator. Astăzi ne vom concentra pe greșelile din User Story.

Probleme cu 3W

O poveste corectă a utilizatorului răspunde la întrebările:

• OMS? (Cine este utilizatorul țintă al produsului?)
• Ce? (Ce capabilități are Produsul și ce poate face?)
• De ce? (Ce scop servește?)

Cu toate acestea, problemele pot însoți răspunsurile la fiecare dintre aceste întrebări. Cea mai puțin frecventă problemă este îndoiala cu privire la ceea ce ar trebui să se schimbe în produs ca răspuns la nevoile clientului. Prin urmare, ne vom concentra asupra problemelor legate de Cine? și de ce?

Cine – persoana de utilizator

Una dintre cele mai frecvente greșeli făcute la crearea User Stories este să nu răspunzi suficient de precis la întrebarea: pentru cine? Cu alte cuvinte, cine este utilizatorul căruia îi este destinată schimbarea planificată?

Adesea, un răspuns generic care indică Clientul sau Utilizatorul final ca destinatar al modificării nu este suficient. Soluția la această problemă este să ne imaginăm destinatarul ca pe o anumită persoană. O persoană este o imagine model a clientului țintă. Cu alte cuvinte, o persoană este o reprezentare a persoanei care va folosi Produsul într-un mod specific.

După ce ți-ai analizat Povestea utilizatorului, s-ar putea să descoperi că spune poveștile diferitelor persoane în același timp. Dacă există mulți utilizatori țintă, merită să luați în considerare împărțirea poveștii utilizatorului în fragmente mai mici pentru a evita acțiunile contradictorii, care se exclud reciproc sau pur și simplu ineficiente.

De ce? – un scop prost definit

Uneori, ultima secțiune a User Story devine sursa problemelor. Ar trebui să specifice valoarea comercială a modificărilor efectuate în timpul execuției User Story. Aruncă o privire la un exemplu de greșeli în povestea utilizatorului în care descrierea funcționalității suplimentare înlocuiește obiectivul:

Ca client, vreau să cumpăr o baghetă magică cu un singur clic pentru că vreau să cumpăr un covor zburător săptămâna viitoare.

În loc să ofere motivul cumpărării baghetei magice, această poveste de utilizator adaugă un alt articol pe lista de cumpărături a potențialului client. Prin urmare, atunci când pregătiți o poveste de utilizator, nu uitați de motivele modificărilor în funcționalitatea Produsului.

Probleme cu 3C

Putem descompune procesul de lucru cu User Stories în trei etape numite 3C:

• Card – Cardul pe care este salvată Povestea utilizatorului
• Conversație – O conversație în cadrul echipei Scrum despre cardul User Story
• Confirmare – definirea criteriilor de acceptare care confirmă că o sarcină a fost finalizată

Pot apărea erori pe oricare dintre acestea, pe care le descriem mai jos.

Card

Cardul de memorie care stochează Povestea utilizatorului are o capacitate limitată. Prin urmare, cele mai frecvente probleme se referă la lungimea și volumul User Story. Povestea utilizatorului are nevoie de coerență și fără bătăi în jurul tufișului, așa cum se spune, într-un grad atât de precis încât fiecare cuvânt contează.

Acest lucru se datorează faptului că problema cardului User Story are două dimensiuni. Unul este modul în care este formulat: concis și care conține o cantitate minimă necesară de enumerare. A doua este dimensiunea reală a poveștii utilizatorului. O propoziție generală poate exprima un număr mare de sarcini care nu pot fi finalizate în timpul unui singur Sprint.

Conversaţie

Formularea cu o singură propoziție a poveștii utilizatorului este punctul de plecare pentru o conversație cu echipa de dezvoltare. Prin urmare, este incorect să o tratezi ca pe o descriere a sarcinii de efectuat. Dezactivează posibilitatea negocierilor și discuțiilor asupra diferitelor modalități de implementare a acesteia. User Story nu trebuie tratată ca o descriere a cerințelor pentru funcționalitatea noului produs, este mai degrabă o invitație de a începe o conversație despre soluții tehnice specifice care vor duce la realizarea valorii de afaceri definite de User Story.

Confirmare

Am scris despre criteriile de acceptare care trebuie definite pentru fiecare User Story în detaliu în textul care descrie ce este o User Story. Una dintre greșelile frecvente este însă lipsa de vagitate a criteriilor de performanță.

O poveste de utilizator bine scrisă conține o descriere a situației în care este implementată. Testul său este că Utilizatorul profită de noua funcționalitate creată de Echipa de Dezvoltare.

Un instrument util pentru validarea User Story este dezvoltarea unui test de acceptare. Acesta este de obicei pe cealaltă parte a cardului care conține Povestea utilizatorului.

Greșeli din povestea utilizatorului – Rezumat

Când pregătiți și aplicați User Stories, merită să respectați următoarele reguli:

• Identificați cu precizie Utilizatorul afectat de modificare
• Definiți clar scopul construirii de noi funcționalități de produs
• Păstrați-i volumul cât mai scurt posibil
• Tratați povestea utilizatorului ca pe un punct de plecare pentru discuțiile despre soluții cu echipa de dezvoltare
• Stabiliți reguli clare de acceptare

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

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