Work Methodologies DefinedTerm

Scrum

Conosciuto anche come: Scrum Framework, Scrum Methodology

Framework agile per gestire lo sviluppo di prodotti complessi attraverso cicli iterativi chiamati sprint, ruoli definiti e cerimonie strutturate.

Updated: 2026-01-04

Definizione

Scrum è un framework agile per sviluppare, consegnare e sostenere prodotti complessi. Definito originariamente da Ken Schwaber e Jeff Sutherland negli anni ‘90, Scrum struttura il lavoro in cicli time-boxed chiamati sprint (tipicamente 2 settimane), con ruoli, eventi e artifact chiaramente definiti.

La Scrum Guide (ultima versione 2020) descrive Scrum come “leggero, semplice da capire, difficile da padroneggiare”. Il framework è deliberatamente incompleto: definisce regole minime, lasciando alle organizzazioni la libertà di adattare pratiche specifiche al contesto.

Struttura del framework

Ruoli (Accountabilities)

Product Owner: responsabile di massimizzare il valore del prodotto. Gestisce il Product Backlog, definisce priorità, e decide cosa costruire. È l’unica persona che può accettare o rifiutare il lavoro completato.

Scrum Master: servant-leader che aiuta il team e l’organizzazione a comprendere e applicare Scrum. Rimuove impedimenti, facilita eventi, coaching il team verso auto-organizzazione. Non è un project manager.

Developers: chiunque nel team contribuisca alla creazione del prodotto (sviluppatori, designer, tester, ecc.). Auto-organizzati, collettivamente responsabili della qualità e della consegna dello sprint.

Eventi (Cerimonie)

Sprint: contenitore time-boxed (1-4 settimane) per tutti gli altri eventi. Ogni sprint produce un incremento potenzialmente rilasciabile. La durata è fissa e non cambia durante il progetto.

Sprint Planning: il team pianifica il lavoro dello sprint (max 8h per sprint di 1 mese). Definisce lo Sprint Goal e seleziona item dal backlog. Output: Sprint Backlog.

Daily Scrum: sincronizzazione quotidiana di 15 minuti, stessa ora e luogo. I Developers ispezionano il progresso verso lo Sprint Goal e adattano il piano. Non è un report allo Scrum Master.

Sprint Review: demo del lavoro completato agli stakeholder (max 4h per sprint di 1 mese). Feedback utilizzato per adattare il Product Backlog.

Sprint Retrospective: il team ispeziona il processo e identifica miglioramenti (max 3h per sprint di 1 mese). Focus su persone, relazioni, processi e strumenti.

Artifact

Product Backlog: lista ordinata di tutto ciò che potrebbe essere necessario nel prodotto. Gestito dal Product Owner, è dinamico e in continua evoluzione.

Sprint Backlog: sotto-insieme del Product Backlog selezionato per lo sprint corrente, più un piano per consegnare l’incremento. Appartiene ai Developers.

Increment: somma di tutti i Product Backlog item completati durante uno sprint e tutti gli sprint precedenti. Deve essere in condizione “done” e utilizzabile.

Adozione e utilizzo

Diffusione: Scrum è il framework agile più adottato. Il State of Agile Report 2024 riporta che il 66% delle organizzazioni agile usa Scrum o varianti (Scrumban, Scrum/XP hybrid). La percentuale è stabile dal 2018.

Certificazioni: Scrum.org (PSM, PSPO) e Scrum Alliance (CSM, CSPO) offrono certificazioni riconosciute. Nel 2024 si stimano oltre 1 milione di professionisti certificati Scrum a livello globale.

Scaling: per coordinare multiple team Scrum, esistono framework come Scrum@Scale, Nexus, e LeSS. SAFe include elementi Scrum ma aggiunge livelli gerarchici significativi.

Considerazioni pratiche

Team size: la Scrum Guide raccomanda team di 10 persone o meno (tipicamente 5-9). Oltre questa dimensione, considerare di splittare in multiple team con backlog condiviso.

Definition of Done: criterio condiviso di quando il lavoro è completo. Include standard tecnici (test passati, code review, documentazione) e business (demo agli stakeholder). Critico per evitare debito tecnico.

Velocity: metrica emergente che misura story point completati per sprint. Usata per forecasting, non per confronti tra team o performance individuale. La velocity di un team è specifica a quel team.

Technical debt: Scrum non prescrive pratiche tecniche. Team efficaci integrano XP practices (TDD, pair programming, CI/CD, refactoring) per mantenere la qualità del codice e la velocità sostenibile.

Fraintendimenti comuni

”Scrum richiede sempre sprint di 2 settimane”

No. La Scrum Guide permette sprint da 1 a 4 settimane. Due settimane è una convenzione comune ma non obbligatoria. La chiave è mantenere la durata costante una volta scelta.

”Il Daily Scrum è un report allo Scrum Master”

No. È un evento per i Developers per sincronizzarsi tra loro. Lo Scrum Master partecipa solo se è anche Developer. Non è un meeting di status per il management.

”Scrum significa nessuna documentazione o design upfront”

Falso. Scrum non proibisce design o documentazione. Incoraggia a farli just-in-time e continuamente, anziché tutto upfront. Architetture emergenti richiedono comunque visione e guardrail iniziali.

”Lo Scrum Master è il team leader o project manager”

No. Lo Scrum Master è un servant-leader che facilita, non comanda. Non assegna task, non approva ferie, non fa performance review. Il team si auto-organizza.

Termini correlati

  • Agile Software Development: filosofia e principi alla base di Scrum
  • Kanban: approccio alternativo basato su flusso continuo anziché sprint
  • DevOps: pratiche complementari per delivery e operations
  • OKR: framework di goal-setting che si integra con sprint planning

Fonti

  • Sutherland, J. & Schwaber, K. (2020). The Scrum Guide
  • Digital.ai (2024). 17th State of Agile Report
  • Sutherland, J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time
  • Cohn, M. (2005). Agile Estimating and Planning
  • Scrum.org: risorse ufficiali e training