Criteri per la prioritizzazione del backlog di prodotto [chiuso]

In Scrum, l'ordine degli articoli nel Product Backlog è la esclusiva provincia del Product Owner.

Ci sono molti modi diversi per raggiungere questo obiettivo. Dal semplice:

Utilizza il valore aziendale e la stima che devono essere associati a ciascun articolo del Backlog del prodotto. Calcola un numero di ritorno sull'investimento (RoI) semplice dividendo il valore dell'attività per stima. Il valore più alto della RoI è ordinato più alto nel Product Backlog.

Più complesso, dove i proprietari dei prodotti creano i loro algoritmi personalizzati.

Ci sono altri fattori che un Product Owner potrebbe considerare come il rischio (fare prima gli articoli ad alto rischio) o i consigli tecnici del Development Team.

Resta il fatto che solo il Product Owner stabilisce l'ordine degli articoli nel Product Backlog.

Un'altra breve nota: quando si scrivono gli articoli del Product Backlog, un principio guida è quello di mantenere gli articoli indipendenti. Non è sempre possibile, ma gli Scrum Teams si impegnano duramente per raggiungere questo obiettivo. Pertanto, la nozione di utilizzare le dipendenze per decidere l'ordine è raramente necessaria o utilizzata.

Nella mia esperienza, quando io o il proprietario del prodotto abbiamo dovuto prendere in considerazione la completa complessità delle storie, abbiamo usato quanto segue:

1. Priorità aziendale
2. Sforzo di sviluppo
3. Rischio di sviluppo
4. Sforzo di prova

Nella nostra situazione, utilizziamo il rischio di sviluppo per identificare elementi che dovrebbero essere fatti prima per consentire più cicli di revisione e feedback. Includiamo il test per assicurarci che non proviamo a fare un mucchio di cose che sono più semplici da costruire, ma molto difficili da testare. Entrambi gli sforzi vengono utilizzati per creare casi nei confronti dei clienti che un articolo debba arrivare prima nel backlog, poiché richiederà più tempo per l'implementazione.

Quando si cerca di mantenere qualcosa vicino a una pianificazione, ridurre il rischio di scivolare sulla data di consegna è importante anche per il business, non solo per il valore degli articoli.

Detto questo, quando abbiamo legami o cose che sembrano vicine, il valore aziendale deve essere ponderato più strong. Non possiamo semplicemente fornire una serie di storie di basso valore che sono difficili da costruire, testare e comportare un rischio elevato. Per questo motivo, il valore aziendale assume un peso maggiore nei nostri calcoli.

Stai mescolando due cose qui: priorità per la priorità aziendale e tecnica. E entrambe le cose sono gestite da persone diverse. La priorità aziendale dovrebbe essere scelta dal cliente / proprietario del prodotto. Ecco come dovrebbe essere ordinato l'intero arretrato. Nessun elemento tecnico è preso in considerazione da questo elenco. Gli sviluppatori quindi scelgono questo elenco in base alla priorità tecnica. Il punto chiave è che non devono scegliere i 10 elementi principali, ma possono selezionare gli elementi che sanno di poter implementare nello sprint, ma che hanno ancora priorità elevata.

Il problema di mescolare entrambi in una singola lista è che il valore aziendale si offusca. Ad esempio, alcune storie potrebbero avere un enorme valore commerciale, ma potrebbe richiedere molto tempo per essere implementata. Nel tuo caso, scenderebbe anche se è davvero importante grazie al mix dei tempi di implementazione. Simile se questa storia dipende da altre storie, che potrebbero avere una priorità inferiore. Se gli sviluppatori non lo scelgono a titolo definitivo, il fatto che sia ancora in cima alla lista gli ricorda che dovrebbero concentrarsi sull'implementazione nelle prossime iterazioni. Dall'altra parte, potrebbero scegliere una storia a bassa priorità semplicemente perché è breve e nessun'altra storia si adatterebbe al resto dell'iterazione.