Gestione del Prodotto con Scrum: Guida Completa + Esempi
Scrum non è una novità nel campo della gestione prodotto. La maggior parte di noi utilizza Scrum nelle proprie aziende e cerca di navigare tra i ruoli e i principi di questo framework per raggiungere i propri obiettivi.
Purtroppo, è comune che le aziende fraintendano i principi di Scrum e li utilizzino in modo scorretto, privando così gli utenti dei numerosi benefici di Scrum.
Questa piccola e simpatica guida serve proprio ad aiutarti a sfruttare meglio questo framework, spiegando di cosa si tratta, perché esistono differenti ruoli in Scrum, quali sono le responsabilità della gestione prodotto e come eccellere nella collaborazione cross-funzionale.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Che cos’è Scrum nella gestione prodotto?
A molti di noi piace discutere il ruolo del product manager all’interno della realtà dei processi Scrum e della metodologia Agile (in altre parole, cosa fa il PM in un team Scrum). Invece di spiegarlo soltanto, penso sia più facile mostrarti semplicemente dove si trova il PM nell’organigramma del team.
Tuttavia, per questa guida desidero affrontare l’argomento nella direzione opposta e mostrarti come Scrum si inserisca nella tua realtà di professionista della gestione prodotto e come possa aiutarti a raggiungere i tuoi obiettivi di prodotto.
Voglio iniziare discutendo l’effetto che i principi fondamentali del framework Scrum hanno sull’efficacia del nostro lavoro.
Probabilmente il principio Scrum più prezioso per noi è la costante consegna di valore agli utenti. Più velocemente le persone riescono a risolvere problemi, migliori saranno le performance del tuo prodotto. Inoltre, si ottiene un feedback precoce da parte delle persone che hanno utilizzato una funzionalità in uno scenario reale.
Il secondo vantaggio che offre Scrum è la flessibilità. Se la realtà del mercato cambia, puoi adattarti rapidamente azzerando completamente il backlog del prodotto e fornendo nuove funzionalità al tuo team già nello sprint successivo (questo è qualcosa in cui l’IA nella pianificazione degli sprint può aiutare).
Entrambe queste cose sono molto difficili (se non quasi impossibili) da ottenere con framework tradizionali come Waterfall, dove tutto è fisso nell’ambito e gli utenti accedono al prodotto solo al termine del ciclo di vita dello sviluppo software.
Esempi di successo di prodotto grazie all’integrazione di Scrum
Avendo lavorato per anni con team Scrum, sono apertamente di parte verso questo framework Agile. Quindi, non prendere le mie parole come verità assoluta. Meglio guardare a casi reali in cui il passaggio a Scrum ha aiutato i team di prodotto a raggiungere il successo più rapidamente.
Microsoft Visual Studio: Il principale strumento di coding del colosso tecnologico era tristemente noto per ripetuti cicli di produzione infernali, con release piene di bug e rilasci incredibilmente rari. Dal momento in cui il team di prodotto ha iniziato a sfruttare Scrum, l’azienda ha registrato un netto aumento della stabilità del prodotto unitamente a rilasci molto più frequenti—ristabilendo così la propria competitività sul mercato.
Spotify: L’adozione di Scrum da parte del nostro amato servizio di streaming musicale è una delle più note del settore. Spotify aveva difficoltà ad adattarsi e a scalare abbastanza velocemente da risolvere le sue sfide di processo...fino all’adozione di Scrum. Ma ciò che distingue Spotify è lo sviluppo di un proprio modello di project management Scrum, che prevedeva un gruppo di team Agile autonomi, dotati di tutte le competenze necessarie per sperimentare rapidamente e integrare il feedback degli utenti.
ING: Il colosso bancario olandese è stato tra le prime istituzioni finanziarie a comprendere che il futuro della banca sarebbe stato digitale. Ha anche capito che i tradizionali processi di project management non erano sostenibili nello sviluppo software. Così ha rapidamente adottato metodologie lean e Scrum, diventando — senza grande sorpresa — leader nel settore dell’e-banking.
Ruoli chiave nella gestione prodotto in Scrum
Se tu, come PM, decidi che Scrum sia la via da seguire, ecco una panoramica rapida dei ruoli chiave di questo framework e ti aiuterò a distinguere tra il tuo ruolo di product manager e quello di product owner Scrum.
Partiamo dai ruoli. Un tipico team Scrum è composto dalle seguenti persone:
- Scrum master: Questa persona aiuta il team a seguire le regole di Scrum e a ottimizzare i propri processi.
- Product Owner: Rappresenta il business e gli utenti all’interno del team Scrum. I PO sono responsabili del backlog e fissano gli obiettivi dello sprint e le priorità delle storie utente.
- Scrum team: I tuoi sviluppatori, designer, QA e altri specialisti che costruiscono il prodotto.
Per quanto riguarda il team Scrum, puoi avere molti altri tipi di specialisti nel gruppo. Il concetto di team cross-funzionali implica che il team sia indipendente per quanto riguarda l’accesso alle competenze professionali. Quindi, ad esempio, se il tuo prodotto si basa molto sull’analisi dei dati, potresti avere anche un data analyst nel team.
Product Manager vs. Product Owner: Qual è la differenza?
La definizione di product owner che ho dato potrebbe confonderti un po’, perché suona molto come quello che tipicamente fa un product manager.
Quindi, in questo caso, qual è la differenza tra product manager e product owner?
Per capire la differenza, diamo prima un’occhiata alle responsabilità principali di ciascuno.
Product Manager
- Svolge la discovery di prodotto e comprende i bisogni e le difficoltà dei clienti.
- Definisce la visione di prodotto e la direzione che il team dovrà seguire.
- Propone soluzioni di prodotto che incontrino le esigenze dei clienti.
- Guida il processo di delivery del prodotto.
- Raffina il prodotto con piccoli incrementi in base ai feedback dei clienti e alle decisioni basate sui dati.
- Gestisce la visione di prodotto e l’esecuzione sia in verticale che in orizzontale all’interno dell’azienda.
Product Owner
- Crea e mantiene il product backlog.
- Funziona come unica fonte di verità in termini di strategia, design e logica di business per il team Scrum.
- Dà priorità agli elementi del product backlog e porta chiarezza al team su ciò che è importante.
- Definisce i criteri di accettazione per le funzionalità e accetta i risultati dello sprint in base a questi.
- Sblocca i membri del team chiarificando i requisiti e risolvendo le problematiche legate a questi.
- Partecipa agli eventi Scrum e rappresenta la voce del business e dei clienti all’interno del team.
Come possiamo vedere, la maggior parte di noi svolge attività che si trovano in entrambe le liste. È una cosa piuttosto normale e comune, dato che molti ricoprono ruoli di product manager e owner contemporaneamente.
La differenza fondamentale tra questi due ruoli è che la gestione di prodotto è una professione e una competenza, mentre la product ownership è un ruolo all’interno del team Scrum.
Ma cosa significa?
Significa che il product owner non deve necessariamente essere un product manager. In una startup piccola, in cui hai il CEO ed altri tre sviluppatori, il CEO ricoprirà il ruolo di product owner fornendo agli sviluppatori un backlog prioritizzato.
L’opposto è anche possibile. Puoi essere un product manager senza essere un product owner. Un buon esempio è il mio caso: uno dei miei vecchi team non applicava Scrum. Nessuno Scrum, nessun product owner in squadra. Tuttavia, seguivamo i principi lean e Agile.
Per chiarire ancora meglio la differenza tra queste due figure, ecco un confronto fianco a fianco delle rispettive attività.
Ma qual era il vero motivo per avere un ruolo speciale nel team Scrum? Non avrebbero potuto semplicemente collaborare con product manager esterni al team? Mi piace molto la risposta di Teresa Torres.
Quindi, il motivo principale per cui esiste una figura di prodotto specifica nel team Scrum è per contribuire con conoscenze e competenze interne sul prodotto e rafforzare ulteriormente la cross-funzionalità del gruppo.
Come il Product Manager interagisce con i team Scrum
Supponendo che tu abbia deciso di intraprendere la strada dello Scrum, dovrai sapere come diventare un membro del team e collaborare con i tuoi colleghi. Ecco una breve panoramica di questo aspetto per ogni evento Scrum e artefatto.
- Daily Scrum (detta anche standup): Il lavoro più importante che svolgi durante queste riunioni a tempo limitato è rispondere alle domande relative al prodotto del tuo team di sviluppo e rimuovere gli ostacoli.
- Riunione di Pianificazione dello Sprint: Qui sei tu a fissare l'obiettivo dello Sprint, definendo chiaramente le tue aspettative sulle funzionalità che ti aspetti di consegnare.
- Retrospective dello Sprint: I processi che utilizzi per trasmettere le priorità e i requisiti al team possono determinarne l'efficacia. Puoi quindi usare questa riunione per raccogliere feedback dal team e migliorare i tuoi processi.
- Review dello Sprint: Qui il tuo compito è accettare le funzionalità completate dello Sprint e dare al team un feedback sul loro lavoro.
- Product Refinement (detta anche grooming): Sei il responsabile di questa riunione e devi utilizzare il tempo a tua disposizione per discutere le priorità e i dettagli delle user story che hai per il team. Incoraggia sempre il team a mettere in discussione i tuoi requisiti e a trovare “bug di prodotto” che hai eventualmente lasciato.
- Product Backlog: È tua responsabilità gestire il product backlog e mantenerlo ordinato e prioritizzato, dato che il team baserà su di esso lo Sprint.
- Sprint Backlog: Questo non è di tua competenza. Il tuo principale punto di collaborazione è guidare il team affinché scelga le giuste storie da inserire nello Sprint backlog e assicurarsi così che possa raggiungere l'obiettivo dello Sprint.
Oltre a ciò, svolgerai altri tipi di attività di prodotto, come la gestione degli stakeholder o la product discovery. Come membro dello Scrum team, il tuo compito è mantenere il team informato sia sulle esigenze degli stakeholder sia su quelle degli utenti, una volta che le hai chiarite.
Ad esempio, se fai un colloquio con un utente e scopri che la user experience del tuo flusso di login risulta in generale confusa, è importante condividere questa informazione con il team per assicurarsi che presti attenzione a quella parte nei successivi sprint.
Best practice per la gestione di prodotto in Scrum
Sebbene la gestione di prodotto sembri semplice se vista attraverso la lente di Scrum (e dello sviluppo Agile in generale), sono molti gli errori che si commettono abitualmente lavorando all'interno dei nostri team auto-organizzati.
Ecco quindi alcune best practice di Scrum che ti aiuteranno ad evitarli:
- Definisci aspettative chiare: Il peggior errore che puoi commettere è fornire al tuo team priorità e requisiti vaghi. La mancanza di chiarezza è una delle principali cause di ritardi nello sviluppo e di tensioni tra te e il team. Tra poco approfondiremo come ottenere chiarezza.
- Non abusare della flessibilità: Avere la possibilità di cambiare direzione è ottimo, ma puoi farlo solo nel product backlog, non nello sprint backlog. Dal momento in cui lo sprint inizia, non aggiungere né rimuovere storie dal suo backlog. Questo manda all’aria i piani e il progresso del team e porta a sprint incompleti.
- Crea un ambiente emotivamente sicuro: Sei un membro del team, non il loro capo. Non spingere quindi il team a prendersi impegni più grandi o a terminare in anticipo. Le guide Scrum dappertutto, inclusa quella di Scrum.org, pongono molta enfasi sul mantenimento di relazioni sane con i compagni di squadra, in quanto è uno dei pilastri del lavoro di squadra efficace.
Queste tre best practice sono a mio avviso le più importanti. Ma se desideri altri consigli sui flussi di lavoro Agile e sulle best practice Scrum per i product manager, ti consiglio di leggere la nostra guida dedicata su gestione di prodotto Agile.
Gestire il Product Backlog in modo efficace
Come accennato prima, fornire chiarezza al tuo team è uno dei compiti più importanti per un product manager. La buona notizia è che il tuo product backlog è probabilmente lo strumento migliore per raggiungere questo obiettivo. Ecco quindi alcuni suggerimenti di gestione del product backlog utili a questo scopo:
Grooming: Non importa quanto bene siano scritte le tue user story, lascerai sempre qualche “bug” che vorrai che il team di sviluppo esamini e ti segnali. Considera anche che non sei uno sviluppatore e potresti scrivere requisiti difficili da realizzare: anche qui sarà il tuo team a farti notare queste criticità durante il processo di grooming.
Tecniche di prioritizzazione: Approfitta dei numerosi framework di prioritizzazione per capire quali funzionalità siano più importanti di altre. Il mio preferito è il metodo MoSCoW, per la sua semplicità.
Allineamento con roadmap e vision: Gli epic e le story nel backlog dovrebbero rappresentare gli obiettivi e i KPI generali di prodotto che vuoi raggiungere. Assicurati quindi di rivedere costantemente la roadmap quando aggiungi elementi nel backlog.
Il segno più evidente che un’organizzazione manca di chiarezza si manifesta quando si va in giro per l’organizzazione a chiedere a persone diverse quali pensano siano i criteri di successo per ciò che deve essere consegnato come prossimo grande traguardo, e si iniziano a sentire storie differenti.
Allineare gli stakeholder nello Scrum
L'essenza del ruolo di un product manager in Scrum è essere sostanzialmente il collegamento tra il team auto-organizzato e il mondo esterno, che siano utenti, stakeholder o altri team.
Quindi, oltre a svolgere i normali compiti di gestione degli stakeholder come PM, è anche necessario riportare queste informazioni al proprio team, e viceversa. Ci saranno anche casi in cui dovrai trasmettere informazioni dal team agli stakeholder.
Un buon esempio è la comparsa di sfide tecniche, come i problemi di integrazione continua, che possono influire sulla tempistica o sullo scopo di una determinata funzionalità. È qualcosa che devi discutere con gli stakeholder e accettare eventualmente la nuova tempistica/scopo o cercare una soluzione diversa (ad esempio, rafforzando il team con più esperti in materia).
Ci sono anche casi in cui il tuo team può aver avuto un'idea interessante per una funzionalità o una soluzione che vale la pena aggiungere alla roadmap. Anche in questo caso, riporti questa informazione agli stakeholder e decidete insieme se aggiungerla o meno ai piani.
L'importanza della roadmap Agile nello Scrum
Sebbene non sia direttamente parte dello Scrum, le roadmap Agile sono uno degli strumenti che rendono possibile lo Scrum. In fondo, che senso ha pianificare in modo iterativo se usi il metodo Waterfall per il tuo prodotto invece di una roadmap Agile?
In tal caso, qualunque cosa tu chiami strategia di prodotto Scrum sarebbe semplicemente dividere un piano già definito e fisso secondo il classico SDLC in parti da 2 settimane (o comunque quanto durano i tuoi sprint). Per rendere significativo lo Scrum per il team, devi invece lavorare con pianificazioni interattive Agile e realizzare una roadmap che sia capace di cambiare nel tempo.
Per integrare efficacemente la tua roadmap Agile con i processi Scrum del team, ecco cosa ti suggerisco di fare:
- Collega gli elementi della roadmap (di solito Epic) alle user story nel backlog prodotto. In questo modo, c'è una connessione diretta tra il lavoro tattico (le storie) e la strategia (la roadmap).
- Presenta la tua roadmap al team Scrum. In questo modo, il team saprà quale direzione sta prendendo il prodotto e potrà tenere conto delle funzionalità in arrivo quando progetta l'architettura frontend o backend.
- Sfrutta strumenti specializzati come Jira, Monday.com e ClickUp per ottimizzare il processo di mappatura della roadmap e di gestione del backlog.
Per quanto riguarda l'ultimo punto, questi tre strumenti sono quelli che ho usato in pratica. Tuttavia, esistono molti altri strumenti di product management che puoi considerare per le stesse esigenze.
More Articles
- L’IA nella Ricerca sugli Utenti: Come l’Intelligenza Artificiale Sta Trasformando le Analisi sugli Utenti
- Spedire Prodotti Global-First Senza il Mal di Testa Globale: Come Integrare la Localizzazione nel Tuo Flusso di Lavoro di Prodotto
- L’IA nella Pianificazione dello Sprint: Come l’IA Migliora l’Efficienza del Team
Le sfide nella gestione di prodotto con Scrum
Sebbene Scrum sia un ottimo framework per il raggiungimento degli obiettivi di prodotto, il suo utilizzo presenta una serie di sfide, tra cui:
- Il tuo team o i tuoi stakeholder potrebbero non capire di cosa tratta Scrum. Questo può, ovviamente, portare a significativi problemi nell'adozione di Scrum, come il rifiuto di utilizzare determinati artefatti. Consiglio di prevenire questa situazione illustrando lo 'stato finale' desiderato, ovvero come appariranno il team e il flusso di lavoro quando il framework sarà pienamente implementato.
- Le persone (e anche tu) potrebbero confondersi riguardo al proprio ruolo nel team e all'esterno del team. Ogni azienda per cui ho lavorato nella mia carriera aveva la sua personale idea di cosa fosse un Product Owner Scrum. È meglio stabilire cosa sia—e cosa non sia—per il tuo team.
- L'ambito delle funzionalità su cui lavori tende ad espandersi all'infinito. Non sorprende che questo renda davvero facile entrare nel territorio dello scope creep. I team Scrum devono essere molto severi su cosa prendere in carico e a cosa dire 'no'.
- La roadmap può facilmente deragliare. Avendo un team relativamente indipendente che può scegliere su cosa lavorare, potresti trovarti nella situazione in cui realizzano cose che sono fuori dalla tua roadmap. Mantenere sempre bene a fuoco l'obiettivo finale è fondamentale per evitare questa insidia.
Anche se queste sfide sono piuttosto comuni, la buona notizia è che basta solo qualche sprint al PM per prendere dimestichezza con il processo Scrum e superare la loro stragrande maggioranza. Per chi desidera formalizzare le proprie competenze, imparare come diventare Scrum Master può offrire ai leader un vantaggio credibile nel guidare i team attraverso il framework.
Conclusione
Scrum è uno dei migliori strumenti a disposizione dei product manager. Grazie all'equilibrio tra agilità sul lungo periodo e rigorosità nelle iterazioni brevi, puoi evitare il caos di uno sviluppo Agile senza framework, mantenendo comunque la possibilità di cambiare rotta in base alla risposta del mercato.
Speriamo che la nostra guida ti sia piaciuta. Se è così, non dimenticare di iscriverti alla nostra newsletter per ricevere altre risorse e guide sulla gestione prodotto, oltre ai podcast più recenti, interviste e altri approfondimenti da leader ed esperti del settore.
FAQ:
Qual è il ruolo di un Product Manager in Scrum?
I product manager, che tipicamente svolgono il ruolo di product owner nel team scrum, sono responsabili di fornire al team chiarezza condividendo i piani del prodotto, le priorità e i requisiti necessari delle funzionalità.
In cosa Scrum si differenzia da altre metodologie Agile nella gestione prodotto?
A differenza di Kanban o altri framework Agile, Scrum è più strutturato e ha regole chiare su come organizzare il lavoro all’interno del team tramite eventi (standup, grooming, ecc.) e artefatti (sprint backlog, product backlog, ecc.).
Quali sono le sfide comuni nella gestione prodotto Scrum?
La sfida più comune è che il tuo team e i tuoi stakeholder interpretano male le regole e gli artefatti del framework scrum e provano a modificarle prima che l’azienda abbia realmente tentato di adattarsi a questo nuovo framework.
Un Product Manager può essere anche Product Owner?
Sì. Product Manager è una professione. Product Owner è un ruolo in un team scrum. Nella maggior parte dei casi, il product owner del team è un product manager. A volte, soprattutto nelle startup più piccole, anche i CEO possono ricoprire il ruolo di product owner nel team.
