5 motivi per cambiare l'ordine degli item

Un Product Owner consegna al suo team 10 Story Card (schede con una User Story ciascuna). I membri del team le leggono e restituiscono la quinta e la sesta scheda al Product Owner. Alla fine dello Sprint, il team consegna le funzionalità delle schede 1, 2, 3, 4 e 7. Tuttavia, il lavoro sulle schede 5 e 6 non è ancora stato iniziato.

A mio parere, questo va bene.

Una raccomandazione standard nelle metodologie agili è che il team debba lavorare sugli item del Backlog nell'ordine stabilito dal Product Owner. Anche se questo ha senso fino a un certo punto, i buoni team agili fanno regolarmente eccezioni a questa regola.

Ci sono molti buoni motivi per cui un team potrebbe non rispettare l'ordine prestabilito. Ecco alcuni di questi motivi, che dovrebbero essere sufficienti come giustificazione:

1) Effetti sinergici

Spesso ci sono sinergie tra gli item in cima al Product Backlog. Mentre un team lavora, ad esempio, sull'item n. 3, dovrebbe anche poter lavorare sull'item n. 6. Se due item si trovano nella stessa parte del sistema e possono essere completati più velocemente insieme, il Product Owner dovrebbe permetterlo.

2) Dipendenze

Un team potrebbe decidere che l'item 4 è più importante degli item 5 e 6. Purtroppo, però, l'item n. 4 può essere lavorato solo dopo il completamento dell'item n. 7. Una tale dipendenza è normalmente sufficiente per permettere a un team di deviare dall'ordine previsto.

3) Disponibilità delle competenze

Un team potrebbe voler lavorare sul quarto item più importante del Product Owner, ma la persona giusta per farlo non è disponibile. Naturalmente, questo potrebbe essere un segnale che più membri del team dovrebbero essere in grado di lavorare in modo cross-funzionale, ma questa è piuttosto una soluzione a lungo termine. Una soluzione a breve termine sarebbe semplicemente lavorare su altri item fino a quando il membro del team con le competenze necessarie non è nuovamente disponibile.

4) È più interessante

Ok, su questo punto si può discutere. Non sto dicendo che il team dovrebbe lavorare sugli item n. 1, 2, 3, 4 e poi sul n. 600. Ma selezionare gli item come nel mio esempio (1, 2, 3, 4, 7) va bene se il lavoro diventa un po' più stimolante in questo modo.

In alcuni progetti, i team si imbattono occasionalmente in una serie di Product Backlog Item che non sono particolarmente divertenti. Se un team può di tanto in tanto anticipare un item che offre un po' di varietà, questo può avere un effetto positivo sul morale dei membri del team. E questo, a sua volta, è un bene per il Product Owner.

Bonus: 4.1.) È più interessante per gli Stakeholder

A proposito: affermo anche che è lecito per un team cambiare l'ordine se determinati item sono interessanti per gli Stakeholder.

A volte può essere una vera sfida convincere tutte le persone importanti a partecipare agli Sprint Review. Diventa particolarmente difficile quando le ultime review sono state piuttosto noiose. La ragione può essere l'alta priorità di determinati lavori (ad esempio, cose importanti che però non sono realmente visibili per gli Stakeholder).

In un caso del genere, può essere intelligente dare un po' di appeal al prossimo Sprint Review. Se il team lavora su qualcosa che gli Stakeholder trovano interessante, questi saranno più propensi a partecipare alla riunione.

5) Dimensione

Se i motivi precedenti non ti hanno ancora convinto, ho tenuto il motivo più convincente per la fine. Dimostra che ogni team può deviare dall'ordine stabilito dal Product Owner: un team può, ad esempio, saltare l'item n. 5 se è troppo grande. Quindi il team prende l'item successivo che si adatta allo Sprint in termini di dimensioni.

Se questo non fosse permesso, il team selezionerebbe solo gli item 1, 2, 3 e 4 e poi si fermerebbe. Allora una parte considerevole dello Sprint resterebbe inutilizzata. Naturalmente, il team potrebbe completare almeno una parte dell'item 5 e poi affrontarne un altro. Ma in molti casi questo non è particolarmente sensato. Pertanto, il team si discosterà almeno di tanto in tanto dall'ordine originale.

I Product Owner non sono perfetti

Un Product Owner perfetto saprebbe tutto questo. Un Product Owner perfetto saprebbe che i primi quattro item nel Backlog comportano già così tanto lavoro legato al database che non dovrebbe mettere un altro item simile al posto n. 5. Un Product Owner perfetto saprebbe che gli item 2 e 5 si riferiscono alla stessa classe Java e li raggrupperebbe nella prioritizzazione.

Per la maggior parte dei Product Owner, però, è difficile essere perfetti. La soluzione migliore è semplicemente prioritizzare il Product Backlog nel miglior modo possibile e poi lasciare al team la rifinitura finale.

Questo testo proviene dal blog di Mike Cohn ed è stato tradotto in italiano.

agile100: Roger Martin

=> A febbraio 2021 abbiamo parlato con Roger L. Martin del suo libro "When more is not Better".

Lavoro agile in MAN

=> Quanto è agile MAN Truck & Bus SE e come funziona il lavoro agile nel settore automobilistico?