1. 6.53
SCRUM METHOD

2. Le pratiche Scrum implicano la scoperta dei requisiti e lo sviluppo di soluzioni attraverso lo sforzo collaborativo di team auto-organizzati
e interfunzionali e dei loro clienti / utenti finali. Sostiene la pianificazione adattiva, lo sviluppo evolutivo, la consegna precoce e il
miglioramento continuo e incoraggia risposte flessibili al cambiamento.
• Scrum Master
• Product Owner
• Scrum Team
• Burndown chart
• User stories
• User story mapping
• Story point estimation
• Timeboxing
• Continuous delivery
• Daily Scrum
• Definition of done (DoD)
• Backlog refinement
• Sprints
SCRUM
METODO SCRUM

3. 3
SCRU
M
Scrum è un framework che genera valore attraverso soluzioni adattive per problemi complessi.
Il metodo Scrum richiede uno Scrum Master per promuovere un ambiente in cui:
1. Un Product Owner ordina il lavoro per un problema complesso in un Product Backlog.
2. Lo Scrum Team trasforma una selezione del lavoro in un incremento di valore durante uno
Sprint.
3. Lo Scrum Team e i suoi stakeholder ispezionano i risultati e si adeguano per lo Sprint
successivo.
4. Ripeti
Scrum è costruito sull'intelligenza collettiva delle persone che lo utilizzano. Piuttosto che
fornire alle persone istruzioni dettagliate, le regole di Scrum guidano le loro relazioni e
interazioni.
Scrum utilizza un approccio iterativo e incrementale per ottimizzare la prevedibilità e
controllare il rischio.
Il metodo coinvolge gruppi di persone che collettivamente hanno tutte le capacità e le
competenze per svolgere il lavoro e condividere o acquisire tali competenze secondo
necessità.

4. PILASTRI DEL METODO
TRASPARENZA
Il processo e il lavoro che ne deriva devono essere visibili a coloro che
eseguono il lavoro e a coloro che ricevono il lavoro.
ISPEZIONE
Gli artefatti di Scrum e i progressi verso gli obiettivi concordati devono
essere ispezionati frequentemente per rilevare variazioni o problemi
ADATTAMENTO
Se alcuni aspetti di un processo si discostano da limiti accettabili o se il
prodotto risultante è inaccettabile, il processo applicato o i materiali prodotti
devono essere adattati.
1/7/20XX 4

5. 5
Adattamento
03
• Il processo o il materiale in
lavorazione devono essere
regolati se un'ispezione
determina che uno o più aspetti
di un processo si discostano da
limiti accettabili e il prodotto
risultante sarà inaccettabile.
• Pianificazione dello sprint
• Mischia giornaliera
• Revisione dello sprint
• Retrospettiva Sprint
Ispezione
02
• Gli utenti Scrum devono
ispezionare frequentemente gli
artefatti di Scrum e progredire
verso un obiettivo Sprint.
• Le ispezioni non dovrebbero
essere così frequenti da
intralciare il lavoro.
• Le ispezioni sono più efficaci se
eseguite diligentemente da
ispettori qualificati sul luogo di
lavoro.
Trasparenza
01
• Gli aspetti principali del
processo devono essere definiti
da uno standard comune.
• Un linguaggio comune che si
riferisce al processo deve
essere condiviso da tutti i
partecipanti.
• Una definizione comune di
"Fatto" per coloro che
eseguono il lavoro e accettano
il prodotto di lavoro.
PILASTRI DEL METODO

6. 6
ELEMENTI SCRUM
Scrum Sprint è un time-box fisso ripetibile durante il quale viene creato un prodotto "Done" del più alto valore possibile. Lo Sprint è al
centro della metodologia Scrum e può essere pensato come un evento che racchiude tutti gli altri eventi Scrum come Daily Scrums, Scrum
Review e Sprint Retrospective. Di solito, uno Sprint dura un mese o meno.
Iterazione corrente. Implementazione di un pacchetto di
lavoro. Durata fissa (timeboxed). Risultati in un risultato
intermedio funzionale.
Sprint
Elenco dei requisiti per il nuovo prodotto. Modificabile e
adattabile in ogni momento. I requisiti sono classificati in
ordine di priorità e suddivisi in pacchetti di lavoro.
Product backlog
Il team presenta il risultato intermedio al Product owner e
alle parti interessate. Il feedback viene incorporato nello
sprint successivo.
Sprint review meeting
Riunione giornaliera di 15 minuti. Incontro informativo.
Ogni membro del team spiega su cosa sta lavorando al
momento.
Daily Scrum Meeting
Suddivisione del pacchetto di lavoro in pacchetti più
piccoli. Assegnandoli ai membri del team.
Documentazione del lavoro rimanente per ogni pacchetto.
Sprint backlog
Pacchetto di lavoro che non viene modificato durante lo
sprint. Risultato intermedio funzionale (incremento della
funzionalità potenzialmente spedibile).
Increment

7. 7
Product
Owner
Development
Team
Scrum
Master
Una persona responsabile della
massimizzazione del valore del
prodotto e del lavoro del team di
sviluppo (Product Backlog e
gestione delle priorità).
Composto da professionisti che
svolgono il lavoro per consegnare
un prodotto potenzialmente
rilasciabile "Fatto" alla fine di ogni
Sprint, auto-organizzante, cross-
funzionale.
Una persona che si assicura
che Scrum sia compreso e
messo in atto, organizza
riunioni e monitora tutto.
SCRUM TEAM

8. 8
Product Owner Development Team Scrum Master Organization
• Coaching nell'auto-organizzazione e nel lavoro di squadra e
rimozione degli impedimenti dal team di sviluppo.
• Aiuta il team di sviluppo a creare prodotti di alto valore.
• Facilita l'implementazione di Scrum.
• Trovare tecniche per una gestione efficace del
Product Backlog.
• Aiutare il team Scrum a comprendere la necessità di
elementi Product Backlog chiari e concisi.
• Facilita l'implementazione di Scrum.
• Guidare e istruire l'organizzazione nella sua adozione di
Scrum, pianificando l'implementazione di Scrum
all'interno dell'organizzazione.
• Aiutare i dipendenti e le parti interessate a comprendere
e attuare Scrum e lo sviluppo di prodotti empirici.
SCRUM TEAM

9. 9
Scrum Master
Roles
Apprendimento
e
scambio
Supporto
Scrum master roles
Supervisionare Riunioni e
l’applicazione dei principi Scrum
Pianificazione del rilascio
Attività di team building
Definizione di Done (DoD)
Mediare e risolvere i conflitti
Aiuta il team a eliminare gli ostacoli
Riparare la squadra dagli ostacoli
esterni
Autonomia del team
Trasparenza e apertura
Flessibilità
Comunicazione faccia a faccia
Monitoraggio e tracciamento
(Grafico burndown e schede di stato)
Reportistica gestionale, feedback sulle
prestazioni e miglioramento dei processi
Gestione dello strumento Scrum

10. 10
Scrum
Process
Update
Product
Backlog
Sprint
Planning
Meeting
Daily Scrum/
Work
Product
Increment
Sprint
Review
Sprint
Retrospective
Release N
Sprint Cycle
Sprint 1, 2, 3, N
Scrum
Master
Team
Members
Stakeholder
Users
Product
Owner
Product
Backlog
Sprint
Backlog
Burndown
Product
Backlog
Burndown
Impediment
List
Sprint
Backlog
Product
Backlog
Delta
Report
• Raccogliere e filtrare le
esigenze dell’utente
• Crea stories
• Backlog iniziale del prodotto
• Assembla il team
Preparazione
Scrum Artifacts
Release
Stockholders
Product
vision
Project
definition
Contractual
Agreement
Initial
release
plan
Product
Owner
Product
Owner
Scrum Roles
PROCESSO SCRUM

11. FASE 0
Identificazione del
cliente e delle
esigenze
il team di sviluppo si
incontra con il cliente per
capire le sue esigenze e
i suoi requisiti. In questa
fase, è importante
stabilire una buona
comunicazione e fare
domande per capire le
necessità del cliente.
Creazione del
Product Backlog
in base alle informazioni
raccolte nella fase
precedente, il Product
Owner crea una lista di
elementi prioritari da
sviluppare, chiamata
Product Backlog. Il
Product Owner, che
rappresenta il cliente, è
responsabile della
definizione delle priorità
dei singoli elementi.
11
Definizione del team
di sviluppo
in questa fase, il team di
sviluppo viene formato,
con l'inclusione di tutti i
membri necessari per la
realizzazione del
progetto. Il team
dovrebbe includere le
competenze tecniche
necessarie, ma anche
competenze come la
gestione del progetto e
la comunicazione con il
cliente.
Pianificazione della
Sprint
il team di sviluppo si
prepara per la sprint,
stabilendo gli obiettivi da
raggiungere durante la
sprint e pianificando il
lavoro da svolgere. Solo
dopo aver completato
queste fasi, il team di
sviluppo può passare
alla fase di lavoro

12. Product Backlog Management
Stockholders
Product
Owner
Raccogliere e
filtrare le
esigenze del
mercato dagli
stakeholder /
Crea stories
Release Planning Release Backlog Management
Release 1
Release 2
Release N
Una volta comprese le esigenze del
cliente, il team di sviluppo può iniziare a
creare le Epic e le User Stories. Le Epic
rappresentano le funzionalità di alto
livello richieste dal cliente e possono
essere divise in User Stories, cioè
descrizioni più specifiche e dettagliate
delle funzionalità richieste.
FASE 0
La creazione delle User Stories prevede generalmente i seguenti passaggi da parte del PO:
1. Identificazione utenti che utilizzeranno il prodotto e le loro esigenze specifiche.
2. Creazione schemi di flusso che descrivono come gli utenti utilizzeranno il prodotto.
3. Sulla base delle informazioni raccolte nei passaggi precedenti, il PO crea le User Stories
che descrivono le funzionalità specifiche del prodotto.
Le User Stories sono solitamente scritte in un formato semplice e comprensibile, ad esempio "Come utente, voglio essere in grado di effettuare un ordine online, in modo da poter acquistare i
prodotti desiderati in modo rapido e semplice". In questo modo, le User Stories aiutano a razionalizzare le funzionalità dal punto di vista dell'utente finale, in modo che il team di sviluppo possa
concentrarsi su ciò che è veramente importante per gli utenti e creare un prodotto che soddisfi le loro esigenze.

13. La priorità delle User Stories è basata sul valore che esse offrono al cliente e sull'urgenza delle loro esigenze. Il Product Owner valuta
le User Stories in base alle necessità del cliente e le assegna una priorità relativa rispetto alle altre User Stories nel Product
Backlog. In questo modo, il team di sviluppo può concentrarsi sulla realizzazione delle funzionalità più importanti per il cliente in primo
luogo. Ogni User Story viene tradotta in uno o più elementi del Product Backlog, che definiscono i requisiti dettagliati per la loro
implementazione
FASE 0
Il team di sviluppo può utilizzare una tecnica chiamata "story points" per stimare il tempo e lo sforzo necessari per completare
ciascuna User Story. Lo Story Point è una stima relativa dell'effort richiesto per implementare una User Story, basata su fattori come la
complessità, il rischio e la conoscenza necessaria per completare la User Story. In questo aspetto entra in gioco l’esperienza passata del
team.
Nella metodologia Scrum, la priorità di ogni User Story viene definita dal Product Owner, che rappresenta il cliente e ha la responsabilità di
definire le priorità delle User Stories nel Product Backlog.

14. Funzionalità 1
User Stories
User Stories
User Stories User Stories
User Stories User Stories
User Stories
Funzionalità 2
User Stories User Stories
User Stories User Stories
User Stories
Funzionalità 3
User Stories
User Stories
USER STORIES
Sprint 1
Sprint 2
Sprint n
Priorità

15. J F M A M J J A S O N D J F M A M J J A S O N D
S1
S2
S3
S4
S5
S6
S7
S8
S9
Project
#01
Project
#02
Project
#03
2021 2021
Agile roadmap
Text Placeholder Text Placeholder
Text Placeholder Text Placeholder
Text Placeholder Text Placeholder
Text Placeholder Text Placeholder
Text Placeholder Text Placeholder
Text Placeholder Text Placeholder
Text Placeholder Text Placeholder
Text Placeholder Text Placeholder Text Placeholder
Text Placeholder Text Placeholder

16. # Task Responsible Start Finish Days Status
Sprint I 28 Complete
1 Feature: placeholder text Anny Fry 01.02 12.02 11 Complete
2 Feature: placeholder text Max Factor 13.02 16.02 3 Complete
3 Feature: placeholder text Antony Stark 17.02 02.03 14 Complete
Sprint II 19 In progress
4 Feature: placeholder text Mary Freeman 03.03 05.03 2 Complete
5 Feature: placeholder text Helen Lee 05.03 20.03 15 In progress
6 Feature: placeholder text Hu Chan 20.03 22.03 2 In progress
Sprint III 25 Not started
7 Feature: placeholder text Anny Fry 22.03 01.04 10 Not started
8 Feature: placeholder text Mary Freeman 01.04 10.04 9 Not started
9 Feature: placeholder text Antony Stark 10.04 16.04 6 Not started
Agile project plan table

17. Scrum and Agile board
To Do’s
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Doing
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Done
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text
Card with
placeholder text

18. 1.Il Product Owner (PO) si incontra con il cliente per comprendere le esigenze del prodotto e definire la visione del prodotto.
2.Il PO, in collaborazione con il cliente, definisce le Epic, ovvero grandi funzionalità o obiettivi del prodotto.
3.Il PO, in collaborazione con il cliente, identifica le User Stories, ovvero funzionalità specifiche del prodotto raccontate dal punto di vista
dell'utente finale.
4.Il PO valuta le User Stories in base alle necessità del cliente e le assegna una priorità relativa rispetto alle altre User Stories nel Product
Backlog.
5.Il team di sviluppo stimava il tempo e lo sforzo necessari per completare ciascuna User Story utilizzando la tecnica dei "story points".
6.Il PO, in collaborazione con il cliente e il team di sviluppo, traduce le User Stories in elementi del Product Backlog, che è una lista prioritizzata di
tutte le funzionalità che il team di sviluppo dovrà implementare.
7.Il team di sviluppo, in collaborazione con il PO, seleziona un insieme di elementi del Product Backlog da implementare durante la Sprint
successiva.
8.Durante la Sprint, il team di sviluppo sviluppa le funzionalità selezionate sotto la supervisione del PO.
9.Il team di sviluppo si incontra quotidianamente nel Daily Scrum per condividere informazioni sul lavoro svolto e sul lavoro previsto, individuando
eventuali problemi e discutendo su come risolverli.
10.Alla fine della Sprint, il team di sviluppo presenta le funzionalità sviluppate durante la Sprint al PO e al cliente, ricevendo un feedback sul
lavoro svolto durante il Sprint Review.
11.Il team di sviluppo riflette sulla Sprint appena conclusa durante la Sprint Retrospective, identificando eventuali problemi e discutendo su come
migliorare per la prossima Sprint.
12.Il PO aggiorna il Product Backlog, includendo eventuali nuove User Stories o modificando le priorità esistenti, in base al feedback ricevuto dal
cliente e alle riflessioni fatte dal team di sviluppo durante la Sprint Retrospective.
13.Il processo si ripete con una nuova pianificazione della Sprint, selezionando nuove User Stories dal Product Backlog e avviando la successiva

19. I ruoli Scrum includono:
•Il Product Owner: responsabile della definizione della visione del prodotto, della gestione del Product Backlog e della priorizzazione delle User
Stories.
•Il team di sviluppo: responsabile dell'implementazione delle funzionalità selezionate durante la Sprint.
•Il Master Scrum: responsabile di facilitare il processo Scrum, rimuovere gli eventuali impedimenti, assicurare che il team segua le regole
Scrum e che le pratiche Scrum siano applicate correttamente.
I prodotti Scrum includono:
•Il Product Backlog: una lista prioritizzata di tutte le funzionalità che il team di sviluppo dovrà implementare.
Il Sprint Backlog: la lista degli elementi del Product Backlog selezionati dal team di sviluppo per la Sprint corrente.
•Incremento: il prodotto funzionante e testato alla fine di ogni Sprint.

20. Gli eventi Scrum includono:
•Sprint Planning: il primo evento della Sprint, in cui il PO e il team di sviluppo collaborano per definire gli obiettivi della Sprint e selezionare le User
Stories da implementare.
•Daily Scrum: una breve riunione giornaliera durante la Sprint, in cui il team di sviluppo discute del lavoro svolto e del lavoro previsto, identifica
eventuali problemi e pianifica le azioni da intraprendere per risolverli.
•Sprint Review: un evento alla fine della Sprint, in cui il team di sviluppo presenta al PO e al cliente le funzionalità sviluppate durante la Sprint,
ricevendo feedback e suggerimenti per migliorare.
•Sprint Retrospective: un evento alla fine della Sprint, in cui il team di sviluppo riflette sul lavoro svolto durante la Sprint e identifica eventuali
problemi e miglioramenti da apportare al processo Scrum.
Dopo la Sprint Retrospective, il processo si ripete con una nuova pianificazione della Sprint, selezionando nuove User Stories dal Product Backlog
e avviando la successiva Sprint. Il ciclo Scrum continua fino a quando il prodotto non è stato sviluppato e testato fino al punto di soddisfare le
esigenze del cliente, o quando il progetto viene interrotto.