Si presenta come una metodologia agile per la pianificazione e alla  gestione dei progetti.
Permette di avere un approccio adattivo cioè cerca di migliorare la non linearità dei progetti e mira alla gestione del cambiamento durante il processo di sviluppo un software.
Il termine Scrum deriva del Rugby e indica la mischia, questo vuole rappresentare la necessità di avere un team coeso che lavori insieme in modo che tutti spingano nella stessa direzione.

Tratto da Scrum For Team System

Preparation

Introduzione

La preparazione detta anche Sprint 0, serve per mettere, nel più breve tempo possibile, il team in grado di partire con le iterazioni che porteranno alla consegna del prodotto.
La quantità di lavoro da svolgere per iniziare un progetto, ovviamente varia da organizzazione a organizzazione e da progetto a progetto.
In questa fase vengono coinvolti i responsabili del progetto per organizzare i lavori.

Valutazione Economica

Ogni progetto dovrebbe avere una verifica economica, indipendente dal metodologia scelta per consegnarlo.
La prima cosa importante da considerare è che un comprensione chiara del valore del progetto porta ad avere una maggior consapevolezza nelle scelte di priorità, di funzionalità e di tempi di consegna.
Questa valutazione sarà probabilmente una valutazione di alto livello e che potrebbe cambiare e quindi non essere precisa.
Ecco perché i product backlog item sono valutati di giorno in giorno.
Il rapporto tra i benefici conseguiti e il costo sostenuto contribuirà a determinare se un progetto è stato utile.
L’inesattezza delle valutazioni viene spesso evidenziata dalla natura iterativa di Scrum che permette di valutare i reali avanzamenti dei vari sprint.
Questo permette di attenuare le valutazioni dei rischi inesatte e permette di non sprecare tempo cercando di creare valutazioni troppo accurate.
Un vantaggio spesso trascurato di Scurm è la verifica di fattibilità di un progetto infatti, dopo solo uno Sprint diventa chiaro se i requisiti non possono essere soddisfatti.
Questo permette di interrompere il progetto all’inizio piuttosto che a 6, 12 mesi.

Project Vision

Come altre metodologie agili non consiglia la documentazione inutile.
Diventa importante però che l’intero team capisca l’essenza del progetto o il prodotto che si sta cercando di realizzare.

Initial Product Backlog

Un product backlog è una lista requisiti di progetto ordinata per priorità con una stima espressa in giorni.
Le valutazioni diventano più precise più è alta la priorità.
La priorità dovrebbe essere assegnata valutando le funzionalità dal punti di vista economico e come return of investment.
Questa lista non è statica ma cambia a seconda delle condizioni che cambiano nel tempo.
Questo elenco è composto da requisiti funzionali non funzionali e richieste.
La loro granularità è dipendente dallo sprint in cui si trovano, in quello in corso saranno più precise e specifiche.
Ogni idea o requisito può essere aggiunto alla product backlog.
Questo rende il product backlog uno strumento molto utile per calmare gli utenti, che in alcune riunioni possono fare richieste che causano degli attriti con il project manager, in scum la risposta si trasforma in "Great idea, we'll put it on the Product Backlog and prioritise against the rest of the Backlog".
Questo fa in modo che il valore di una nuova richiesta venga confrontato con il valore effettivo del resto del progetto.

Initial Release Plan

Il team entra nel primo                sprint e dovrebbe identificare abbastanza product backlog da consentigli di iniziare il lavoro.
L’elenco dei product backlog può uscire da un Business Case trasformato in un documento dei requisiti o direttamente dal product owner.

Assemble Team

Una volta identificate le figure necessarie per il progetto, è bene organizzare una riunione con temi, lo scopo del progetto, i backlog ad alto livello,  definizione dei tempi di scrum.

Logistics

Ci sono una serie di attività logistiche da preparare prima dell’inizio di un progetto.
Il luogo dove il team dovrà lavorare è molto importante, infatti se è possibile sarebbe meglio riunire il team nella stessa stanza per migliorare la comunicazione, altrimenti è necessario utilizzare tutti i mezzi tecnologici come telefono e video chiamate  per gestire al meglio la comunicazione.

Ruoli

In scrum vengono divise le figure che sono direttamente coinvolte da quelle parzialmente coinvolte.

Product Owner

Il product owner è responsabile del return of investment del progetto.
Questa persona è un investitore o rappresenta qualcuno interessato al progetto, è responsabile della consegna del progetto e degli investimenti legati a esso.
Solitamente questa figura è un dipendente del cliente incaricato del progetto con delle responsabilità dopo il rilascio.
Il product owner deve avere una comprensione ad alto livello assegnare le priorità ai requisiti funzionali, non funzionali e creativi del progetto.
Deve accertarsi che le funzionalità e le priorità.
Decide le caratteristiche del prodotto la data di consegna e la soddisfazione.
Unifica le richieste del Cliente e degli altri utenti.
Accetta o rifiuta il lavoro finale
Può cambiare priorità ogni mese
È responsabile del Roi

Team Members

Le persone che costituiscono il team member hanno abilità differenti che sono necessarie per trasformare i requisiti nel prodotto.
Spesso i team è composto dall’analista, il progettista, il responsabile della QA, uno sviluppatore, un responsabile della documentazione.
Ad ogni iterazione il lavoro del team viene sottoposto al product owner ed esso può decidere quali sono i passi successivi.
In un progetto solitamente esistono delle figure altamente specializzate per quanto riguarda la sicurezza, l’usabilità, le basi di dati ecc…
Queste figure devono avere un ruolo ben preciso, se svolgono una attività di mentoring o guidano il processo di sviluppo di una parte posso entrare o meno a far parte delle persone coinvolte.

Scrum Master

Ci sono diversi modi per interpretare lo scrum master uno è quello di genitore che insegna al team come auto gestirsi con il produc owner.
Lo scrum master deve far rispettare le regole e creare un gruppo coeso e facendo crescere i componenti.
Per avere il massimo del rendimento lo scrum master deve far in modo che i le attività che prevede scrum vengano rispettate.
Un altro compito dello scrum master è rimuovere qualsiasi impedimento interno o esterno al raggiungimento del goal all’interno dello sprint.
Permettere una stretta collaborazione tra tutti i ruoli del team e rimozione delle barriere.
Protegge il team dalle interferenze esterne
Si accerta che il percorso venga seguito
Insegnando al cliente come elevare ROI e conseguire i loro obiettivi.
Migliora l’ingegneria utilizzando strumenti che permettano la riduzione dei tempi  di consegna.

Stakeholder

Tutti i consegnatari potenziali per il progetto dovrebbero essere identificati prima possibile e informati dell’avanzamento del progetto.

Il Processo

L’obbiettivo del processo di Scrum è dare i maggiori risultati ogni mese.
Il processo parte con il product owner che definisce una priorità per i product backlog.
Questo permette di avere un insieme di product backlog da analizzare e pianificare nello sprint planning meeting.
Il team inizia a lavorare sugli sprint backlog quotidianamente e si verifica nel daily scrum.
Alla conclusione dello sprint viene mostrato il lavoro al product owner e agli altri soggetti interessati.
I feedback ricevuti verranno inseriti durante lo sprint review nel poduct backlog e verranno assegnate le nuove priorità.
Prima di affrontare lo sprint successivo il team, durante lo Sprint retrospective discute delle prestazioni e apporta i miglioramenti necessari.
Il Team continua con gli sprint fino ad aver sviluppato un prodotto utile e funzionante per la produzione.

Daily Scrum Meeting

Il Daily Scrum è una riunione giornaliera di 15 minuti tenuta da ogni team.
Durante la riunione ogni partecipante aggiorna gli altri sull’avanzamento delle attività e su gli ostacoli incontrati, lo scrum master prende nota per la loro rimozione.
Questi sono molti utili perche permettono di identificare subito i problemi e condividendo le soluzioni riducono i tempi spesi.
Il team risulta più consolidato perché vengono chiariti gli obbiettivi e si riducono le incomprensioni.
Restare in piedi durante queste riunioni migliora l’attenzione.
Alcune regole che aiutano lo svolgimento di questa riunione:

• Pianificare la riunione nello stesso posto alla stessa ora, meglio se di mattina di modo che i componenti del team possano pensare a cosa hanno fatto ieri e cosa si prefissano di fare oggi.
• Tutti i componenti del team sono tenuti ad assistere, se qualcuno non può essere presente deve comunicare i suo stato di avanzamento.
• I membri della team devo essere rapidi. La riunione inizia all’orario prefissato senza deroghe.
• Ogni membro del team deve parlare e dire che cosa ha fatto ieri cosa farà oggi e quali sono i problemi che ha incontrato.
• Durante la riunione non si fanno domande, non si discute, non si divaga. Lo scrum master è responsabile dell’andamento della riunione.
• L’obbiettivo di far comunicare la squadra e non di parlare allo scrum master
• Si parla uno solo per volta senza altri disturbi.
• Quando un membro del team segnala qualcosa di interessante o richiede l’assistenza di altre persone ci può essere una risposta immediata ma la discussione deve continuare fuori dal daily scrum.
• Chi non è direttamente coinvolto nel progetto può partecipare ma non deve intervenire ne disturbare.

The Sprint

Lo sprint è un periodo di tempo definito che deve durare 30 giorni dove il team lavora per completare i product backlog per produrre un aumento di funzionalità del prodotto.
Un mese come durata permette di essere abbastanza lungo per riuscire a produrre qualcosa di significativo e abbastanza corto per sostenere il processo di sviluppo e potersi migliorare e valutare.
Gli obbiettivi e le attività dello sprint sono definite all’inizio di ogni sprint durante la riunione di sprint planning.
L’avanzamento dei lavori viene tracciato tramite il completamento delle sprint backlog e del grafico di sprint burndown.
Come per il progetto esiste una vison è importante avere un obbiettivo (Sprint Goal) per ogni sprint.
Per gestire al meglio ogni Sprint ci sono alcune regole da rispettare:

• Durante ogni sprint il team può chiedere aiuto a fonti esterne ma deve conoscere gli obbiettivi e gestirsi autonomamente.
• Durante lo Sprint Planning vengono decisi i product backlog da portare a termine e nessuno esterno dovrebbe modificari.
• Se lo sprint risulta impossibile lo scrum master può interromperlo per organizzare una nuova riunione di pianificazione.  Questa decisione deve essere presa solo dallo scrum master. Lo sprintt può essere interrotto se la tecnologia è inattuabile, se le condizioni esterne cambiano talmente tanto da risentire sul processo se la squadra è disturbata da elementi esterni.
• Se il team ritiene di non riuscire a completare i product backlog pianificati è possibile contrattare con il product owner per la rimozione di alcuni o lo scrum master può decider di interrompere lo sprint.
• Se durante i primi giorni dello sprint ci si accorge che il carico è superiore del 20% lo sprint va ripianificato e va riportata questa anomalia nel Sprint Retrospective.
• Se la situazione è ribaltata quindi si è pianificato meno lavoro è possibile inserire nuove attività consultando il product owner.
• I membri del team hanno due responsabilità, partecipare alle daily scrum meeting e mantenere aggiornate le attività nello sprint backlog, aggiungendo subito le nuove funzionalità identificate nel product backlog.
• Se una attività dura più di un girono deve essere decomposta in attività più granulari.
• Il team deve seguire le convezioni e le pratiche stabilite per lo sviluppo di software.

Sprint Planning

Lo scopo di uno sprint è trasformare una lista di product backlog in un aumento di funzionalità.
Lo scrum master, il product owner e il team si riuniscono per determinare su quali funzionalità del prodotto il team dovrà lavorare.
Il product owner identifica le funzionalità che vorrebbe avere e il team da una stima di tempi per capirne la fattibilità.
Lo sprint planning può essere diviso in due fasi, nella prima vengono identificati i possibili product backlog da completare e nella seconda il team definisce l'architettura ed il disegno delle funzionalità e definisce le mansioni.

• Il product owner definisce le priorità
• Tutti insieme si decide quali attività possono essere completate in uno sprint.
• Il team ottiene i particolari necessari per verificare la fattibilità.
• Il product owner è responsabile della negoziazione delle attività nei confronti dello stakeholder.
• Il team prende in consegna soltanto il lavoro che realmente pensa di consegnare.
• La capacità produttiva del team può essere valutata guardando gli sprint precedenti e la complessità relativa alle attività richieste.
• Le product backlog possono essere suddivise in sprint backlog

Sprint Review

Lo sprint review fornisce un controllo sull’andamento del processo alla conclusione di ogni sprint.
Sulla base delle verifiche fatte possono essere fatti degli adattamenti.
Alla conclusione dello Sprint, la squadra presenta l'incremento sul prodotto.
L'amministrazione, i clienti, gli utenti ed il product owner valutano l'incremento delle funzionalità.
Vengono ascoltate le cose andate bene o male durante lo Sprint.
Dopo di che si hanno gli elementi necessari per decidere come procedere con l’avanzamento del progetto.
Durante questa riunione dovrebbe uscire le richieste di miglioramento o l’aggiunta di funzionalità potendo osservare concretamente il prodotto.
Il team aiuta a prendere le decisioni avendo seguito il processo di sviluppo e conoscendo punti forti e deboli del sistema.
Per operare al meglio durante una sprint review:

• La preparazione della sprint review non deve durare più di un ora.
• Non devono essere presentate funzionalità non concluse.
• La presentazione delle funzionalità dovrebbe essere fatta in un ambiente più vicino alla produzione ad esempio l’ambiente di gestione della qualità
• La revisione di Sprint comincia con un membro del Team che presenta l'obiettivo di Sprint, Product Backlog completato e Product Backlog non completato. Gli altri membri del team possono commentare su cosa sia andato bene o male durante lo sprint.
• Una volta conclusa la presentazione vengono ascoltati i commenti dei consegnatari.
• Il product owner ascolta le richieste e riorganizza le priorità per il prossimo sprint.
• Gli stakeholder possono commentare e identificare funzionalità che non sono state previste o che non rispettano le specifiche e proporle per la nuova pianificazione.
• Lo scrum master si occupa di decidere le persone che dovranno partecipare alla riunione.
• Alla fine della riunione lo scrum master annuncia la data e il luogo della prossima Sprint Review.

Sprint Retrospective

Questa riunione facilita lo scrum master e il team a identificare che cosa può essere cambiato per rendere il successivo sprint più produttivo.
Lo sprint review guarda a “che cosa” la squadra sta costruendo mentre lo sprint retrospective guarda al “come” viene costruito.
Tutto quello che potrebbe essere interessante diventa argomento di discussione, come processi, pratiche, comunicazione, ambiente, strumenti.
Scrum non è una metodologia rigida e quindi lo Sprint Retrospective è un meccanismo importante che permette che a un team di evolversi e migliorare continuamente con la durata di un progetto.
Allo sprint retrospective partecipano il product owner, lo scrum master e il team e tutti possono proporre miglioramenti.
Diventa importante in questa riunione far emergere in un ambiente aperto e costruttivo i problemi.
Spesso utilizzare una persona esterna per guidare la riunione permette allo scrum master di partecipare più attivamente e è particolarmente utile se le emozioni ed i rapporti nel team non sono armoniosi come dovrebbero essere.