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
Câmpuri RICE și WSJF native pe fiecare item, sortare automată după scor, planning poker integrat pentru estimare, intervale de confidence vizibile pe board — fără spreadsheet paralel.