Cum prioritizezi un backlog cu RICE sau WSJF?
RICE = Reach × Impact × Confidence ÷ Effort, util pentru produse de masă. WSJF (Weighted Shortest Job First) = Cost of Delay ÷ Job Size, util pentru roadmap-uri în care timpul contează cât valoarea — folosești unul, altul sau ambele, în funcție de tipul de decizii.
Backlog-ul prioritizat "din intuiția PM-ului" e cum decizia se ia politic, nu economic. Cele două framework-uri populare — RICE și WSJF — forțează echipa să scrie pe hârtie ipotezele despre cât de mare e impactul, cât costă effort-ul și care e penalty-ul întârzierii. Numerele nu sunt sfinte, dar conversația pe care o produc e mult mai utilă decât "eu cred că asta e mai important".
1. RICE: pentru produse cu utilizatori măsurabili
RICE = (Reach × Impact × Confidence) ÷ Effort. Reach = câți utilizatori atinge feature-ul într-o perioadă (luna viitoare, trimestrul viitor). Impact = cât schimbă comportamentul per user (scară 0.25/0.5/1/2/3). Confidence = încrederea ta în estimări (50% / 80% / 100%). Effort = person-months.
Output-ul e un scor RICE per item — sortezi descrescător și obții ordinea. Utilitatea reală nu e în scor, ci în discuția pe care o forțează: "OK, dacă pretinzi că Reach e 50.000 users, cum justifici? Sursa? Daca Impact e 3 (massive), care e ipoteza despre comportament?" Forțezi rigoare, nu produci certitudine.
2. WSJF: pentru roadmap-uri unde timpul costă
WSJF (Weighted Shortest Job First) vine din SAFe și calculează: (Business Value + Time Criticality + Risk Reduction) ÷ Job Size. Diferența cheie față de RICE: include explicit "Time Criticality" — cât pierdem dacă livrăm cu o lună mai târziu.
Util când ai dependențe externe (lansare paralelă cu un client mare, deadline regulator, sezon de Black Friday). Un feature cu valoare medie dar time-critical urcă în top peste un feature cu valoare mare dar fără presiune de timp. Asta reflectă economia reală a deciziei.
3. Estimările în Fibonacci, nu în zile
Atât RICE (Effort) cât și WSJF (Job Size) cer dimensionarea muncii. Fă-o în scară Fibonacci (1, 2, 3, 5, 8, 13, 20) — nu în zile sau ore. Scara non-liniară reflectă realitatea: incertitudinea crește exponențial cu mărimea, iar 8 nu e dublu față de 4, e o ligă diferită.
Echipa face estimarea în 10 minute folosind planning poker (toți arată cardul simultan). Conversația despre diferențele dintre estimări (un dev zice 3, altul 13) e mai informativă decât media — relevă ipoteze diferite despre scope sau implementation.
4. Confidence interval, nu cifre singulare
O capcană comună: scor RICE = 42.7. Sună precis, e iluzoriu. Toate inputurile sunt estimate cu eroare ±50%, deci scorul final e între 20 și 90. Tratează scorul ca interval, nu ca număr — și interval-urile suprapuse înseamnă "egal", nu "primul ăsta e mai bun".
Practic: orice diferență sub 30% între două scoruri RICE/WSJF e ruperea echivalentă cu "egal". Aici discreția PM-ului contează — pe baza altor factori care nu intră în formulă (strategie, momentum echipă, dependențe blocante). Framework-ul nu înlocuiește judecata, o calibrează.
5. Re-prioritizare la fiecare schimbare majoră, nu lunar
Backlog-ul prioritizat o dată pe trimestru se învechește în 2 săptămâni — clientul mare cere altceva, competitorul lansează un feature, regulatorul schimbă cerința. Re-prioritizezi cu RICE/WSJF la fiecare schimbare semnificativă, nu pe ritualul lunar.
Practic: ține scorurile RICE/WSJF lângă fiecare item în backlog (coloană vizibilă). Când se schimbă context-ul, deschizi item-urile afectate și ajustezi Reach/Impact/Time Criticality. Sortarea se actualizează automat. Asta convertește framework-ul din ceremonie trimestrială în mecanism viu.
Backlog prioritizat în 4myprojects
Ordinea pe care o decizi cu RICE sau WSJF o ții direct în backlog: prioritate și etichete pe fiecare item, story points pentru mărime, comentariul în care ai argumentat scorul chiar lângă task — fără spreadsheet paralel.