Cos’è Scrum e perché domina il panorama Agile nel 2026?
Definizione operativa di Scrum
Scrum è un framework Agile che struttura il lavoro in cicli brevi e time-boxed chiamati sprint, con ruoli, artefatti ed eventi definiti per consegnare valore in modo iterativo. Non è una metodologia con procedure scritte nella pietra: è un insieme di regole operative minime, pensato per tenere un team allineato mentre i requisiti cambiano sotto i suoi piedi.
La distinzione tra framework e metodologia non è accademica. È pratica. Una metodologia ti dice esattamente cosa fare. Scrum ti dà uno scheletro e ti lascia decidere come riempirlo, sprint dopo sprint. Atlassian lo definisce come una struttura con sprint time-boxed, ruoli precisi, artefatti e cerimonie, tutta orientata alla consegna iterativa di valore reale al cliente.
In soldoni: tre ruoli (Product Owner, Scrum Master, Development Team), cinque eventi (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), tre artefatti (Product Backlog, Sprint Backlog, Increment). Punto. Tutto ciò che non sta in questi elementi non è Scrum, è un’aggiunta del tuo contesto.
E il contesto conta moltissimo. Scrum funziona su progetti con requisiti incerti, cambiamenti frequenti, alto grado di complessità. Non ha senso applicarlo a un lavoro ripetitivo e prevedibile: lì si spreche solo energie. Ma nei progetti software, nella gestione prodotto, nello sviluppo di servizi digitali, dove il cliente sa solo a grandi linee cosa vuole, Scrum è la struttura che trasforma l’incertezza da ostacolo in risorsa.
Tra i team che mi è capitato di seguire negli anni, quelli che faticavano di più erano quasi sempre quelli che avevano adottato Scrum come etichetta senza capirne la logica sottostante: facevano i Daily Scrum ma nessuno aggiornava il backlog, tenevano le Sprint Review senza invitare il cliente, chiamavano “sprint” qualsiasi settimana lavorativa. Scrum mal applicato non è Scrum. È rumore con un nome famoso.
Scrum dentro il movimento Agile
Scrum non è nato dal nulla. Cresce dentro un movimento più ampio: il manifesto Agile del 2001, con i suoi dodici principi, di cui il primo recita che la priorità massima è soddisfare il cliente attraverso la consegna anticipata e continua di software funzionante. Scrum è, tra tutti i framework nati da quel manifesto, quello che ha trasformato quel principio in meccanica operativa concreta.
I numeri raccontano una storia che vale la pena leggere per intero. Nel 2021, il 14° State of Agile Report registrava un’adozione di Scrum al 58% tra i team Agile. Nel 2024, il 16° Report porta quel numero all’87%: quasi nove team su dieci che lavorano in Agile usano Scrum. Sono +29 punti percentuali in tre anni, una crescita che non si spiega solo con la moda del momento.
Ma Scrum non vive isolato. L’81% degli Scrum Master, secondo dati di Scrum.org e Age of Product riportati da Parabol, usa Scrum insieme a Kanban. Il 54% lo abbina a pratiche DevOps. Scrum è sempre più il nucleo di un sistema ibrido, non un’isola.
Poi c’è la dimensione enterprise. Il 28% dei rispondenti al 16° State of Agile Report dichiara di usare Scrum@Scale o Scrum of Scrums, contro il 9% dell’anno precedente. I team crescono, si moltiplicano, e cercano un modo per coordinare più scrums senza perdere l’agilità che li ha resi efficaci in primo luogo.
A mio avviso, però, il dato più rilevante non è la percentuale di adozione. È il 78% di professionisti Scrum che raccomanderebbero il framework a colleghi e amici, secondo i dati Scrum Alliance citati da Parabol. Un Net Promoter Score di quel livello, in qualsiasi settore, è la prova che le persone che ci lavorano davvero lo trovano utile, non solo che le aziende lo impongono dall’alto.
Quindi Scrum domina il 2026 non perché qualcuno ha deciso che doveva farlo. Domina perché funziona su progetti complessi, perché scala, perché si adatta. E perché chi lo usa tende a non tornare indietro.
Perché molti team italiani applicano Scrum solo a metà?
L’adozione parziale di Scrum è la pratica di implementare alcuni elementi del framework (sprint, backlog) tralasciandone altri (Daily Scrum, Retrospective, Definition of Done). È più diffusa di quanto si pensi, e i danni che causa sono silenziosi: il team lavora, consegna, si sente agile. Ma non lo è davvero.
Il gap tra adozione dichiarata e pratica reale
Nei miei anni di formazione con team italiani ho visto lo stesso schema ripetersi decine di volte. L’azienda annuncia la transizione a Scrum, compra qualche licenza, manda due persone a fare il corso. Poi gli sprint partono, il backlog prende forma. E lì si fermano.
Il problema è strutturale, non di buona volontà. Scrum viene percepito come un insieme di pratiche modulari: “prendiamo quello che ci serve”. Ma il framework non funziona così. Gli eventi non sono opzionali, sono il meccanismo che genera l’adattamento continuo. Togliere un evento è come togliere un ingranaggio a un orologio e aspettarsi che segni ancora l’ora giusta.
I dati confermano questo gap. Secondo il 16° State of Agile Report citato da Parabol, quasi 9 rispondenti su 10 (87%) dichiarano di usare Scrum. Ma dichiararlo e praticarlo sono due cose diverse. E a conti fatti, la differenza tra uno Scrum completo e uno Scrum “di facciata” si misura in qualità, velocità e fiducia del team.
CA Technologies ha rilevato che i team che applicano Scrum in modo completo hanno una qualità del prodotto 250% superiore rispetto ai team che non stimano il lavoro. Il dato è citato nell’analisi di Parabol sulle statistiche Scrum e, a mio avviso, è il numero più eloquente sull’argomento. Non è un margine di miglioramento. È un ordine di grandezza diverso.
Quali eventi vengono saltati per primi
Non tutti gli eventi di Scrum resistono allo stesso modo alla pressione del quotidiano. Alcuni sopravvivono quasi sempre. Altri spariscono nel giro di pochi sprint.
Lo Sprint Planning tiene, almeno nella forma. Serve per assegnare il lavoro, quindi nessuno lo cancella. Il Daily Scrum resiste meglio di quanto ci si aspetti: secondo i dati di Scrum Alliance riportati da Parabol, l’87% dei team Scrum lo tiene regolarmente. Ma “tenerlo” non significa farlo bene. Spesso diventa un briefing verticale, il team risponde al manager invece di sincronizzarsi tra pari. La forma sopravvive, la sostanza no.
La Sprint Retrospective è l’evento che sparisce prima. Sempre. Il motivo che si sente più spesso è “non abbiamo tempo”. Ma la Retrospective è esattamente lo spazio in cui il team capisce perché non ha tempo. Saltarla è come ignorare la spia del motore perché si è di fretta.
Poi c’è la Sprint Review. Sopravvive solo se c’è uno stakeholder che la chiede. Se il cliente è lontano o disinteressato, la Review si trasforma in una demo interna informale, poi scompare del tutto.
E lo Sprint Planning completo? In molti team italiani si riduce a una lista di task assegnati dal product owner. La stima, la discussione, la negoziazione sul “quanto” e sul “come” vengono tagliate per risparmiare tempo. Ma è esattamente qui che nasce il ritmo sano di uno sprint. Senza quella fase, il team entra nello sprint senza accordo condiviso e senza ownership reale sul lavoro.
Tutto sommato, il pattern è chiaro: sopravvivono gli eventi visibili verso l’esterno (Planning, Daily), spariscono quelli interni al team (Retrospective, Review autentica). Quindi il team perde proprio gli spazi in cui potrebbe migliorare se stesso. Scrum diventa una struttura di consegna, non un sistema di apprendimento. E i 59,1% di team che usano sprint di due settimane come default (dato Broadcom via Parabol) si ritrovano con cicli brevi ma senza il meccanismo di ispezione e adattamento che quei cicli dovrebbero alimentare.
Il risultato? Si fa Scrum. Ma Scrum non funziona. E la colpa, all’interno del team, ricade sul framework invece che sull’implementazione incompleta.
Scrum o Agile: qual è la differenza che devi conoscere prima di certificarti?
Agile è una filosofia di project management basata su valori e principi iterativi; Scrum è una metodologia specifica che implementa quella filosofia con regole operative definite. Sembra una distinzione sottile. Non lo è. Confondere i due è uno degli errori più frequenti che vedo fare a chi si avvicina per la prima volta al mondo delle certificazioni, e può portare a scegliere il percorso di studio sbagliato fin dall’inizio.
Agile come mindset
Il Manifesto Agile non è un manuale operativo. È una dichiarazione di valori: collaborazione, adattamento, risposta al cambiamento. I 12 Principi che lo accompagnano mettono al primo posto la consegna continua di valore al cliente, come chiarito direttamente da Agile Alliance. Non dicono quanti minuti deve durare una riunione. Non prescrivono ruoli. Non definiscono la lunghezza di un ciclo di lavoro.
Agile è il perché. Non il come.
Northeastern University lo sintetizza bene: Agile è il sistema di valori e principi, Scrum è il framework che li applica. Questa differenza non è accademica: capirla cambia il modo in cui studi, ti certifichi e poi lavori sul campo.
Scrum come metodo
Scrum traduce quei principi in strutture concrete: sprint, retrospettive, Daily Scrum, backlog, tre ruoli definiti. È un framework, non un processo generico. Secondo Atlassian, Scrum organizza il lavoro in sprint time-boxed con ruoli, artefatti e cerimonie progettati per la consegna iterativa di valore. E i numeri dicono che funziona: l’87% dei rispondenti a survey Agile-focused dichiara di usare Scrum, contro il 58% rilevato nel 14° report del 2021 (16th State of Agile Report, via Parabol).
Ma c’è un dato che trovo ancora più interessante. L’81% degli Scrum Master usa Scrum e Kanban insieme, secondo dati Scrum.org riportati da Parabol. Il che significa che nella pratica reale, Scrum raramente vive da solo. Si combina, si adatta, si ibrida. E chi si certifica senza capire questa realtà si trova poi a corto di strumenti.
Personalmente, tra i candidati che ho seguito in preparazione alla certificazione, quelli che avevano interiorizzato la distinzione tra Agile e Scrum prima ancora di aprire la Scrum Guide erano quelli che progredivano più in fretta. Non perché studiassero di più, ma perché capivano dove si inseriva ogni concetto.
Quando Scrum non è la scelta giusta
Scrum non è l’unico framework Agile. Anzi, a livello enterprise è sempre meno sufficiente da solo.
Kanban è pensato per flussi continui senza sprint. Extreme Programming (XP) privilegia pratiche ingegneristiche come il pair programming e il test-driven development. SAFe (Scaled Agile Framework) coordina Agile su larga scala, ed è per questo che il 53% delle aziende enterprise lo usa come framework principale, secondo il 16th State of Agile Report. Un dato in forte crescita rispetto al 37% del report precedente.
Quindi quando Scrum non è la scelta giusta? Quando il team è grande e distribuito su più unità, quando il lavoro non si presta a sprint fissi, quando l’organizzazione ha già adottato SAFe o un approccio ibrido. In quei contesti, conoscere solo Scrum non basta. Serve capire dove Scrum finisce e dove inizia qualcos’altro.
Tutto sommato, la domanda da porsi prima di scegliere una certificazione non è “Scrum o Agile?” ma “che tipo di lavoro voglio fare e in quale contesto?” La risposta orienta il percorso. E questo vale soprattutto se stai pensando a una certificazione come trampolino di carriera, non come esercizio teorico.
Come è strutturato un team Scrum: i tre ruoli ufficiali
Il team Scrum è composto da tre ruoli definiti: Product Owner, Scrum Master e Developers, ciascuno con responsabilità specifiche e non delegabili. Non è una gerarchia. Non ci sono capi, subordinati, o catene di comando tradizionali. Ogni ruolo ha un perimetro preciso, e invaderlo crea i problemi tipici che si vedono nei team che “fanno Scrum” senza averlo capito davvero.
La Scrum Guide 2020 fissa la dimensione ottimale del team tra le 3 e le 9 persone nel ruolo di Developer, più un Product Owner e uno Scrum Master. Sotto i tre Developer il lavoro scarseggia, sopra i nove le dipendenze esplodono. È una regola empirica, non un dogma, ma deriva da decenni di pratica sul campo.
Product Owner: ownership del valore
Il Product Owner gestisce il Product Backlog: ordina le voci per priorità, le affina, e si assicura che il team sappia sempre cosa costruire prima e perché. Non è un segretario delle richieste. È la persona che decide cosa ha valore e cosa può aspettare.
Nei progetti che ho seguito, la confusione più frequente è questa: il Product Owner trattato come una casella postale tra stakeholder e sviluppatori, un passacarte senza autorità reale. Ma la Scrum Guide è netta sul punto: il Product Owner è una persona sola, non un comitato, e le sue decisioni sul Backlog sono definitive. Se gli stakeholder vogliono cambiare le priorità, lo fanno parlando con il Product Owner, non scavalcandolo.
Questa ownership del valore non è una formalità. È il motivo per cui, secondo i dati di Scrum Alliance citati da Parabol, l’85% dei praticanti Scrum dichiara una migliore qualità della vita lavorativa: sapere chi decide cosa elimina ambiguità, riunioni inutili, blocchi.
Scrum Master: facilitatore del processo
Lo Scrum Master non è un project manager. Punto.
Non assegna task, non controlla l’avanzamento delle attività, non produce report per il management. Il suo lavoro è diverso, e spesso incompreso: rimuove gli impedimenti che rallentano il team, facilita gli eventi Scrum, aiuta l’organizzazione a capire Scrum e a smettere di sabotarlo inconsapevolmente. È un ruolo di servizio, non di controllo.
Anzi, la vera misura del buono Scrum Master è quanto riesce a rendersi superfluo nel tempo. Un team maturo ha bisogno di meno facilitazione esplicita perché ha interiorizzato i principi. Quello stesso team, però, nelle fasi iniziali può affidarsi allo Scrum Master come punto di riferimento sul processo ogni giorno.
Nella pratica, l’81% degli Scrum Master lavora combinando Scrum con Kanban, e il 54% lo integra con pratiche DevOps, stando ai dati di Scrum.org e Age of Product riportati da Parabol. Questo racconta molto: lo Scrum Master è una figura che conosce il processo in profondità, non qualcuno che si limita a moderare una riunione.
Developers: il team che costruisce l’incremento
I Developers, nel senso che Scrum dà al termine, non sono solo sviluppatori software. Sono tutte le persone che lavorano concretamente per produrre un incremento di prodotto finito e potenzialmente rilasciabile alla fine di ogni sprint. Potrebbero essere designer, tester, analisti, ingegneri. Il nome crea confusione, ma il concetto è semplice.
Il team di Developers si auto-organizza. Decide come svolgere il lavoro dello sprint senza che qualcuno dall’esterno gli dica come farlo. Questa autonomia è il meccanismo che genera qualità, non un privilegio concesso per gentilezza. Ed è uno dei motivi per cui i dati reggono: il 78% dei praticanti Scrum raccomanderebbe il framework a colleghi e professionisti, secondo i dati Scrum Alliance via Parabol. A conti fatti, quando un team sa perché fa quello che fa, e ha la libertà di farlo come ritiene giusto, i risultati si vedono.
Ma l’autonomia non è assenza di responsabilità. I Developers si impegnano su un obiettivo di sprint, e sono loro, collettivamente, a rispondere di quell’impegno. Non il singolo, non il manager. Il team.
Quali sono gli eventi Scrum e quanto durano nello sprint reale?
Gli eventi Scrum sono cinque attività time-boxed (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) che strutturano il ciclo di lavoro iterativo del team. Non sono riunioni opzionali da calendarizzare quando si trova spazio. Sono il ritmo del framework: saltarne anche solo una significa rompere il ciclo e perdere il principale meccanismo di controllo che rende Scrum diverso da un normale piano di progetto.
Nella pratica, gli sprint durano tra le 2 e le 4 settimane. Ma se lavori con un team che ha già qualche esperienza, la risposta più probabile è due settimane esatte. I dati Broadcom raccolti da Parabol lo confermano: il 59,1% dei team Scrum usa sprint di due settimane come durata predefinita. Non è un caso. Due settimane bastano per produrre qualcosa di concreto e abbastanza corte da accorgersi presto di un problema senza aspettare un mese.
Sprint Planning
Lo Sprint Planning apre ogni sprint. Il team seleziona gli elementi del Product Backlog su cui lavorare e costruisce lo Sprint Backlog, cioè il piano di lavoro per le prossime due settimane. La durata massima indicata dalla Scrum Guide è di otto ore per uno sprint di quattro settimane. Per uno sprint di due settimane si lavora normalmente su quattro ore al massimo, spesso meno.
In soldoni: più il team è maturo e conosce il backlog, più lo Sprint Planning dura poco. Ho seguito team che lo chiudevano in 90 minuti perché il Product Owner aveva già affinato le priorità durante la settimana. E altri che ci passavano una mattinata intera perché arrivavano con item vaghi e senza stime.
Daily Scrum
Il Daily Scrum è la cerimonia più nota e la più spesso storpiata. Quindici minuti, ogni giorno, stessa ora. Non è un report ai manager. È un momento in cui il team sincronizza il lavoro verso l’obiettivo dello sprint.
Secondo i dati Scrum Alliance citati da Parabol, l’87% dei team Scrum esegue il Daily Scrum regolarmente. Quel 13% che non lo fa, di solito ha un problema più grande del Daily Scrum in sé: spesso il team non ha un obiettivo condiviso e la riunione non avrebbe senso. Ma il Daily Scrum non è il problema, è il sintomo.
Quindici minuti. Non di più. Se emergono blocchi che richiedono discussione, si aggiorna un sotto-gruppo dopo, non in plenaria.
Sprint Review
Alla fine dello sprint, il team presenta il lavoro completato agli stakeholder. Non è una demo di prodotto nel senso teatrale del termine: è un momento di ispezione e adattamento del Product Backlog basato su feedback reale. La durata indicativa è quattro ore per uno sprint di quattro settimane, due ore per uno di due.
Ma c’è un dettaglio che spesso si trascura. La Sprint Review non è una cerimonia interna: servono gli stakeholder veri, quelli che poi usano o finanziano il prodotto. Un team che fa la Review con solo i suoi membri sta fondamentalmente parlando con se stesso.
Sprint Retrospective
La Retrospective è l’evento più sottovalutato. E anche il primo a essere tagliato quando il team è sotto pressione o lo sprint è andato male. Ecco il paradosso: viene saltata proprio quando sarebbe più utile.
Personalmente, negli anni in cui ho osservato team che si autodefinivano “agili”, il segnale più affidabile per capire se stavano facendo Scrum sul serio era uno solo: tengono la Retrospective anche quando lo sprint è andato storto? Se la risposta è no, quello che stanno facendo ha il nome di Scrum ma non la sostanza.
La Retrospective dura al massimo tre ore per uno sprint di quattro settimane, di solito 90 minuti per due settimane. Il focus è il processo, non il prodotto: cosa ha funzionato, cosa no, cosa cambia nello sprint successivo. È il motore del miglioramento continuo. Anzi, è l’unico motore istituzionalizzato che Scrum prevede per migliorare il modo in cui il team lavora insieme. Toglierla significa togliere la capacità di apprendimento collettivo dal framework.
Tutto sommato, i cinque eventi Scrum non sono burocrazia da subire. Sono il meccanismo con cui un team resta allineato, corregge la rotta e migliora sprint dopo sprint. Chi li esegue tutti, con disciplina e senso critico, sta facendo Scrum. Chi ne taglia qualcuno per “risparmiare tempo” sta costruendo debito di processo che prima o poi si paga.
Quando passare da un singolo team Scrum a Scrum of Scrums?
Scrum of Scrums è una tecnica di scaling Agile in cui rappresentanti di più team Scrum si incontrano regolarmente per coordinare dipendenze e impedimenti tra team. Non è un framework autonomo: è un meccanismo di raccordo, leggero per definizione, che funziona perché ogni team mantiene la propria autonomia e si limita a sincronizzare i punti di contatto con gli altri.
La domanda che sento più spesso da chi lavora con Scrum da qualche anno è sempre la stessa: “quando smette di bastare un solo team?”. La risposta, a mio avviso, è meno ovvia di quanto sembri.
Cos’è Scrum of Scrums
Il meccanismo è semplice. Ogni team Scrum designa un rappresentante, di solito lo Scrum Master o un membro tecnico senior, che partecipa a un meeting periodico di coordinamento con i rappresentanti degli altri team. In quel meeting non si gestisce il lavoro interno di nessun team: si identificano blocchi inter-team, dipendenze tecniche, rischi condivisi.
Il punto non è aggiungere burocrazia. È esattamente il contrario. Senza un momento di coordinamento strutturato, le dipendenze tra team si gestiscono via email, Slack, riunioni improvvisate a fine sprint. E a quel punto il coordinamento c’è lo stesso, ma nessuno lo vede e nessuno lo governa.
Nei progetti che ho seguito, i team che adottano Scrum of Scrums prima di aver raggiunto la soglia critica spesso lo abbandonano dopo pochi sprint: “troppa cerimonia, troppo poco valore”. Ha senso. Se i team lavorano su parti del prodotto quasi indipendenti, il coordinamento può avvenire in modo informale senza struttura aggiuntiva.
Soglia di team oltre cui scalare
Non esiste una regola scritta sulla pietra, ma la soglia pratica che si osserva è intorno a tre o quattro team Scrum che lavorano sullo stesso backlog di prodotto o su componenti fortemente interdipendenti. Con due team, spesso bastano una chat dedicata e una breve call settimanale. Con quattro o più, le dipendenze si moltiplicano in modo non lineare e il coordinamento informale diventa un collo di bottiglia reale.
I numeri degli ultimi report confermano che la pressione verso lo scaling è reale: il 28% dei rispondenti al 16° State of Agile Report dichiara di usare Scrum@Scale o Scrum of Scrums, contro il 9% dell’anno precedente (fonte: Parabol). Una crescita di tre volte in un anno non si spiega con la moda: si spiega con il fatto che molte organizzazioni hanno semplicemente raggiunto quella soglia e non potevano più ignorarla.
Ma attenzione. Scrum of Scrums non è l’unica risposta disponibile. Il 53% delle enterprise usa SAFe come framework di scaling, a conferma che le organizzazioni grandi tendono verso strutture più formali quando la complessità supera una certa massa critica. Scrum of Scrums rimane la soluzione giusta per contesti medi, con team che condividono un prodotto senza bisogno di un’architettura organizzativa elaborata.
Un altro segnale che vale la pena osservare: il 54% degli Scrum Master combina già Scrum con pratiche DevOps. Questo dato dice qualcosa di importante: i team maturi integrano e adattano. Quando le pratiche di un singolo team iniziano a creare attrito con le pratiche degli altri team sullo stesso prodotto, quella è la vera soglia. Non il numero di persone. Non il numero di sprint.
Quindi, in soldoni: scala verso Scrum of Scrums quando le dipendenze tra team cominciano a generare ritardi, blocchi o riunioni improvvisate che nessuno ha messo in agenda. Quel momento arriva quasi sempre prima di quanto si pensi. E aspettare di sentire il problema in modo acuto di solito significa già averlo gestito male per qualche sprint.
Quanto vale una certificazione Scrum nella carriera di un Project Manager?
Una certificazione Scrum è una credenziale formale, come il PSM I di Scrum.org o il CSM di Scrum Alliance, che attesta la conoscenza del framework e aumenta la credibilità professionale in ruoli Agile. Non è solo un titolo da aggiungere al profilo LinkedIn. È la differenza tra candidarsi a un ruolo Agile con un curriculum generico e presentarsi con qualcosa di verificabile, riconosciuto, spendibile.
I numeri del settore parlano chiaro. Le aziende che adottano Agile riportano un tasso di successo medio nei progetti del 75,4% (Businessmap, 2026). E il 39% dei team Agile dichiara di ottenere le migliori performance di progetto della propria storia (Businessmap, 2026). Sono dati che le direzioni HR leggono. E quando cercano un Project Manager, cercano qualcuno che quei risultati sappia produrli davvero.
PSM I di Scrum.org vs CSM di Scrum Alliance
Le due credenziali più riconosciute sul mercato sono il PSM I (Professional Scrum Master I) di Scrum.org e il CSM (Certified ScrumMaster) di Scrum Alliance. Hanno filosofie diverse. Vale la pena capirlo prima di scegliere.
Il PSM I si ottiene superando un esame online da 80 domande in 60 minuti, senza obbligo di corso preliminare. Scrum.org valuta la comprensione reale del framework, non la semplice partecipazione a una classe. Il CSM, invece, richiede un corso accreditato di due giorni con un trainer certificato prima di accedere all’esame. Due approcci opposti alla certificazione. Ma nessuno dei due è “più facile”: sono diversi.
A conti fatti, il PSM I tende ad avere più peso tecnico, soprattutto in contesti IT e di sviluppo software. Il CSM è diffusissimo nei team di marketing, operations e prodotto, anche fuori dal software. E qui c’è un dato che cambia la prospettiva: l’86% dei marketer pianifica di far passare i propri team a metodologie Agile entro il 2026 (Businessmap). Quindi il CSM non è affatto una certificazione di nicchia, tutt’altro.
Secondo il 16° State of Agile Report, l’87% dei professionisti che usano un framework Agile dichiara di usare Scrum. Su 100 colleghi che incontri in un contesto Agile, 87 lavorano con Scrum. Avere una certificazione che attesta questa conoscenza specifica non è un dettaglio.
Cosa cambia in busta paga dopo la certificazione
La domanda vera, alla fine della fiera, è questa: cambia qualcosa in busta paga? Sì. Ma non in modo automatico.
La certificazione apre porte che prima erano chiuse o richiedevano anni di esperienza dimostrata. Un Project Manager certificato Scrum può accedere a ruoli come Scrum Master, Agile Coach, Product Owner o Delivery Manager, posizioni che nei listini salariali italiani e internazionali superano sistematicamente i ruoli PM tradizionali. Non perché la certificazione valga oro di per sé, ma perché certifica una competenza che il mercato sta cercando attivamente.
Ma c’è un aspetto che spesso si trascura. L’aumento salariale non arriva solo cambiando azienda. Arriva anche internamente. Un PM che ottiene la certificazione mentre lavora in un’azienda che sta adottando Agile diventa una risorsa diversa, più preziosa, in un contesto in trasformazione. Ho visto candidati usare la certificazione come leva in una negoziazione di rinnovo contrattuale, con risultati concreti, non solo simbolici.
E i team certificati consegnano meglio. I dati di CA Technologies citati da Parabol mostrano che i team che applicano Scrum in modo completo hanno una qualità del prodotto superiore del 250% rispetto ai team che non stimano il lavoro. Quando porti questo tipo di risultato in azienda, la busta paga segue.
Percorso formativo strutturato vs studio autodidatta
Si può studiare Scrum da soli. La Scrum Guide è gratuita, scaricabile da Scrum.org, e in 13 pagine descrive l’intero framework. Però.
Però la guida descrive il “cosa”, non il “come” e soprattutto non il “perché in quel contesto specifico”. E l’esame PSM I non chiede di recitare la guida: chiede di ragionare su scenari complessi, conflitti tra ruoli, situazioni ambigue in cui la risposta giusta non è mai ovvia. Studiare da soli significa affrontare quell’ambiguità senza una mappa.
Un percorso formativo strutturato riduce i tempi di preparazione e, cosa forse più importante, riduce l’incertezza sul ROI. Chi studia con un metodo guidato sa cosa aspettarsi dall’esame, conosce i pattern delle domande, ha simulato scenari reali. Non arriva il giorno dell’esame sperando di aver coperto gli argomenti giusti.
Personalmente, tra i professionisti che ho visto prepararsi per il PSM I, quelli con un percorso strutturato arrivavano all’esame con una confidenza diversa. Non arroganza. Confidenza. Sapevano dove erano forti, sapevano dove dovevano ancora lavorare, e avevano già sbagliato gli errori tipici durante le simulazioni, non il giorno dell’esame.
Ma c’è un punto pratico che non va ignorato. Il 78% degli utilizzatori di Scrum raccomanda il framework a colleghi e professionisti (Scrum Alliance, via Parabol). Questo non accade perché Scrum è semplice da capire: accade perché, quando viene applicato bene, funziona. E applicarlo bene richiede una formazione che vada oltre la lettura autonoma di una guida.
Domande frequenti su Scrum
Questa sezione raccoglie le domande più frequenti su Scrum poste da Project Manager e Product Manager che valutano l’adozione del framework o una certificazione. Le risposte si basano su dati verificati e fonti autorevoli, così puoi citarle o condividerle direttamente.
Scrum è adatto solo allo sviluppo software?
No. Scrum nasce nello sviluppo software, ma oggi si applica a marketing, finanza, risorse umane e operations. Il dato più eloquente: il 86% dei marketer prevede di adottare metodologie Agile (Businessmap, 2026). E i team engineering restano la quota più numerosa, con il 48% dei praticanti Agile in ambito R&D, cresciuta del 16% dal 2022. In soldoni, Scrum funziona ovunque ci sia un deliverable iterabile e un cliente che può dare feedback prima della versione finale.
Quanto dura davvero uno sprint Scrum?
La Scrum Guide fissa il limite massimo a quattro settimane, ma nella pratica la durata più comune è due settimane. Secondo i dati Broadcom raccolti da Parabol, il 59,1% dei team Scrum usa sprint da due settimane come durata predefinita.
Perché due settimane? È il punto di equilibrio tra cicli abbastanza brevi da permettere correzioni rapide e abbastanza lunghi da produrre un incremento reale. Sprint di una settimana funzionano bene per team maturi con backlog molto definito. Quelli da quattro settimane si vedono quasi solo in contesti regolamentati, dove ogni rilascio richiede validazioni esterne. Ma a mio avviso, se stai iniziando, parti da due settimane e basta: aggiustare dopo è più facile che indovinare al primo colpo.
Posso usare Scrum e Kanban insieme?
Sì, ed è già la norma. L’81% degli Scrum Master usa Scrum e Kanban in parallelo (Scrum.org, via Parabol). La combinazione prende il nome di Scrumban. Scrum struttura le iterazioni con sprint e cerimonie fisse; Kanban aggiunge visibilità continua sul flusso di lavoro tramite board e limiti di WIP. I due approcci non si escludono: si integrano.
Ma attenzione. Mescolare framework senza consapevolezza produce confusione, non flessibilità. Prima di adottare Scrumban è utile padroneggiare i due framework separatamente, capire cosa manca in ognuno, poi scegliere quali elementi combinare.
Quale certificazione Scrum scegliere nel 2026?
Dipende dal ruolo che ricopri o che vuoi ricoprire. Per chi lavora come Scrum Master, le certificazioni PSM (Professional Scrum Master) di Scrum.org e CSM (Certified ScrumMaster) di Scrum Alliance sono le referenze più riconosciute a livello internazionale. Per i Product Owner esistono PSPO e CSPO, con la stessa logica. Il 78% dei praticanti Scrum consiglierebbe il framework a colleghi e professionisti (Scrum Alliance, via Parabol): un Net Promoter Score che pochi standard di settore raggiungono, e che indica quanto la comunità sia attiva e le certificazioni effettivamente spendibili.
Quindi, se sei un PM generalista che vuole capire Scrum prima di certificarsi in un ruolo specifico, parti dalla PSM I: è accessibile, ha materiale di preparazione ufficiale su Scrum.org e richiede un esame pratico basato sulla Scrum Guide, non su nozioni accademiche.
Scrum sostituisce il Project Manager tradizionale?
Scrum non prevede la figura del Project Manager tra i suoi tre ruoli ufficiali (Product Owner, Scrum Master, Developers). Però non la elimina: la redistribuisce.
Nei team che adottano Scrum in modo completo, le responsabilità tipiche del PM tradizionale si dividono tra Product Owner (priorità, visione, ROI) e Scrum Master (facilitazione, ostacoli, processo). Nei contesti ibridi o enterprise, molti Project Manager diventano Scrum Master o Program Manager Agile senza dismettere la loro esperienza di pianificazione. Nei progetti che usano SAFe, il framework di scaling più diffuso con il 53% di adozione tra le grandi organizzazioni (16th State of Agile Report), ruoli come Release Train Engineer e Product Manager recuperano funzioni tipicamente manageriali.
Anzi, tra i candidati che ho seguito negli ultimi anni, quelli con un background da PM tradizionale spesso diventano Scrum Master più efficaci degli sviluppatori promossi al ruolo: portano abitudine al rischio, alla comunicazione con gli stakeholder e alla gestione delle aspettative. Quello che manca lo si impara. Quello che si porta è più difficile da costruire da zero.
