Cos’è Scrum: la definizione che conta davvero
Se lavori (o vuoi lavorare) come digital project manager, prima o poi qualcuno ti chiederà di “fare Scrum”. Conviene allora partire da una domanda onesta: cos’è Scrum, al netto degli slogan da conferenza? Scrum è un framework Agile leggero per gestire il lavoro complesso, soprattutto lo sviluppo di prodotti, attraverso cicli brevi e iterativi. Non è una metodologia rigida con cento procedure, e non è nemmeno una semplice lista di riunioni: è un’impalcatura minima che un team riempie con le proprie pratiche.
Il cuore di Scrum è l’empirismo. Invece di pianificare tutto in anticipo e sperare che la realtà collabori, il team avanza per piccoli passi, osserva cosa succede e corregge la rotta. Questo approccio si regge su tre pilastri.
- Trasparenza: chi lavora e chi decide vedono le stesse cose. Backlog, avanzamento e definizione di “fatto” sono visibili a tutti, senza zone d’ombra.
- Ispezione: a intervalli regolari si guarda il lavoro e il modo di lavorare, per accorgersi presto di scostamenti e problemi.
- Adattamento: quando l’ispezione rivela che qualcosa non funziona, si cambia. Subito, non al prossimo trimestre.
Tieni a mente questi tre pilastri: ogni evento e ogni artefatto di Scrum esiste per renderli concreti. Se una pratica non serve a trasparenza, ispezione o adattamento, probabilmente è cerimonia inutile.
Lo schema 3-5-3: la struttura di Scrum in un colpo d’occhio
Chi studia Scrum impara presto la formula 3-5-3. È il modo più rapido per ricordare di cosa è fatto il framework: 3 accountability (i ruoli), 5 eventi, 3 artefatti. Niente di più. Tutto ciò che si aggiunge oltre questo nucleo è una scelta del team, non un obbligo di Scrum.
- 3 accountability: Product Owner, Scrum Master, Developers.
- 5 eventi: lo Sprint che li contiene tutti, più Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
- 3 artefatti: Product Backlog, Sprint Backlog, Increment, ognuno con il suo commitment associato.
Vediamoli uno per uno, con esempi e tabelle, così da capire non solo cosa sono ma anche dove i team sbagliano.
I 3 ruoli (accountability) dello Scrum Team
Scrum non parla più di “ruoli” in senso gerarchico ma di accountability: responsabilità chiare, dentro un unico team senza sotto-team né capi. Lo Scrum Team è tipicamente piccolo, dieci persone o meno, ed è multifunzionale: contiene tutte le competenze per consegnare valore.
Product Owner
È la persona responsabile di massimizzare il valore del prodotto. Decide cosa va fatto e in che ordine, traduce le esigenze degli stakeholder in elementi del Product Backlog e dice il difficile “no” alle richieste che non valgono lo sforzo. Una sola persona, non un comitato.
Scrum Master
È responsabile dell’efficacia dello Scrum Team. Aiuta tutti a capire e applicare Scrum, rimuove gli impedimenti, protegge il team dalle interruzioni e fa da coach sui comportamenti agili. Non è il capo del team e non assegna i compiti: serve il team, non lo comanda.
Developers
Sono le persone che costruiscono l’Increment: sviluppatori, ma anche designer, tester, chiunque contribuisca al prodotto. Si auto-organizzano, decidono come trasformare gli elementi del Sprint Backlog in lavoro fatto e sono collettivamente responsabili della qualità.
La parte più utile, in pratica, è sapere cosa ciascuno NON deve fare. È lì che nascono i conflitti nei team reali.
| Accountability | Cosa fa | Cosa NON fa |
|---|---|---|
| Product Owner | Definisce e ordina il Product Backlog, massimizza il valore, chiarisce i requisiti, parla con gli stakeholder. | Non scrive il codice né stima al posto dei Developers, non aggiunge lavoro dentro lo Sprint, non fa da project manager classico. |
| Scrum Master | Coach del framework, rimuove impedimenti, facilita gli eventi, migliora il modo di lavorare del team. | Non assegna i task, non comanda il team, non sostituisce il Product Owner nelle decisioni di prodotto, non fa da segretario delle riunioni. |
| Developers | Pianificano lo Sprint, costruiscono l’Increment, si auto-organizzano, rispettano la Definition of Done. | Non aspettano ordini su “come” lavorare, non delegano la qualità a un reparto esterno, non accettano scope aggiuntivo silenziosamente durante lo Sprint. |
I 5 eventi di Scrum e i loro timebox
Gli eventi servono a creare regolarità e a ridurre il bisogno di riunioni non previste. Ognuno ha un timebox, cioè una durata massima: non un minimo da riempire, ma un tetto da rispettare. L’evento contenitore è lo Sprint, dentro il quale vivono tutti gli altri.
Lo Sprint è un ciclo a lunghezza fissa, al massimo un mese, durante il quale si produce un Increment utilizzabile. Quando uno Sprint finisce, ne inizia subito un altro: non ci sono pause tra uno e l’altro. La durata, una volta scelta, resta costante, perché è proprio la cadenza fissa a rendere prevedibile il ritmo.
| Evento | Timebox (Sprint di 1 mese) | Scopo |
|---|---|---|
| Sprint | Fino a 1 mese (durata fissa) | Contenitore di tutto il lavoro e degli altri eventi; produce un Increment. |
| Sprint Planning | Fino a 8 ore | Definire perché, cosa e come dello Sprint: si fissa lo Sprint Goal e si seleziona il lavoro. |
| Daily Scrum | 15 minuti, ogni giorno | I Developers sincronizzano il lavoro verso lo Sprint Goal e adattano il piano della giornata. |
| Sprint Review | Fino a 4 ore | Ispezionare l’Increment con gli stakeholder e adattare il Product Backlog. |
| Sprint Retrospective | Fino a 3 ore | Ispezionare il modo di lavorare e individuare miglioramenti concreti. |
Una nota pratica sui timebox: in uno Sprint di due settimane si dimezzano in proporzione. Planning intorno alle 4 ore, Review intorno alle 2, Retrospective intorno a 1 ora e mezza. Il Daily resta sempre 15 minuti, indipendentemente dalla lunghezza dello Sprint.
I 3 artefatti e i loro commitment
Gli artefatti rappresentano lavoro o valore e sono progettati per massimizzare la trasparenza. Dalla versione 2020 della Scrum Guide, ognuno è legato a un commitment, un impegno che dà direzione e permette di misurare i progressi.
Product Backlog e Product Goal
Il Product Backlog è la lista ordinata, e mai “finita”, di tutto ciò che potrebbe servire al prodotto. È l’unica fonte del lavoro per lo Scrum Team. Il suo commitment è il Product Goal: l’obiettivo di lungo periodo verso cui il team si muove, una sorta di stella polare.
Sprint Backlog e Sprint Goal
Lo Sprint Backlog è il piano dei Developers per lo Sprint: lo Sprint Goal, gli elementi scelti dal Product Backlog e il modo per realizzarli. Il suo commitment è lo Sprint Goal, l’unico obiettivo dello Sprint che dà coerenza e flessibilità: se cambia il dettaglio, l’obiettivo resta la bussola.
Increment e Definition of Done
L’Increment è un passo concreto verso il Product Goal: lavoro effettivamente completato e utilizzabile, che si somma agli Increment precedenti. Il suo commitment è la Definition of Done, la descrizione formale e condivisa dello stato di qualità necessario perché un elemento sia davvero “fatto”. Se non rispetta la Definition of Done, non è parte dell’Increment, punto.
Esempio: uno Sprint di 2 settimane, giorno per giorno
La teoria si capisce meglio calata in un caso concreto. Immagina un team di prodotto che lavora a una app di prenotazioni, con uno Sprint di due settimane (dieci giorni lavorativi) e lo Sprint Goal “consentire all’utente di modificare una prenotazione esistente”.
- Giorno 1, mattina: Sprint Planning. Il Product Owner spiega la priorità, il team concorda lo Sprint Goal e seleziona dal Product Backlog le storie sulla modifica prenotazione. I Developers abbozzano lo Sprint Backlog.
- Giorni 1-2: i Developers spezzano le storie in attività tecniche e iniziano dal flusso di modifica lato interfaccia.
- Giorni 2-9, ogni mattina: Daily Scrum di 15 minuti. Il team allinea i progressi verso lo Sprint Goal e segnala un impedimento (un’API di pagamento instabile). Lo Scrum Master se ne fa carico per rimuoverlo.
- Giorni 3-7: sviluppo e test della logica di modifica, con la Definition of Done sempre come riferimento (test scritti, codice in review, niente bug noti).
- Giorni 8-9: integrazione, correzione degli ultimi difetti, l’Increment diventa potenzialmente rilasciabile.
- Giorno 10, mattina: Sprint Review. Il team mostra la funzione agli stakeholder, raccoglie feedback (serve anche notificare via email l’avvenuta modifica) e aggiorna il Product Backlog.
- Giorno 10, pomeriggio: Sprint Retrospective. Il team riconosce che le stime erano ottimistiche e decide un’azione concreta: dal prossimo Sprint, riservare mezza giornata agli imprevisti tecnici.
Nota come ogni evento abbia fatto il suo mestiere: la Planning ha dato direzione, i Daily hanno tenuto il ritmo, la Review ha ispezionato il prodotto, la Retrospective ha migliorato il processo.
Gli errori più comuni (e come riconoscerli)
Molti team dicono di “fare Scrum” ma in realtà ne usano solo l’etichetta. Ecco tre derive ricorrenti che ho visto rovinare team in gamba.
- Il Daily come status report al capo: se la riunione delle 15 si trasforma in un giro di “cosa ho fatto ieri” recitato allo Scrum Master o al manager, ha perso senso. Il Daily è dei Developers, per sincronizzarsi tra loro verso lo Sprint Goal, non un controllo dall’alto.
- Lo Scrum Master scambiato per capo progetto: quando lo Scrum Master assegna i task, stabilisce le scadenze interne e decide le priorità di prodotto, non è più uno Scrum Master ma un manager travestito. Le priorità sono del Product Owner, l’auto-organizzazione è dei Developers.
- Definition of Done assente o vaga: senza un accordo chiaro su cosa significa “fatto”, ogni Sprint accumula debito nascosto. Il lavoro sembra completo ma non lo è, e la trasparenza, primo pilastro di Scrum, salta del tutto.
Il filo comune è sempre lo stesso: si tengono le cerimonie ma si tradiscono i pilastri. Trasparenza, ispezione e adattamento sono il test per capire se stai facendo Scrum o solo teatro.
Quando Scrum conviene davvero
Scrum dà il meglio quando il problema è complesso e i requisiti cambiano: prodotti digitali, progetti con molta incertezza, contesti dove imparare in fretta vale più che pianificare nel dettaglio. In quei casi i cicli brevi sono un vantaggio enorme, perché permettono di sbagliare in piccolo e correggere presto.
Non sempre però è la scelta giusta. Se l’ambito è stabile e ben noto, e le fasi devono susseguirsi in ordine rigido (pensa a certi progetti regolatori o infrastrutturali), un approccio sequenziale può funzionare meglio. Vale la pena ragionarci con la testa, e qui torna utile l’approfondimento su Agile vs Waterfall: quando usare l’uno o l’altro.
Scrum, inoltre, non è l’unico framework Agile. Per flussi di lavoro continui, dove non ha senso ragionare a Sprint, molti team preferiscono un sistema a flusso: se vuoi capire le differenze, leggi la guida su cos’è Kanban. E se il ruolo di Scrum Master ti incuriosisce come sbocco professionale, trovi un percorso dedicato nell’articolo sulla certificazione Scrum Master PSM I.
Come imparare Scrum sul serio (e prepararti alla certificazione)
Capire cos’è Scrum leggendo è un buon inizio, ma la padronanza arriva mettendo in pratica ruoli, eventi e artefatti su casi reali, e misurandosi con una certificazione riconosciuta. Scrum è il cuore del percorso base per chi vuole diventare digital project manager: padroneggiarlo apre la porta a tutto il resto.
Il Corso Digital Project Manager Foundation di Management Academy nasce proprio per questo. È un corso erogato interamente online, con 27 ore di contenuti video on demand e accesso garantito per 12 mesi, disponibile in modalità Community (solo on demand) oppure Blended, con un’ora di Q&A live a settimana con il docente. Prepara alla certificazione Professional Scrum Master I (PSM I) di Scrum.org: l’esame si sostiene presso Scrum.org e non è incluso nel costo del corso, mentre la certificazione, una volta ottenuta, è permanente. Il percorso include un simulatore d’esame, attestato con badge digitale verificabile, materiale scaricabile, community e app didattica, ed è di livello base, senza prerequisiti formali. Scopri il corso Digital Project Manager Foundation.
FAQ
Cos’è Scrum in parole semplici?
Cos’è Scrum, detto in modo essenziale: un framework Agile leggero per gestire lavoro complesso attraverso cicli brevi chiamati Sprint. Un piccolo team si dà un obiettivo, lavora per un periodo a lunghezza fissa, consegna qualcosa di utilizzabile, raccoglie feedback e ricomincia migliorando ogni volta.
Scrum e Agile sono la stessa cosa?
No. Agile è un insieme di valori e principi sulla gestione del lavoro; Scrum è uno dei framework che mettono in pratica quei principi. In altre parole Scrum è Agile, ma Agile non è solo Scrum: esistono altri approcci, come i sistemi a flusso continuo.
Quanto dura uno Sprint?
Uno Sprint dura al massimo un mese e ha una lunghezza fissa, decisa dal team. Le durate più comuni sono una o due settimane: cicli più corti aumentano la frequenza di feedback e adattamento. Una volta scelta, la durata resta costante per dare ritmo prevedibile.
Lo Scrum Master è il capo del team?
No. Lo Scrum Master è responsabile dell’efficacia dello Scrum Team e lo aiuta ad applicare Scrum rimuovendo impedimenti, ma non comanda e non assegna i compiti. Le decisioni di prodotto sono del Product Owner, mentre i Developers si auto-organizzano sul come svolgere il lavoro.
