Prioritizzazione con cost of delay

Prioritizzare è una delle attività più importanti e difficili nella vita di qualsiasi Product Owner. La maggior parte delle volte la difficoltà nel prioritizzare si verifica perché le persone hanno diverse opinioni sugli impatti che ogni elemento del Product Backlog può avere sul prodotto finale.

Beh, e questo è il problema. La prioritizzazione basata su opinioni (che di solito hanno un peso proporzionale al peso del badge di chi sta opinando). Quando in qualche modo riusciamo a rendere tangibile il valore di ogni elemento nel nostro Product Backlog, la discussione diventa molto più razionale.

Un modo per capire meglio il valore di ogni funzionalità viene attraverso una semplice domanda: quanto stiamo perdendo per non aver ancora consegnato questo elemento?

Rispondere a questa domanda non è sempre facile, e spesso implica molto lavoro di ricerca. L’importante è ricordare sempre che non stiamo sempre cercando informazioni super precise qui. Lo scopo di comprendere il valore di ogni elemento è aiutarci a prendere una decisione razionale.

Per esempio: diciamo che un certo elemento mi farà guadagnare tra $6.000 e $40.000. Questo intervallo è molto ampio e può sembrare avere poco valore, ma se so che il costo dell’elemento non dovrebbe superare $3.000, posso già prendere una decisione e non ho bisogno di investire più tempo a raffinare la mia ricerca per restringere questo intervallo.

Diversi tipi di cost of delay

Ogni elemento può avere un costo di ritardo in un formato diverso: alcuni tendono a crescere linearmente e altri esponenzialmente. Ci sono anche quelli con una data fissa, come la conformità a una legge con una data di entrata in vigore, e altri il cui costo non ha una relazione così rilevante con il tempo di ritardo. Capire quali tipi di elementi hai nel tuo Product Backlog è il primo passo per razionalizzare il tuo processo di prioritizzazione.

Il tipo di elemento più comune da trovare in un Product Backlog sono quelli il cui costo di ritardo tende ad aumentare nel tempo, sia linearmente che esponenzialmente. Immagina un prodotto con i seguenti elementi nel suo Product Backlog:

Tabella con elementi del Product Backlog e i loro costi

Ogni elemento ha un costo stimato per settimana di ritardo e un tempo di sviluppo stimato. Se dividiamo il costo di ritardo per la durata di ogni elemento, arriviamo al famoso CD3: Cost of Delay Divided by Duration (costo di ritardo diviso per la durata).

Ma perché questo CD3 è importante? Per rispondere a questa domanda, proviamo a prioritizzare questo backlog in tre modi diversi.

Prioritizzazione per dimensione

Se scegliamo di consegnare prima gli elementi più piccoli, la nostra curva di consegna sarebbe più o meno così:

Grafico prioritizzazione per dimensione

Nella prima settimana avremmo un costo di ritardo equivalente a tutti gli elementi sommati (2.000 + 5.000 + 6.000 + 1.500), dopotutto non abbiamo consegnato nulla.

Alla fine della settimana 1 siamo riusciti a consegnare l’elemento Notifiche (che è stato prioritizzato per avere la durata più breve) e con ciò abbiamo ridotto il nostro costo totale di ritardo di 2.000. E poi ripetiamo questo processo per i prossimi elementi nel Product Backlog.

Alla fine, abbiamo il seguente scenario:

  • 1 settimana con costo totale di ritardo di 14.500

  • 2 settimane con costo totale di ritardo di 12.500

  • 3 settimane con costo totale di ritardo di 11.000

  • 4 settimane con costo totale di ritardo di 6.000

In questo scenario il nostro costo totale di ritardo è stato:

(1 x 14.500) + (2 x 12.500) + (3 x 11.000) + (4 x 6.000) = 96.500

Prioritizzazione per valore

Quando prioritizziamo per valore, le cose cambiano un po’:

Grafico prioritizzazione per valore

  • 4 settimane con costo totale di ritardo di 14.500

  • 3 settimane con costo totale di ritardo di 8.500

  • 1 settimana con costo totale di ritardo di 3.500

  • 2 settimane con costo totale di ritardo di 1.500

In questo scenario iniziamo a lavorare con l’elemento APP perché ha il più alto costo di ritardo per settimana. Alla fine abbiamo un costo totale di ritardo di:

(4 x 14.500) + (3 x 8.500) + (1 x 3.500) + (2 x 1.500) = 90.000

Prioritizzazione per CD3

La prioritizzazione per valore ha generato un risultato leggermente migliore, ma abbiamo ancora margine di miglioramento. Guarda cosa succede quando prioritizziamo per CD3:

Grafico prioritizzazione per CD3

  • 1 settimana con costo totale di ritardo di 14.500

  • 3 settimane con costo totale di ritardo di 12.500

  • 4 settimane con costo totale di ritardo di 7.500

  • 2 settimane con costo totale di ritardo di 1.500

(1 x 14.500) + (3 x 12.500) + (4 x 7.500) + (2 x 1.500) = 85.000

Una buona riduzione, vero? E un ottimo esempio di come una persona che agisce come Product Owner può avere un impatto molto positivo sullo sviluppo del prodotto!

Conclusione

Sapere come prioritizzare bene è importante, e per farlo avrai sempre bisogno di avere una buona comprensione del valore di ogni elemento nel tuo Product Backlog.

Formule come il calcolo del CD3 possono aiutare molto una volta che hai fatto il primo passo: avere questo senso del valore. Ma questo primo passo dipende molto dalla vicinanza del Product Owner al mercato e da una buona comprensione dei problemi dei clienti. E beh, non c’è una formula magica per questo. :)

Autonomia nella Retrospettiva
3 fake news che potresti aver sentito su Scrum