Scrum è una metodologia molto utilizzata per gestire la creazione di prodotti digitali, e come product manager è essenziale sapere come utilizzare questo strumento.
Il product manager ha diverse responsabilità durante il ciclo di vita del prodotto e deve gestire molti flussi di lavoro contemporaneamente, restando flessibile e capace di adattarsi velocemente a nuovi scenari. Per fare questo necessita di strumenti che lo aiutino a pianificare, organizzare, definire le priorità, e comunicare con il team in maniera chiara ed efficiente.
La metodologia Scrum, fa parte dei metodi derivati dal manifesto AGILE e, se utilizzata in maniera corretta, si presta molto bene a supportare il product manager nel gestire il quotidiano.
In questo articolo andiamo a vedere il ruolo del product manager all’interno del team e delle cerimonie Scrum.
Il ruolo del product manager nel team Scrum
All’interno del team Scrum esistono tre ruoli:
- scrum master
- product owner
- sviluppatori
I tre ruoli di Scrum descrivono le responsabilità chiave per coloro che fanno parte di un team. Non sono titoli di lavoro, il che significa che chiunque può svolgere uno di questi compiti.
Di fatto, è spesso il product manager ad assumere i ruoli di product owner e scrum master, quando non esistono persone all’interno dell’azienda che svolgono questo compito specifico.
La distinzione tra product owner e product manager è spesso motivo di confusione, poiché utilizzata quasi in modo interscambiabile da molte aziende. In breve, il product owner ha un focus tattico e operativo ed è responsabile della gestione del backlog, mentre il product manager ha un ruolo strategico e potere decisionale su quali elementi andranno a comporre il prodotto.
Le cerimonie Scrum e a cosa servono
Nella Guida Scrum i fondatori di questa metodologia definiscono una serie di meeting ricorrenti (detti “cerimonie”) per facilitare il lavoro all’interno del team. È importante notare che uno dei temi fondamentali di Scrum è l’adattabilità e quindi qualunque processo non deve essere adottato alla cieca, ma adattato in funzione del team che lo utilizza.
La misura guida di Scrum è lo Sprint, definito come un’unità di tempo che in genere varia da una a quattro settimane. All’interno dell Sprint, ai vari elementi viene assegnato un valore in punti, che corrisponde per ciascun sviluppatore ad un certo valore temporale in base alla propria esperienza.
Andiamo ora a vedere quali meeting ricorrenti ruotano intorno allo Sprint.
Sprint planning
Durante lo Sprint planning il team pianifica lo sprint successivo. Il product owner è responsabile della preparazione del backlog, i cui elementi devono essere ordinati per priorità. Un aspetto molto importante ma purtroppo spesso trascurato dello Sprint planning è la stima dei punti realizzabili in un determinato Sprint. Questi dipendono dalla disponibilità degli sviluppatori – se c’è qualcuno in vacanza o ammalato il numero di punti realizzabili deve essere adattato.
Una volta stimato quanti punti possono essere realizzati in uno Sprint, ogni elemento del backlog viene discusso dagli sviluppatori che stimano collettivamente lo sforzo richiesto. Questa stima viene spesso fatta in punti piuttosto che in unità di tempo. La misurazione in punti consente di tener conto delle diverse capacità all’interno del team degli sviluppatori: un junior developer avrà probabilmente bisogno di molto più tempo di un senior per eseguire lo stesso compito.
Una volta discussi gli elementi del backlog e stimata la capacità del team per quello Sprint deciso quali inserire nel prossimo Sprint. È importante tener conto non solo dei punti, ma anche delle competenze specifiche di ciascun sviluppatore, per evitare ad esempio di trovarsi un backlog di soli ticket backend e sviluppatori frontend senza niente da fare. Per questo è in genere buona prassi avere un’idea di quali ticket verranno assegnati a ciascun sviluppatore durante lo Sprint.
Daily standup
La daily standup è un meeting giornaliero di riassunto dei risultati raggiunti il giorno prima e pianificazione di quelli che ci si appresta ad affrontare quel giorno. Il rischio di questo incontro è che diventi lungo, noioso e poco utile. Nel peggiore dei casi, può essere vissuto dagli sviluppatori come una forma di controllo sul loro lavoro.
Per evitare che si trasformi in una seccatura, è importante ricordare che l’obiettivo di questo incontro è lo scambio di informazioni utili agli altri membri del team ed essere fiscali sulla sua durata (non più di 15 minuti).
Sprint review
La Sprint review è il momento in cui il team mostra i risultati del lavoro svolto durante uno Sprint agli stakeholder. Questi a loro volta sono incoraggiati a dare feedback. Per quanto positivo nella teoria, anche questo meeting può degenerare, ad esempio se i risultati ottenuti non sono quanto gli stakeholder si aspettavano, o se parte del lavoro svolto è altamente tecnica e perciò incomprensibile per un pubblico senza un background adeguato.
In questo contesto è fondamentale che il product manager mantenga le aspettative degli stakeholder allineate e sappia condividere con questi il valore del contributo del team, sottolineando le difficoltà di un compito in termini semplici e senza entrare in dettagli tecnici.
Sprint retro
La Sprint retro al contrario della review è aperta solo ai membri del team Scrum e si focalizza sui processi anziché i risultati dello Sprint appena concluso. Anche in questo caso le buone intenzioni, se ma dirette, possono far naufragare un’esperienza altrimenti costruttiva. Per questo motivo è buona prassi iniziare elencando tutto ciò che ha funzionato e lasciare i commenti costruttivi alla fine, sempre accompagnati da soluzioni concrete per migliorare.
