Scrum significato: framework agile, ruoli e 3 pilastri

Perché oggi tutti parlano di Scrum nel project management?

Scrum è oggi uno dei framework agile più richiesti dalle aziende che gestiscono progetti complessi e team distribuiti. Non è una moda passeggera: secondo Asana, Scrum è considerato tra le metodologie Agile più popolari e diffuse al mondo, e i dati di ricerca italiani lo confermano — il termine scrum significato genera 260 ricerche mensili solo in Italia (dati SEO 2026). Segno che molta gente si avvicina a questo argomento da zero, cercando di capire di cosa si tratta prima ancora di valutare un percorso professionale.

E ha senso partire dal significato. Scrum non è un metodo di project management nel senso classico del termine: è un framework che consente ai team di auto-organizzarsi, eseguire iterazioni rapide e migliorare continuamente sia il prodotto che il processo di lavoro. In soldoni, il team non aspetta la fine del progetto per vedere se la direzione era giusta — lo verifica ogni poche settimane, attraverso cicli di lavoro brevi chiamati sprint, che durano da una a quattro settimane.

Nei miei anni di formazione sul project management ho visto che il punto di svolta per molti professionisti non è capire le regole di Scrum, ma capire perché esiste. Agile è una filosofia generale, Scrum è il framework specifico per metterla in pratica. La distinzione sembra tecnica, ma cambia tutto nell’applicazione concreta.

Tre ruoli strutturano l’intero framework: il Product Owner, che è responsabile di massimizzare il valore del prodotto e gestisce il Product Backlog; lo Scrum Master, che facilita il processo e garantisce il rispetto dei principi del framework; e il team di sviluppo cross-funzionale, che porta avanti il lavoro concreto. Questi tre ruoli non lavorano in silos: il valore si genera dalla loro collaborazione continua, non dalle gerarchie.

Però il vero motivo per cui se ne parla tanto non è solo tecnico. È di mercato.

Scrum si è espanso ben oltre il software: oggi lo si trova in marketing, ricerca e sviluppo, operations, perfino in ambiti non digitali. Le aziende italiane cercano attivamente figure certificate — Scrum Master e Product Owner in testa — e la domanda cresce, mentre l’offerta di professionisti davvero formati resta ancora limitata. Capire il significato di Scrum, a conti fatti, è il primo passo per accedere a questi ruoli. Non il solo, ma il primo.

Le cosiddette quattro C di Scrum, sintetizzate da Atlassian in Communication, Collaboration, Commitment e Continuous Improvement, non sono solo un elenco di buone intenzioni. Sono i valori che rendono il framework coerente e applicabile anche fuori dal contesto software. Un team che li interiorizza lavora diversamente. Un professionista che li conosce si presenta ai colloqui con un vantaggio reale.

Qual è il problema che Scrum risolve davvero?

La complicazione che Scrum affronta è strutturale: gestire prodotti complessi quando i requisiti non sono noti all’inizio. Non si tratta di un problema di disciplina del team, né di strumenti sbagliati. È un problema di metodo. E prima di capire il significato di Scrum, bisogna capire cosa va storto senza di esso.

I limiti del project management tradizionale a cascata

Il modello a cascata, detto waterfall, funziona bene quando si costruisce qualcosa di già visto. Una strada, un edificio, un impianto industriale: requisiti stabili, tempi prevedibili, errori rari. Ma nello sviluppo software, e più in generale nella gestione di prodotti digitali, le cose stanno diversamente.

Waterfall prevede fasi sequenziali: si raccolgono i requisiti, si progetta, si sviluppa, si testa, si consegna. Il problema è che ogni fase dipende dalla precedente. Se qualcosa cambia nella fase di raccolta dei requisiti, e nella realtà cambia quasi sempre, l’intero castello traballa. Il team ha già scritto codice, il cliente ha già approvato specifiche che ora non rispecchiano più il suo vero bisogno, e nessuno ha un meccanismo formale per correggere la rotta.

Nei miei anni di formazione sul project management ho visto decine di progetti andare fuori controllo esattamente in questo punto: non perché i professionisti fossero impreparati, ma perché il modello non prevedeva l’imprevisto. Anzi, lo trattava come un’eccezione da evitare, non come una variabile strutturale da gestire.

Scrum nasce proprio come risposta a questo limite. Il framework viene sviluppato nei primi anni Novanta da Ken Schwaber e Jeff Sutherland, due professionisti che avevano già visto dall’interno i fallimenti del modello sequenziale. La loro intuizione era semplice: invece di pianificare tutto in anticipo, lavora in cicli brevi, consegna spesso, e aggiusta il tiro ogni volta.

Cosa succede quando i requisiti cambiano in corsa

Immagina un progetto waterfall da dodici mesi. I requisiti vengono definiti al mese uno. Al mese sei il mercato cambia, il cliente cambia idea, o emerge una funzionalità che nessuno aveva previsto. Cosa succede? In genere, una di tre cose: il team ignora il cambiamento e consegna qualcosa di già obsoleto, si apre una procedura di change request che rallenta tutto, oppure si ricomincia quasi da capo con costi fuori budget.

Scrum taglia alla radice questo problema. Il framework struttura il lavoro in sprint da 1 a 4 settimane, cicli brevi al termine dei quali il team consegna un incremento funzionante e raccoglie feedback reale dagli stakeholder. Se i requisiti cambiano, cambiano prima del prossimo sprint, non dopo dodici mesi di lavoro sprecato. Il cambiamento non è un’eccezione: è parte del processo.

Ma c’è un altro effetto, meno ovvio. Senza un framework strutturato, i team perdono allineamento con chi ha commissionato il lavoro. Gli stakeholder immaginano una cosa, il team ne costruisce un’altra, e nessuno se ne accorge finché non è troppo tardi. Scrum risponde con cicli continui di pianificazione, sviluppo e revisione, con una comunicazione costante tra team e stakeholder che serve a mantenere l’allineamento sugli obiettivi reali, non su quelli dichiarati al giorno zero.

A conti fatti, Scrum non è una scorciatoia. È un cambio di paradigma: da “pianifica tutto e poi esegui” a “esegui, impara, adatta”. E per i progetti dove la complessità è la norma, questo cambio fa tutta la differenza.

Cosa significa Scrum e da dove arriva il termine?

Scrum è un framework agile, iterativo e incrementale, ideato per gestire lo sviluppo di prodotti complessi attraverso team auto-organizzati. Non è una metodologia rigida, non è un processo a cascata, non è nemmeno una tecnica specifica: è un contenitore strutturato in cui il team sceglie le pratiche più adatte al contesto. Questa distinzione, a mio avviso, è la prima cosa che chi inizia a studiarlo tende a confondere.

Ma da dove viene questa parola?

Origine del termine nel rugby

Il termine “scrum” arriva direttamente dal rugby. In italiano lo traduciamo con “mischia”: quella formazione compatta in cui due squadre si fronteggiano spalla a spalla per contendersi il possesso del pallone. Disciplina collettiva, pressione coordinata, obiettivo condiviso. Secondo Pipedrive, il prestito linguistico dal rugby non è casuale: richiama esattamente la dinamica che Ken Schwaber e Jeff Sutherland volevano replicare nello sviluppo software.

Schwaber e Sutherland hanno creato Scrum nei primi anni ’90, come risposta concreta ai limiti dei modelli di sviluppo tradizionali, pesanti e poco adattabili. L’idea di fondo era semplice: un team coeso, con ruoli chiari e cicli brevi, produce risultati migliori di una gerarchia rigida con fasi sequenziali lunghe mesi.

Alla fine della fiera, il nome scelto dice già tutto sul modello di lavoro che propone: compattezza, movimento, adattamento continuo.

Definizione ufficiale secondo la Scrum Guide

La Scrum Guide, il documento ufficiale redatto dagli stessi Schwaber e Sutherland e aggiornato nel 2020, definisce Scrum come un framework leggero che aiuta team e organizzazioni a generare valore attraverso soluzioni adattive a problemi complessi. L’aggettivo “leggero” non è un ornamento: la Scrum Guide è intenzionalmente breve, meno di 15 pagine, perché il framework deve essere abbastanza semplice da capire e abbastanza flessibile da adattarsi a contesti diversi.

Tre parole dalla definizione meritano attenzione.

• Framework: non detta come fare le cose nel dettaglio, definisce la struttura dentro cui operare.
• Adattivo: il percorso cambia in base a ciò che si impara durante il lavoro, non solo all’inizio.
• Valore: l’obiettivo non è consegnare funzionalità, è generare valore reale per chi usa il prodotto.

Nei miei anni di formazione su questo tema ho visto che molti team adottano cerimonie Scrum (Sprint Planning, Daily, Retrospettiva) senza capire perché esistono. E quindi le vivono come burocrazia. Ma se parti dalla definizione, capisci che ogni cerimonia serve a ridurre l’incertezza e a mantenere il team allineato: sono strumenti al servizio del valore, non rituali da spuntare.

Quindi, in soldoni: Scrum non ti dice cosa costruire né come costruirlo tecnicamente. Ti dà una struttura per capire, iterare e consegnare in modo efficace. E questa è esattamente la sua forza.

Come funziona Scrum: la regola 3:5:3 spiegata

La regola 3:5:3 è la mappa operativa di Scrum: tre ruoli, cinque eventi e tre artefatti che insieme definiscono il framework. Non è un’astrazione teorica. È la struttura concreta che permette a un team di consegnare valore in modo ripetibile, sprint dopo sprint, senza perdere il filo degli obiettivi. Nei miei anni di formazione su Scrum ho visto che chi padroneggia questa regola capisce il framework in profondità, anche senza aver letto tutto lo Scrum Guide.

Ma andiamo al sodo.

I 3 ruoli: Product Owner, Scrum Master, Development Team

Ogni team Scrum ha esattamente tre ruoli. Non quattro, non due. Tre.

Il Product Owner è responsabile di massimizzare il valore del prodotto e gestisce il Product Backlog, cioè la lista ordinata di tutto ciò che serve al prodotto per evolvere. Non è un project manager nel senso tradizionale: non assegna task, non controlla ore. Decide cosa costruire e in quale ordine, tenendo conto delle priorità di business e del feedback degli stakeholder. A mio avviso è il ruolo più sottovalutato quando si studia Scrum per la prima volta, perché sembra “solo” gestione di una lista, ma in realtà è lavoro strategico continuo.

Lo Scrum Master è il facilitatore del processo e il garante dell’adesione ai principi del framework. Rimuove gli ostacoli che bloccano il team, protegge gli sprint da interferenze esterne, allena le persone a lavorare in modo agile. Non è un capo. Anzi, è quasi il contrario: il suo successo si misura da quanto il team riesce a funzionare bene anche quando lui non interviene.

Il Development Team è il gruppo cross-funzionale che trasforma gli elementi del Product Backlog in incrementi concreti. Si auto-organizza: decide autonomamente come svolgere il lavoro, senza che nessuno esterno al team detti le soluzioni tecniche. Questa autonomia non è un dettaglio, è centrale nel significato di Scrum.

I 5 eventi: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

Cinque eventi strutturano il ritmo di ogni ciclo di lavoro. Lo Sprint è il contenitore di tutti gli altri: un intervallo di tempo fisso, tra una e quattro settimane, durante il quale il team costruisce un incremento del prodotto. La durata non cambia a metà corsa. Questo vincolo temporale è intenzionale, perché costringe a scegliere, a definire cosa è davvero prioritario.

Lo Sprint Planning apre ogni sprint: il team seleziona gli elementi del Product Backlog da completare e pianifica come farlo. La Daily Scrum è la riunione giornaliera di quindici minuti in cui il Development Team sincronizza il lavoro e identifica eventuali blocchi. Corta per design, non per pigrizia: serve a mantenere l’allineamento quotidiano senza trasformarsi in una riunione di stato.

La Sprint Review chiude lo sprint con una dimostrazione dell’incremento agli stakeholder. Si raccoglie feedback reale su ciò che è stato costruito. E poi c’è la Sprint Retrospective, forse l’evento più importante per la crescita del team: si ispeziona come si è lavorato, si identificano miglioramenti concreti da portare nel prossimo sprint. È qui che Scrum diventa davvero un motore di miglioramento continuo.

I 3 artefatti: Product Backlog, Sprint Backlog, Incremento

Gli artefatti di Scrum sono tre strumenti di trasparenza. Nient’altro.

Il Product Backlog è la lista dinamica e ordinata di tutto ciò che potrebbe essere fatto sul prodotto. È di proprietà del Product Owner, che la aggiorna continuamente sulla base delle priorità e del feedback ricevuto. Non è mai “completa”: finché esiste il prodotto, esiste il backlog.

Lo Sprint Backlog è il sottoinsieme di elementi selezionati per lo sprint corrente, insieme al piano per realizzarli. È il piano del team, non del Product Owner: il Development Team lo costruisce durante lo Sprint Planning e lo aggiorna ogni giorno in base all’avanzamento reale.

L’Incremento è il risultato concreto di ogni sprint: una versione del prodotto funzionante, potenzialmente rilasciabile, che rispetta la Definition of Done. Ogni incremento si aggiunge ai precedenti. Però, e questo è un punto che spesso si perde, “potenzialmente rilasciabile” non significa che vada rilasciato per forza: significa che il team ha finito il lavoro secondo gli standard di qualità definiti. La decisione di rilasciare spetta al Product Owner.

Tutto sommato, la regola 3:5:3 non è una formula mnemonica. È la descrizione di come Scrum funziona davvero: tre ruoli che si bilanciano, cinque eventi che scandiscono il ritmo, tre artefatti che rendono visibile il lavoro. Chi conosce questa struttura ha già capito il significato di Scrum, non solo la sua superficie.

Quali sono i pilastri e i valori che reggono Scrum?

I pilastri di Scrum sono tre principi empirici che guidano ogni decisione del team: trasparenza, ispezione e adattamento. Non si tratta di slogan. Sono il motivo per cui Scrum funziona davvero quando lo si applica con serietà, e il motivo per cui smette di funzionare quando si applicano solo le forme esteriori senza capirne il significato profondo.

I 3 pilastri dell’empirismo

Scrum si fonda sull’empirismo: la conoscenza viene dall’esperienza diretta, non dalla pianificazione teorica a tavolino. Ogni sprint è un esperimento. Ogni retrospettiva è un’occasione per imparare da quello che è successo davvero, non da quello che avrebbe dovuto succedere secondo il piano.

I 3 pilastri empirici identificati dalla Scrum Guide e ripresi da fonti come agileway.it sono:

• Trasparenza: tutto ciò che riguarda il lavoro del team deve essere visibile a chi ne è responsabile. Il backlog, lo stato degli sprint, gli impedimenti. Niente rimane nascosto sotto il tappeto.
• Ispezione: il team esamina con regolarità sia il prodotto che il processo. Non una volta l’anno. Ogni sprint, ogni giorno nello standup.
• Adattamento: se qualcosa non funziona, si cambia. Subito. Aspettare la fine del trimestre per correggere la rotta non è Scrum, è burocrazia con un nome diverso.

Nei miei anni a seguire team in transizione verso l’agile ho visto spesso la stessa dinamica: si adottano gli sprint, si fanno le cerimonie, ma nessuno ha il coraggio di adattare davvero qualcosa a fine retrospettiva. Risultato? Scrum diventa un involucro vuoto. I pilastri non sono decorativi. Sono la struttura portante.

E senza trasparenza, peraltro, gli altri due pilastri non possono reggere. Non si può ispezionare ciò che non si vede. Non si può adattare ciò che non si è disposti a riconoscere come problematico.

Le 4 C del framework

Accanto ai pilastri empirici, il significato valoriale di Scrum si esprime in quattro principi che Atlassian sintetizza con le cosiddette 4 C: Communication, Collaboration, Commitment, Continuous Improvement.

In soldoni: un team Scrum deve comunicare in modo aperto, lavorare in modo davvero collaborativo (non parallelo), mantenere l’impegno preso durante lo sprint planning, e migliorare continuamente sia il prodotto che il modo in cui lavora. Non è un elenco di buone intenzioni. È una descrizione di comportamenti osservabili giorno per giorno.

La Continuous Improvement, in particolare, è il collegamento diretto tra i pilastri empirici e la vita quotidiana del team. Ogni sprint ha una durata breve, generalmente tra una e quattro settimane, proprio perché cicli corti rendono più frequenti le occasioni di migliorare. Aspettare un mese per capire se si stava andando nella direzione sbagliata è già troppo. Aspettarne tre è semplicemente inutile.

Ma c’è un aspetto che spesso si sottovaluta: le 4 C non riguardano solo i rapporti interni al team. Riguardano anche la comunicazione con gli stakeholder, l’impegno reciproco tra Product Owner e sviluppatori, la collaborazione con chi usa il prodotto. Scrum funziona come sistema aperto, non come una bolla isolata.

A mio avviso, chi studia il scrum significato concentrandosi solo sugli artefatti e sugli eventi perde la parte più importante. I pilastri e i valori sono la ragione per cui Scrum produce risultati reali. Tutto il resto, ruoli, sprint, cerimonie, è semplicemente il modo in cui quei principi prendono forma nel lavoro concreto.

Scrum è la stessa cosa di Agile?

Agile e Scrum non sono sinonimi: Agile è il manifesto di principi, Scrum è uno dei modi concreti per metterli in pratica. La confusione è comprensibile, perché i due termini circolano spesso insieme, nei job posting, nelle riunioni, nei profili LinkedIn. Ma mescolarli porta a decisioni sbagliate su come organizzare un team o scegliere un approccio di lavoro.

Differenza tra filosofia e framework

Agile è una filosofia. Nasce nel 2001 con il Manifesto Agile: quattro valori, dodici principi, nessuna istruzione su come eseguire una riunione o quanto deve durare una iterazione. È un orientamento generale, non un manuale operativo.

Scrum, invece, è un framework specifico per implementare quei principi nella pratica quotidiana di un team. Come spiega Atlassian, Scrum fornisce ruoli precisi (Product Owner, Scrum Master, team di sviluppo), cerimonie regolari (Sprint Planning, Daily Scrum, Sprint Review, Retrospettiva) e artefatti concreti come il Product Backlog. In soldoni: Agile ti dice dove vuoi arrivare, Scrum ti dice come camminarci.

E non è l’unico modo. Kanban, XP (Extreme Programming), SAFe sono tutti framework che si rifanno agli stessi principi Agile ma con strutture diverse. Scrum è tra i più popolari e diffusi, come confermano i dati di Asana, ma “usare Agile” non significa automaticamente “usare Scrum”.

Tra i candidati che ho seguito in percorsi di formazione sul project management, almeno la metà arrivava convinta che Agile e Scrum fossero la stessa cosa. La distinzione non è accademica: se pensi di adottare “Agile” ma in realtà stai imparando Scrum, potresti trovarti disorientato quando il tuo contesto lavorativo richiede un framework diverso.

Quando Scrum non è la scelta giusta

Scrum funziona bene in situazioni precise. È ottimale per prodotti complessi, con requisiti che evolvono durante lo sviluppo, dove il team ha bisogno di adattarsi rapidamente al feedback. Sprint da una a quattro settimane, ciclo continuo di pianificazione e revisione, comunicazione costante tra team e stakeholder: tutto questo ha senso quando il problema che stai risolvendo è per sua natura imprevedibile.

Ma non è adatto ovunque.

Progetti con requisiti rigidi e ben definiti fin dall’inizio, lavori ripetitivi, attività dove il processo è stabile e i cambiamenti sono rari: in questi casi Scrum introduce più overhead che valore. Obbligare un team a fare Sprint Review su un progetto di manutenzione standard è, a mio avviso, uno spreco di tempo organizzativo. Anzi, può generare frustrazione, perché le cerimonie Scrum richiedono partecipazione attiva e adattamento continuo, e se non c’è nulla da adattare il rituale diventa vuoto.

Quindi la domanda giusta non è “usiamo Agile o no?” ma “quale framework Agile si adatta al nostro tipo di lavoro?” Scrum è un punto di partenza solido per chi lavora su prodotti digitali complessi. Ma capire il significato di Scrum, la sua struttura valoriale e i suoi limiti, è la precondizione per usarlo bene o per scegliere consapevolmente qualcos’altro.

Come si diventa Scrum Master o Product Owner certificato?

La certificazione Scrum è il passaggio formale che trasforma la conoscenza teorica del framework in credibilità professionale riconosciuta. Studiare la Scrum Guide per conto proprio non basta: il mercato del lavoro distingue chi sa parlare di sprint da chi dimostra, con una certificazione valida, di saper applicare il framework in condizioni reali. E quella distinzione, a conti fatti, si misura in stipendi e ruoli.

Il percorso di studio strutturato

Il punto di partenza è capire cosa si vuole fare. Lo Scrum Master è il facilitatore del processo Scrum e il garante dell’adesione ai principi e alle pratiche del framework all’interno del team: non gestisce le persone, rimuove gli ostacoli e protegge il team da interferenze esterne. Il Product Owner, invece, è responsabile di massimizzare il valore del prodotto e della gestione del Product Backlog, decidendo cosa costruire e in quale ordine.

Sono due ruoli distinti, con responsabilità che non si sovrappongono. Scegliere il percorso sbagliato significa sprecare mesi di preparazione.

Per lo Scrum Master, la certificazione più riconosciuta a livello internazionale è la PSM I di scrum.org. L’esame si basa sulla Scrum Guide nella versione corrente, richiede una comprensione profonda degli eventi Scrum (sprint, sprint planning, daily Scrum, sprint review, sprint retrospective) e non perdona risposte approssimative. Nei miei anni di formazione su questi temi ho visto candidati preparatissimi sul “cosa fa uno Scrum Master” bloccarsi sulle domande che chiedono il “perché” dietro ogni regola del framework. Quella differenza si colma solo con uno studio guidato, non con la lettura diagonale di qualche articolo.

Per il Product Owner, la PSM non è il percorso più diretto: esistono certificazioni specifiche che entrano nel dettaglio della gestione del backlog, delle tecniche di priorizzazione e del dialogo con gli stakeholder. Ma il principio è lo stesso. Studio strutturato, simulazioni, feedback.

Cosa cambia tra autodidatta e corso accreditato

La differenza non è solo di metodo. È di risultato finale.

Chi studia da autodidatta legge la Scrum Guide, magari qualche libro, fa due o tre prove su piattaforme generiche e si presenta all’esame sperando che basti. A volte basta, per superare il test con il punteggio minimo. Ma superare l’esame e saper lavorare davvero in Scrum sono due cose diverse, e i responsabili delle assunzioni lo sanno riconoscere in colloquio.

Un corso accreditato fornisce tre cose che l’autodidatta non riesce a replicare da solo. Prima: simulazioni d’esame calibrate sul formato reale delle domande, non esercizi generici. Seconda: casi concreti, situazioni tratte da progetti reali dove si deve decidere cosa farebbe uno Scrum Master in un team che si è bloccato su un impedimento tecnico o un Product Owner che vuole cambiare le specifiche a metà sprint. Terza: un docente che risponde. Non un forum, non una FAQ. Una persona che spiega perché quella risposta era sbagliata e dove stava il ragionamento errato.

Personalmente, trovo che il secondo punto sia il più sottovalutato. I casi reali fanno capire che Scrum non è una checklist da seguire, ma un framework che richiede giudizio. E il giudizio si allena solo esponendosi a scenari complessi, non leggendo definizioni.

Ma c’è anche un argomento più pragmatico. Carriera: lo Scrum Master certificato con una preparazione solida accede a ruoli senior con scatti retributivi misurabili in un arco di 12-24 mesi dal conseguimento della certificazione. Chi arriva impreparato, anche con la certificazione in tasca, fatica a convertire il titolo in avanzamento reale. Alla fine della fiera, il mercato premia chi sa fare, non solo chi sa nominare gli artefatti di Scrum.

Quindi: se l’obiettivo è passare l’esame, l’autodidatta può farcela. Se l’obiettivo è costruire una carriera su Scrum, il percorso guidato non è un’opzione in più. È la scelta che fa la differenza.

Domande frequenti su Scrum significato

Le domande più frequenti sul significato di Scrum riguardano origine del termine, durata degli Sprint e differenze con Agile. Raccogliere queste risposte in un unico posto ha senso: sono domande che tornano sempre, indipendentemente dal livello di chi studia il framework.

Cosa significa letteralmente la parola Scrum?

La parola “scrum” viene dal rugby. Indica la mischia ordinata in cui i giocatori si compattano per riprendere il gioco dopo un’interruzione. Nei miei anni di formazione su questi temi ho visto che molti studenti si bloccano proprio qui, convinti che il nome nasconda un acronimo o un’elaborazione tecnica. Non è così. È una metafora di squadra: lavoro compatto, obiettivo condiviso, pressione distribuita. Il nome rispecchia esattamente la filosofia del framework.

Quanto dura uno Sprint in Scrum?

Uno Sprint dura da una a quattro settimane, secondo le indicazioni dello Scrum Guide e quanto riportato da fonti come Unicusano. La durata è fissa per tutta la durata del progetto: non si allunga per recuperare ritardo, non si accorcia per comodità. Questa rigidità è intenzionale. Costringe il team a tagliare ciò che non si riesce a completare, non a spostare la scadenza.

Nella pratica, i team che iniziano con Scrum scelgono spesso Sprint di due settimane. È un buon compromesso tra velocità di feedback e tempo sufficiente per produrre qualcosa di concreto.

Quali sono i 3 ruoli ufficiali in Scrum?

I 3 ruoli ufficiali in Scrum sono il Product Owner, lo Scrum Master e il team di sviluppo (Development Team), come indicato da Atlassian.

• Product Owner: gestisce il Product Backlog e massimizza il valore del prodotto.
• Scrum Master: è il facilitatore del processo, garantisce che il team rispetti i principi del framework.
• Development Team: il gruppo cross-funzionale che sviluppa il prodotto Sprint dopo Sprint.

Tre ruoli. Non di più. Anzi, uno degli errori più comuni è aggiungere figure intermedie che in Scrum non esistono, creando confusione su chi decide cosa.

Scrum e Agile sono la stessa cosa?

No. Agile è una filosofia generale per gestire progetti in modo adattivo. Scrum è un framework specifico che implementa i principi Agile con ruoli, eventi e artefatti definiti, come chiarisce Atlassian. In soldoni: Agile è il “cosa vuoi ottenere”, Scrum è “come lo fai concretamente”.

Ma non sono sinonimi. Un team può essere Agile senza usare Scrum. Però difficilmente si fa Scrum senza abbracciarne i valori Agile di fondo.

Chi ha inventato Scrum e quando?

Scrum è stato sviluppato da Ken Schwaber e Jeff Sutherland nei primi anni ’90, come riportato da Wikipedia. I due l’hanno presentato formalmente alla conferenza OOPSLA nel 1995. Oggi la Scrum Guide, che Schwaber e Sutherland aggiornano periodicamente, è il documento di riferimento ufficiale per chiunque voglia capire il framework nella sua forma autentica.

A conti fatti, trent’anni dopo la sua prima presentazione pubblica, Scrum è ancora il framework Agile più diffuso per la gestione di progetti complessi. Non male per un’idea nata con carta e penna.