Scrum è un framework agile per la gestione del ciclo di sviluppo del software, iterativo ed incrementale, concepito per gestire progetti e prodotti software o applicazioni di sviluppo, creato e sviluppato da Ken Schwaber e Jeff Sutherland.

Scrum enfatizza tutti gli aspetti di gestione di progetto legati a contesti in cui è difficile pianificare in anticipo. Vengono utilizzati meccanismi propri di un "processo di controllo empirico", in cui cicli di feedback che ne costituiscono le tecniche di management fondamentali risultano in opposizione alla gestione basata sul concetto tradizionale di command-and-control. Il suo approccio alla pianificazione e gestione di progetti è quello di portare l'autorità decisionale al livello di proprietà e certezze operative.

Il termine Scrum, in quanto applicato allo sviluppo di prodotti, è stato per la prima volta utilizzato in "The New New Product Development Game" (Harvard Business Review 86116:137-146, 1986) e successivamente elaborato in "The Knowledge Creating Company" entrambi testi di Ikujiro Nonaka e Hirotaka Takeuchi (Oxford University Press, 1995).

Storia Nel 1986, Hirotaka Takeuchi e Ikujiro Nonaka descrissero un nuovo approccio allo sviluppo di prodotti commerciali che avrebbe aumentato la velocità e la flessibilità, basato su casi di studio presi dall'industria automobilistica e quella relativa alla realizzazione di fotocopiatrici e stampanti. Essi lo chiamarono approccio olistico o rugby, in quanto l'intero processo viene eseguito da un team interfunzionale su più fasi che si sovrappongono, dove la squadra "cerca di raggiungere l'obiettivo come unità, passando la palla avanti e indietro".

Il termine Scrum è mutuato dal termine del rugby che indica il pacchetto di mischia ed è evidentemente una metafora del team di sviluppo che deve lavorare insieme in modo che tutti gli attori del progetto spingano nella stessa direzione, agendo come un'unica entità coordinata.

Ken Schwaber e Jeff Sutherland hanno presentato per la prima volta Scrum alla conferenza OOPSLA del 1995. Questa presentazione ha essenzialmente documentato ciò che Ken e Jeff avevano appreso negli anni precedenti applicando Scrum. Nel 2001 Schwaber ha collaborato con Mike Beedle per descrivere il metodo in un libro chiamato Agile Software Development with Scrum.. Inoltre, nel 2004, Ken Schwaber ha pubblicato il libro Agile Project Management with Scrum pubblicato da Microsoft Press.

La teoria di Scrum Scrum si basa sulla teoria dei controlli empirici di analisi strumentale e funzionale di processo o empirismo. L'empirismo afferma che la conoscenza deriva dall'esperienza e che le decisioni si basano su ciò che si conosce. Scrum utilizza un metodo interattivo e un approccio incrementale per ottimizzare la prevedibilità e il controllo del rischio.

Sono tre i pilastri che sostengono ogni implementazione del controllo empirico di processo.

Trasparenza Gli aspetti significativi del processo devono essere visibili ai responsabili del lavoro. La trasparenza richiede che quegli aspetti siano definiti da uno standard comune in modo tale che gli osservatori condividano una comune comprensione di ciò che viene visto. Ad esempio: Un linguaggio comune di riferimento al processo deve essere condiviso da tutti i partecipanti; Una definizione comune della parola "fatto" (in inglese "done") deve essere condivisa da chi esegue il lavoro e da chi deve accettarlo.

Ispezione Chi utilizza Scrum deve ispezionare frequentemente gli artefatti prodotti e i progressi realizzati verso il conseguimento degli obiettivi prestabiliti, individuando in tal modo precocemente eventuali difformità rispetto a quanto si intende realizzare. La frequenza delle ispezioni non deve essere tale da determinare un'interruzione del lavoro in corso. Le ispezioni devono essere eseguite diligentemente e da ispettori qualificati.

Adattamento Se chi ispeziona verifica che uno o più aspetti del processo di produzione sono al di fuori dei limiti accettabili e che il prodotto finale non potrà essere accettato, deve intervenire sul processo stesso o sul materiale prodotto dalla lavorazione. L'intervento deve essere portato a termine il più rapidamente possibile per ridurre al minimo l'ulteriore scarto rispetto agli obiettivi prestabiliti. Scrum prescrive quattro occasioni formali per l'ispezione e l'adattamento: Sprint Planning Meeting Daily Scrum Sprint Review Sprint Retrospective

Caratteristiche In maniera molto sintetica Scrum è un framework di processo che prevede di dividere il progetto in blocchi rapidi di lavoro (Sprint) alla fine di ciascuno dei quali creare un incremento del software. Esso indica come definire i dettagli del lavoro da fare nell'immediato futuro e prevede vari meeting (eventi) con caratteristiche precise per creare occasioni di ispezione del lavoro svolto.

Il framework Scrum è un sistema formato basato su valori, responsabilità, eventi, artefatti e regole ad essi associati allo scopo di creare un ambiente trasparente che permetta l'ispezione ed adattamento. Ogni parte del framework serve a uno specifico scopo ed è essenziale per il successo e l'utilizzo di Scrum. Le regole di Scrum legano insieme eventi, responsabilità, artefatti e commitments, governando le relazioni e interazioni tra essi anche se le strategie specifiche per l'utilizzo del framework Scrum variano e vengono descritte in molti testi specifici.

Responsabilità Fino a qualche tempo fa le persone all'interno di un'organizzazione dove si fosse utilizzato Scrum venivano divise in due gruppi distinti: i maiali e i polli (in base alla storiella The Chicken and the Pig, una metafora che distingue ironicamente fra chi è "strettamente coinvolto" in un progetto e chi lo è invece solo parzialmente). Si è scelto nel 2011 di non utilizzare più questa analogia, perché da molti è stata ritenuta inappropriata ed offensiva.

Le persone che ricoprono i ruoli principali nel processo Scrum costituiscono il Team Scrum e sono quelle impegnate nel progetto e che realizzano il prodotto (obiettivo del progetto).

Il Team Scrum Il Team Scrum è formato dal Product Owner, sviluppatori (fino al 2017 development team, ora rinominato per ribadire il concetto che non esistono sotto-team) e da uno Scrum Master. I Team Scrum sono auto-organizzati e cross-funzionali: scelgono come meglio compiere il lavoro organizzandosi e coordinandosi al proprio interno e hanno tutte le competenze necessarie per realizzare il lavoro senza dover dipendere da nessuno al di fuori del team. Il modello di team in Scrum è progettato per ottimizzare la flessibilità, la creatività e la produttività. I Team Scrum rilasciano i prodotti in modo iterativo e incrementale, massimizzando le opportunità di feedback. I rilasci incrementali di prodotto "fatto" garantiscono che una versione potenzialmente utile del prodotto funzionante sia sempre disponibile.

Secondo l'ultima versione della scrum guide questo è tipicamente composto da 10 o meno persone

Product Owner Il Product Owner rappresenta gli stakeholders ed è la voce del cliente. È responsabile di massimizzare il valore del prodotto risultante dal lavoro svolto dallo scrum team. Il Product Owner definisce gli item (requisiti di prodotto) centrati sui bisogni dei clienti (tipicamente, ma non necessariamente user stories), assegna loro la priorità, e li aggiunge al Product Backlog. I team Scrum devono avere un Product Owner e si raccomanda che questo ruolo non sia combinato con quello dello Scrum Master. Il ruolo di Product Owner non va inoltre confuso con quello di Product Manager.

Team di sviluppo Il team di sviluppo è responsabile della consegna del prodotto, con incrementi di caratteristiche, che sia potenzialmente rilasciabile alla fine di ogni Sprint. Un team di sviluppo è composto da persone, con competenze cross-funzionali, che stimano e realizzano il lavoro effettivo (analisi, progettazione, sviluppo, test, comunicazione tecnica, documentazione...). Il team di sviluppo in Scrum si auto-organizza e gli incrementi sviluppati sono tenuti a rispettare la definition of done, sebbene possa esserci un'interfaccia verso il PMO (Project Management Office).

Scrum Master Lo Scrum Master è responsabile della rimozione degli ostacoli che limitano la capacità del team di raggiungere l'obiettivo dello Sprint e i deliverable previsti e di massimizzare l'efficacia del team. Sebbene sia un ruolo manageriale, lo Scrum Master non è il team leader, piuttosto colui che facilita una corretta esecuzione del processo. Lo Scrum Master detiene l'autorità relativa all'applicazione delle norme. Una parte fondamentale del ruolo di Scrum Master è quello di proteggere il team di sviluppo e tenerlo concentrato sui compiti fungendo da cuscinetto verso qualsiasi influenza di distrazione. Fino al 2020, il ruolo viene anche descritto come servant-leader, anche se nell'ultima versione è più un true leader who serves the team. Lo scrum master, oltre ad essere un leader, deve anche essere un buon coach e un insegnante che sappia insegnare scrum agli altri membri del gruppo, sia capace di aiutare il product owner nella comunicazione degli obiettivi di progetto e nel trovare tecniche per massimizzare l'efficacia del product backlog e istruire il team nella direzione dell'auto organizzazione

Stakeholder Lo stakeholder non fa parte dei ruoli del gruppo scrum, ma è il portatore di interessi che interfacciandosi con il po o con il team in generale da feedback e chiede modifiche (lasciando però l'ultima parola sempre al gruppo)

Eventi Gli eventi previsti sono utilizzati in Scrum per creare regolarità e ridurre al minimo la necessità di riunioni non definite da Scrum stesso. Scrum utilizza eventi time-box, in modo che ogni evento abbia una durata massima. Questo assicura che una quantità appropriata di tempo sia trascorsa pianificando, senza permettere l'introduzione di sprechi nel processo di pianificazione. Oltre allo stesso Sprint, che è un contenitore di tutti gli altri eventi, ogni evento in Scrum è un'occasione formale per ispezionare e adattare qualcosa. Questi eventi sono specificamente progettati per consentire trasparenza critica e ispezione. La mancata inclusione di uno qualsiasi dei risultati di questi eventi riduce la trasparenza ed è un'occasione persa per ispezionare e adattarsi.

Lo Sprint contiene e consiste dello Sprint Planning meeting, del Daily Scrum, del lavoro di sviluppo, dello Sprint Review e della Sprint Retrospective. Oltre questi eventi principali, possono aggiungersi altri due meeting: il Backlog Grooming e lo Scrum of Scrums.

Sprint

Lo sprint è l'evento base in scrum, ha una durata fissa decisa dal team, che può andare da una a quattro settimane e dà ritmo e permette di attuare al suo interno i tre pilastri dell'empiricismo scrum.

Ogni sprint contiene al suo interno gli altri eventi scrum e all'interno di esso si trasformano gli items in valore aggiunto per il prodotto.

A inizio sprint viene fatta una pianificazione, chiamata sprint planning, in cui si pianifica il lavoro di tutta la durata dello sprint, alla fine si ispeziona il risultato in un evento, chiamato sprint review, e il processo nella sprint retrospective.

Ogni giorno gli sviluppatori si incontrano in un meeting chiamato daily scrum, dove in quindici minuti si allineano sull'andamento del lavoro.

Il lavoro nello sprint è regolato dallo sprint backlog, un artefatto di valore contenente gli oggetti che gli sviluppatori hanno previsto di portare entro lo sprint, in senso di storie e task, insieme allo sprint goal, il commitment dello sprint backlog ovvero l'obiettivo finale di quello sprint che non può essere cambiato né rinegoziato, a differenza delle storie e i task.