Se hai lavorato nel project management digitale, probabilmente hai già sentito parlare della metodologia Scrum.
Scrum è una popolare metodologia di project management che è stata ampiamente adottata in diversi settori.
Alla sua base, Scrum si fonda sull’idea di responsabilizzare i team, permettendo loro di auto-organizzarsi e prendere decisioni sul modo migliore per raggiungere gli obiettivi. Questo approccio può aiutare i team a consegnare prodotti e servizi di alta qualità in modo rapido ed efficiente.
Cos’è la metodologia Scrum?
Puoi definire la metodologia Scrum come un approccio alla consegna dei prodotti che propone principi e processi per migliorare i risultati.
La gestione di progetti Agile Scrum definisce requisiti di tempo e costi fissi per i progetti. Scrum raggiunge questo obiettivo utilizzando time box (un periodo di tempo specifico e limitato) per le iterazioni di lavoro, oltre a backlog di prodotto ed eventi di team specifici. È un framework altamente adattivo che aiuta a fornire valore nei progetti più velocemente.
Nella gestione Scrum, i progetti avanzano attraverso sprint che rappresentano un’iterazione di lavoro verso gli obiettivi del team. Ogni sprint o iterazione produce un incremento consegnabile.
La metodologia Scrum è una delle tante metodologie agili, tutte in grado di ribaltare il classico triangolo predittivo o a cascata dello sviluppo di progetti e prodotti.
Mentre le metodologie tradizionali di project management limitano l’ambito (ad esempio delineandolo in un documento di definizione dello scopo) e lasciano flessibili tempi e risorse, le metodologie agili (compresa Scrum) fissano risorse e tempistiche, ma rendono flessibile l’ambito, a seconda di ciò che è più importante realizzare nel tempo e con le risorse disponibili.

Alla sua radice, Scrum dà potere ai team di creare una tensione positiva tra fare la cosa giusta, nel modo giusto, il più velocemente possibile.
L’obiettivo di Scrum è migliorare la comunicazione, il lavoro di squadra e la rapidità di sviluppo. Concetti come sprint, Scrums, backlog e grafici burndown derivano tutti da Scrum.
Perché Scrum?
Una delle principali ragioni della popolarità di Scrum è la sua capacità di aiutare i team a consegnare prodotti e servizi di alta qualità in modo rapido ed efficiente. Suddividendo i progetti in piccoli blocchi gestibili e revisionando regolarmente i progressi, i team possono identificare e affrontare rapidamente eventuali problemi. Questo permette loro di restare in linea con gli obiettivi e rispettare le scadenze.
Un ulteriore motivo per cui Scrum è stato adottato risiede nell’enfasi sulla collaborazione e sulla comunicazione. In un ambiente Scrum, i membri del team sono incoraggiati a lavorare insieme e condividere idee, invece di seguire una gerarchia rigida. Questo può favorire senso di appartenenza e responsabilità, che aiutano i team a mantenersi motivati e coinvolti.
In generale, l’adozione di Scrum è stata guidata dalla sua capacità di aiutare organizzazioni e team a raggiungere gli obiettivi in modo rapido ed efficiente. Rendendo i team autonomi nell’organizzare il lavoro e nelle decisioni, Scrum può aiutare le organizzazioni a restare competitive e offrire prodotti e servizi di alta qualità.
La mentalità centrale di Scrum: Il Manifesto Agile
Il Manifesto Agile è fondamentale per la metodologia Scrum e può essere considerato la mentalità di base di tutte le metodologie agili. La metodologia Scrum si innesta sul Manifesto Agile, fornendo indicazioni pratiche su come perseguire gli obiettivi.
In altre parole, Scrum è una delle molteplici guide operative per ottenere risultati seguendo una mentalità agile. Ecco una panoramica del Manifesto Agile abbinata ad alcuni principi fondamentali di Scrum.
1. Individui e interazioni più dei processi e degli strumenti
Anzitutto, mette l’accento sugli individui e sulle interazioni piuttosto che sui processi e sugli strumenti. La comunicazione è la chiave, non i processi che gestiscono il progetto. All’interno di Scrum ciò significa il team auto-organizzato e cross-funzionale.
2. Software funzionante più che documentazione esaustiva
C’è un forte focus sulla produzione rapida di prodotti pronti per la consegna, anziché investire molto tempo nella stesura dei requisiti. Nello sviluppo software con Scrum, si lavora in sprint a tempo prefissato, producendo a ogni sprint un incremento pronto per la consegna.
3. Collaborazione con il cliente più della negoziazione dei contratti
I valori Agile specificano la collaborazione con il cliente o committente, lavorando insieme al cliente in ogni fase, con un coinvolgimento attivo lungo tutto il processo. Scrum prevede un coinvolgimento costante e regolare del cliente.
4. Rispondere al cambiamento anziché seguire un piano
Invece di vedere i cambiamenti come un nemico, essere in grado di considerarli come qualcosa di positivo e reagire prontamente a essi è un principio fondamentale dell’approccio agile. Scrum si basa su requisiti in continua evoluzione e il cambiamento viene accolto con favore.
Oltre al Manifesto Agile, Scrum a sua volta racchiude cinque valori essenziali affinché persone e team diventino abili nell’operare in modo efficace: impegno, focalizzazione, apertura, rispetto e coraggio.
Questi valori orientano un team agile o un team Scrum su come comportarsi nel proprio lavoro. Le decisioni prese e le azioni intraprese dovrebbero rafforzare questi valori, non sminuirli o comprometterli. Quando messi in pratica in modo efficace, i pilastri empirici di Scrum — trasparenza, ispezione e adattamento — prendono vita, costruendo fiducia.
Quali sono i 3 artefatti di Scrum?
Gli artefatti Scrum comunicano informazioni chiave che il team Scrum deve conoscere durante lo sviluppo del prodotto.
1. Product Backlog
Il product backlog elenca tutte le funzionalità, le funzionalità e i requisiti che devono essere inclusi nel prodotto, in ordine di importanza. È normale che i requisiti di un prodotto cambino durante lo sviluppo, sia per riflettere esigenze aziendali che tendenze di mercato. Il product backlog viene costantemente aggiornato per riflettere tali cambiamenti.
2. Product Backlog Item
Questi sono gli elementi che compongono un product backlog. Descrivono le modifiche che devono essere apportate e il risultato desiderato. Un modo per esprimere il risultato desiderato, in modo che il team di sviluppo lo comprenda, è utilizzare le “user story”: una semplice frase che spiega cosa cerca un utente o un’azienda nel prodotto.
Le user story sono strutturate così: “Come [blank] voglio [blank] così da poter [blank].”
3. Sprint Backlog
Lo sprint backlog è composto dagli elementi del product backlog selezionati per uno sprint. Include anche un piano per produrre un incremento al termine dello sprint.
Lo sprint backlog definisce il lavoro che il team di sviluppo svolgerà durante lo sprint successivo e gli elementi necessari a produrre un incremento che rispetti la definizione di fatto.

Il framework Scrum
Il framework Scrum è una metodologia agile incentrata sull’erogazione di valore in modo incrementale e iterativo nel tempo. Il processo inizia con il product owner che crea il product backlog sulla base degli input provenienti da dirigenti, team, stakeholder, clienti e utenti, e termina con la presentazione del lavoro completato durante la sprint review, seguita dalla retrospettiva dello sprint. Questo ciclo si ripete a intervalli regolari, tipicamente da 1 a 4 settimane.

Scrum, di per sé e similmente agli eventi scrum, è stato volutamente ideato per essere leggero e semplice. Scrum è facile da apprendere ma può essere difficile da padroneggiare. È pensato per fornire un quadro di riferimento a team interfunzionali che devono risolvere problemi complessi.
In poche parole: Scrum è una metodologia o un processo attraverso cui mettere in pratica la mentalità agile.
Ruoli Scrum
All’interno della metodologia Scrum ci sono ruoli chiaramente definiti.
- Team di sviluppo Scrum
- Scrum master
- Product owner
Questi ruoli aiutano a distinguere il modello Scrum da metodi agili simili come extreme programming, lean o test-driven development.
L’ambiente Scrum favorisce l’utilizzo di piccoli team flessibili di non più di 9 persone che lavorano sul product backlog. Un test empirico per la dimensione del team è se puoi sfamarli con due pizze (sì, parlo sul serio).
Questo equivale tipicamente a 5-9 persone in un team. Le persone dovrebbero essere assegnate a un solo team Scrum alla volta. Questa regola è spesso giustificata da come comunicano i team, da come vengono allineati gli incentivi e da quante relazioni una persona può mantenere contemporaneamente.

1. Team di Sviluppo Scrum
Un team di sviluppo Scrum è un gruppo di professionisti responsabili della consegna di un incremento rilasciabile di "completato" alla fine di ogni Sprint.
I team di sviluppo sono unici per i seguenti motivi:
- I team di sviluppo sono auto-organizzati. Nessuno all'interno del team Scrum (nemmeno lo Scrum master) è autorizzato a dire loro come trasformare il product backlog in incrementi.
- Sono cross-funzionali. Tutti i membri devono avere le competenze richieste per creare un incremento; alcuni possono avere competenze diverse, ma tutti dovrebbero essere in grado di contribuire.
- Sono responsabili dei successi e dei fallimenti come squadra. Non importa se un membro ha commesso un errore che ha portato il team a non avere un incremento alla fine di uno sprint, il team di sviluppo accetta la responsabilità come un tutto.
2. Scrum Master
Lo Scrum master è responsabile della facilitazione del processo Scrum. Si assicura che tutti abbiano una solida comprensione dei principi Scrum e offre guida e formazione quando necessario.
Lo Scrum master guida il team Scrum durante lo Scrum giornaliero. Spesso pone tre domande:
- Cosa hai fatto ieri?
- Cosa farai domani?
- Quali ostacoli hai davanti?
Lo Scrum master non è il leader o il responsabile delle persone di un team Scrum. Non è direttamente responsabile dei risultati. L'intero team nel suo insieme deve accettare la responsabilità per il prodotto finale.
Lo Scrum master lavora anche con il product owner per assicurarsi che il progetto sia sulla giusta strada.
Svolge compiti come:
- Garantire che gli obiettivi Scrum siano compresi da tutti.
- Ottimizzare la gestione del product backlog.
- Organizzare gli eventi Scrum
- Aiutare a rimuovere gli ostacoli quando si presentano
Il compito dello Scrum master è mantenere tutti concentrati e diretti verso lo stesso obiettivo. Ha il compito di rimuovere ostacoli, prevenire distrazioni inutili e aiutare il team a fare progressi giorno dopo giorno. Anche se il risultato dello Scrum dipende dall'intero team, spesso gli Scrum master sentono molta pressione a riuscire nel loro ruolo.
3. Product Owner
Il product owner rappresenta l'azienda o la base clienti. È presente per assicurarsi che gli altri membri del team Scrum non dimentichino lo scopo dello sprint. Vista la grande varietà di possibili utenti aziendali e clienti, il product owner deve avere una solida comprensione delle esigenze degli utenti.
Ogni sprint inizia con il product owner che documenta e dà priorità ai requisiti e alle funzionalità desiderate del prodotto per il team di sviluppo. In una sessione di pianificazione, il compito del product owner è rispondere a qualsiasi domanda che il team di sviluppo possa avere riguardo a specifiche e requisiti.
Il product owner non è coinvolto nello sviluppo, ma può essere chiamato a rispondere a domande di chiarimento nel corso di ogni sprint.
Le responsabilità quotidiane di un product owner possono includere:
- Documentare i requisiti del prodotto
- Scrivere iniziative, epiche e user stories
- Sincronizzarsi con il product management per assicurarsi che i requisiti del prodotto siano allineati con la roadmap generale del prodotto
- Ricercare le esigenze dei clienti e utenti reali del prodotto
- Rispondere alle domande di chiarimento del team di sviluppo
- Collaborare con i leader di tutta l'organizzazione per garantire che il loro prodotto possa essere venduto, implementato, supportato, ecc.
I product owner sono essenziali per un ciclo di sviluppo prodotto di successo nella metodologia Scrum. Senza requisiti chiari e prioritizzati, i team di sviluppo potrebbero non sapere cosa sviluppare in quale ordine. I product owner garantiscono che i team di sviluppo sappiano cosa è più importante su cui lavorare ora e cosa arriverà dopo.

Eventi Scrum (alias Cerimonie Scrum)
Esistono 5 principali tipi di eventi Scrum o cerimonie Scrum:
- Lo sprint
- Pianificazione dello sprint
- Daily Scrum (chiamata anche riunione quotidiana stand-up)
- Revisione dello sprint
- Retrospettiva dello sprint
Alcuni tipi di eventi Scrum si svolgono in momenti specifici del processo di sviluppo. Sono anche chiamati cerimonie Scrum.
1. Lo Sprint
Uno sprint in Scrum è un periodo di tempo di lunghezza fissa, di un mese o meno, in cui le idee vengono trasformate in valore. Lo sprint è il cuore pulsante di Scrum. Uno sprint è una durata fissa che si ripete costantemente. Spesso i team misurano il loro futuro attraverso gli sprint.
Lo scopo dello sprint è quello di delimitare il tempo di lavoro e portare i team a rispettare gli impegni presi. Gli sprint permettono di fissare obiettivi a breve termine ma molto solidi. Durante uno sprint, nulla dovrebbe cambiare che possa mettere a rischio l’obiettivo dello sprint.
Lo sprint mantiene il team focalizzato, ma permette anche di correggere la rotta o di apportare modifiche tra uno sprint e l’altro. Gli sprint consentono prevedibilità assicurando che ciò che il team di sviluppo si impegna a realizzare venga completato o revisionato in un periodo di tempo breve.
Con gli sprint, il “vedremo quando succederà” non esiste più. Sappiamo quando le cose avverranno perché sono inserite o non inserite nello sprint.
Uno sprint dura da 1 a 4 settimane, non di più. Questo limite consente ai team di agire rapidamente e fornire progressi incrementali senza impazzire. Gli sprint non possono essere allungati né abbreviati. Uno sprint può essere annullato solo se il suo obiettivo diventa obsoleto. Solo il product owner ha l’autorità di annullare uno sprint.
2. Pianificazione dello Sprint

Durante un evento di pianificazione dello sprint, il team concorda la serie di elementi del backlog che intende completare nello sprint successivo.
Per ogni settimana di sprint, si riserva un’ora per la pianificazione dello sprint. La riunione di pianificazione dello sprint si svolge prima dell’inizio dello sprint, quindi se lo sprint è di 4 settimane il team riserverà quattro ore per l’incontro.
La parte più importante di una riunione di pianificazione dello sprint è la preparazione che deve avvenire prima dell'inizio della riunione. Il product owner si presenta con un backlog prioritizzato di user story e funzionalità che desidera far realizzare al team di sviluppo.
Nella riunione di pianificazione dello sprint, il team di sviluppo e il product owner si allineano esattamente su ciò che si desidera ottenere e su quanto tempo si prevede serva per soddisfare tali requisiti.
Quali e quanti elementi del backlog saranno completati dipende dall’impegno del team e dalla sua velocità (la rapidità con cui il team di sviluppo può creare incrementi). Se pianifichi con un nuovo team, è meglio non calcolare la velocità prevista finché non si sono fatti alcuni sprint insieme.
3. Daily Scrum
Ogni giorno si svolge una riunione di Daily Scrum in cui i membri del team discutono i progressi compiuti e i problemi riscontrati, con l'obiettivo di celebrare i risultati, allineare il lavoro in corso e rimuovere rapidamente gli ostacoli per mantenere tutti in movimento.
Le riunioni Scrum avvengono ogni giorno durante uno sprint. Non dovrebbero durare più di quindici minuti e devono essere molto focalizzate a mantenere il team in movimento.
Le sessioni di Daily Scrum si tengono tutti i giorni per evitare che i problemi si accumulino in background. Eventuali domande o preoccupazioni dovrebbero essere sollevate nella riunione quotidiana.
4. Revisione dello Sprint
La riunione di revisione dello sprint si svolge alla fine dello sprint con lo scopo esplicito di esaminare i progressi raggiunti. Durante la revisione, il product owner verifica se i risultati corrispondono alle aspettative definite nella pianificazione dello sprint. Qui il product owner verifica che l’incremento di lavoro soddisfi la definizione di completato.
5. Retrospettiva dello Sprint
Una riunione di sprint retrospective permette al tuo team di riflettere sugli eventi e le situazioni passate. Secondo la Scrum Guide, la sprint retrospective è una “opportunità per il team Scrum di auto-ispezionarsi e creare un piano per miglioramenti da attuare durante lo sprint successivo.” Ha senso, soprattutto considerando che il fulcro dello sviluppo agile è il miglioramento continuo. Per migliorare, bisogna sapere quale spada affilare.
La retrospective dovrebbe creare un ambiente sicuro affinché le persone possano condividere onestamente i loro feedback su ciò che sta andando bene, cosa potrebbe essere migliorato e generare una discussione su cosa cambiare la prossima volta — con elementi concreti documentati.
Pianificare i progetti con la metodologia Scrum
La metodologia Scrum può essere utilizzata per progetti di diverse dimensioni ed è basata sul principio dello sviluppo agile, che enfatizza la necessità di flessibilità e capacità di risposta ai cambiamenti.
Il primo passo nell’uso della metodologia Scrum è creare un product backlog prioritizzato. Il product backlog è una lista di tutte le attività da completare per raggiungere l’obiettivo del progetto. Le attività possono essere aggiunte al product backlog in qualsiasi momento e possono essere prioritarizzate in base all’importanza.
Una volta creato il product backlog, il passo successivo è creare uno sprint backlog. Lo sprint backlog contiene una lista delle attività che saranno completate durante uno specifico sprint, o periodo di tempo. Le attività presenti nello sprint backlog dovrebbero essere scelte tra quelle più importanti e urgenti del product backlog.
Per assicurare che le attività vengano completate in modo efficiente ed efficace, la metodologia Scrum utilizza una serie di linee guida specifiche che aiutano a mantenere tutto gestibile. Le linee guida includono:
- Le attività dovrebbero essere suddivise in parti piccole e gestibili
- Le attività dovrebbero essere assegnate a specifici membri del team
- I membri del team dovrebbero riunirsi regolarmente per aggiornarsi reciprocamente sui loro progressi
- Il team deve sempre concentrarsi sul completamento delle attività più importanti prima di tutto
Una volta che un team inizia a sviluppare e fornire valore con la metodologia Scrum, il ciclo degli sprint sarà ripetuto. È responsabilità del product owner assicurare che le user story e le richieste di funzionalità siano pronte per il team di sviluppo, in modo che abbiano sempre qualcosa su cui lavorare. Lo Scrum master aiuta a mantenere il team in movimento in modo allineato e ordinato.
Seguendo le linee guida della metodologia Scrum, i team possono essere più produttivi ed efficienti mentre lavorano per completare il progetto. La flessibilità dell’approccio consente rapidi aggiustamenti quando necessario, mantenendo i progetti in carreggiata e nei tempi previsti. Scrum inoltre incoraggia il lavoro di squadra, la collaborazione e la comunicazione tra i membri del team, il che aiuta a garantire risultati di successo.
Vantaggi della metodologia Scrum
La metodologia Scrum è una tecnica agile di gestione di progetti o prodotti che aiuta i team a lavorare in modo più efficiente ed efficace. È un approccio semplice ma potente che può essere utilizzato nello sviluppo software, nella progettazione di prodotti, nei progetti di marketing e altro ancora.
Alcuni dei vantaggi nell’uso della metodologia Scrum includono:
- Aumento della produttività: Quando i team riescono a lavorare in brevi intervalli di tempo chiamati "sprint", solitamente riescono a ottenere più risultati rispetto a quando lavorano al progetto su un periodo di tempo più lungo.
- Aumento della collaborazione: La metodologia Scrum incoraggia i membri del team a lavorare insieme per raggiungere obiettivi comuni. Questo può aiutare a ridurre i malintesi e migliorare la comunicazione.
- Maggiore flessibilità: La metodologia Scrum è flessibile e può essere adattata alle specifiche esigenze del team di progetto. Questo può aiutare a garantire che il progetto dia priorità al completamento degli elementi più importanti, pur mantenendo gli impegni di costo e tempi.
- Qualità migliorata: Utilizzando sprint brevi, i team possono concentrarsi sul completare compiti specifici assicurando la massima qualità possibile. Questo aiuta a evitare errori costosi e a migliorare la qualità complessiva del prodotto o servizio finale.
Una breve storia di Scrum
- 1986: Hirotaka Takeuchi e Ikujiro Nonaka pubblicarono "New New Product Development Game" su Harvard Business Review e coniarono la parola "Scrum" per un uso al di fuori del gioco del rugby.
- 1995: Jeff Sutherland e Ken Schwaber presentarono Scrum all'OOPSLA.
- 2001: Sutherland, Schwaber e altri 15 sviluppatori crearono il "Manifesto per lo Sviluppo Agile", comunemente chiamato "Agile Manifesto". L'Agile Alliance fu fondata e riconobbe Scrum come uno dei metodi agili.
- 2002: Schwaber pubblicò "Agile Software Development with Scrum" con Mike Beedle, fondò la Scrum Alliance e iniziò a offrire certificazioni Scrum.
- 2004: Schwaber pubblicò "Agile Project Management with Scrum", a cui hanno fatto seguito altri libri e guide sull'applicazione di Scrum in diversi contesti.
- 2007: Viene sviluppato il Scaled Agile Framework, conosciuto come SAFe.
- 2014: Il dott. Dave Cornelius, riconosciuto catalizzatore Lean e Agile, presentò la sua ricerca dottorale basata sulla metodologia Scrum, concentrandosi su "Il valore di Scrum per le organizzazioni".
- Dal 2014 in poi, Scrum è stato applicato a nuovi contesti, inclusi quelli di grandissima scala in tutto il mondo.
Scrum: In confronto
Scrum vs Agile
In breve, agile è una mentalità, mentre Scrum è una delle molte metodologie che sfruttano questa mentalità. Scrum si colloca sotto l'ombrello di agile come mentalità, affiancato da molte altre metodologie orientate all'agile come extreme programming, lean, Kanban, SAFe, sviluppo guidato dai test, crystal e altre.

La differenza tra Scrum e agile è che Scrum è un piano o una guida pratica per implementare processi allineati con la mentalità agile. Lo sviluppo software agile con Scrum è uno degli approcci più diffusi allo sviluppo.
Leggi di più sulle differenze tra waterfall e agile in modo più ampio qui.
Scrum vs Kanban
Esistono anche altri modi per implementare agile. Ad esempio, un altro approccio popolare è Kanban, che si differenzia da Scrum in quanto non richiede ruoli chiaramente definiti, non prevede sprint con durata fissa e accetta modifiche al workflow agile in qualsiasi fase dello sviluppo.
La chiave di Kanban è limitare il numero di attività in corso in un determinato momento. Il limite al lavoro in corso (WIP) costringe i team a concentrarsi e completare ciò che hanno iniziato, poiché non è permesso iniziare nuove attività finché quelle vecchie non sono terminate (questo rende la pianificazione della capacità in Kanban abbastanza semplice). Puoi riconoscere un team Scrum dai suoi "sprint" mentre puoi identificare un team Kanban vedendo i limiti sul lavoro in corso.
Potresti vedere un team Scrum usare una Kanban board (che letteralmente significa tabellone) per mostrare visivamente le attività per stato—va benissimo! L'uso della Kanban board non invalida Scrum, a patto che ruoli, eventi e time-box rimangano in uso.
Leggi di più sulle differenze tra Scrum e Kanban qui.

Software per Scrum
Scrum e gli strumenti Scrum non sono solo per i team di sviluppo software, anche se è lì che Scrum ha avuto origine. Il framework Scrum può essere utilizzato in molti ambienti produttivi—dalle agenzie di marketing alle imprese edili.
Ecco alcuni dei migliori software per la gestione di progetti agili con funzionalità come backlog e pianificazione degli sprint che ti aiutano a seguire la metodologia Scrum.
Clicks on the links below may earn a commission, which supports our independent testing and review of software and services. Learn more about how we stay transparent.
Approfondisci le recensioni di questi strumenti—con schermate, valutazioni e informazioni sui prezzi—nella recensione dei software Scrum e nella recensione degli strumenti Scrum.
Le migliori risorse Scrum
- Scrum Guides: La guida ufficiale (e GRATUITA) al Body of Knowledge di Scrum. Scritta dai co-creatori di Scrum, Ken Schwaber e Jeff Sutherland.
- Scrum.org: Un'organizzazione professionalmente riconosciuta che offre formazione e certificazioni agile ufficiali come Professional Scrum Masters, Professional Scrum Product Owners e Professional Scrum Developers.
- Scrum Alliance: Un'organizzazione che insegna Scrum a persone di tutti i livelli di esperienza. Offre anche formazione e certificazioni come Certified Scrum Masters, Certified Product Owners e Certified Scrum Developers.
- Scrum Inc: Fondata da Jeff Sutherland, il co-creatore di Scrum, che aggiorna regolarmente il blog. Offre formazione e certificazione.
- Atlassian: Azienda australiana di software enterprise che fornisce guide dettagliate e verificate sulle metodologie agile, incluso Scrum.
- Visual Paradigm Scrum Guides: Un grande database di articoli su tutto ciò che riguarda Scrum, da definizioni di base alla risoluzione di problemi specifici.
Potresti anche voler dare un'occhiata a questi corsi su Scrum.
Glossario Scrum
Per chi non è esperto, Scrum può sembrare intimidatorio. Ecco una panoramica di alcuni termini comunemente usati.
Ecco una lista di termini Scrum a cui puoi fare riferimento in qualsiasi momento:
- Agile: La mentalità e l’approccio sotto il quale è stata sviluppata la metodologia Scrum. Promuove l’adattamento e la flessibilità rispetto a una struttura rigida.
- Burndown chart: Un grafico che mostra la quantità di lavoro che rimane nel product backlog.
- Burn-up chart: Un grafico che mostra la quantità di lavoro completata dal product backlog.
- Daily Scrum: Riunione che si tiene ogni giorno, nella quale vengono dedicati quindici minuti per pianificare la giornata di lavoro.
- Definition of done: L’aspettativa che un incremento deve soddisfare per essere considerato rilasciabile.
- Development team: Squadra all’interno del team Scrum che gestisce, organizza ed esegue il lavoro di sviluppo richiesto per creare un incremento.
- Empiricism: Controllo di processo che afferma che solo il passato è certo. Consente la massima flessibilità all’interno del framework agile. Valorizza trasparenza, ispezione e adattamento.
- Engineering standards: Insieme di standard condivisi tra i team per garantire la qualità degli incrementi.
- Forecast of functionality: L’insieme di incrementi estratti dal product backlog che il team di sviluppo ritiene possibile completare in uno sprint.
- Increment: Una parte di software che può essere aggiunta ad altri incrementi. Insieme, un numero sufficiente di incrementi costituisce un prodotto.
- Product backlog: Un elenco (tipicamente ordinato) del lavoro che deve essere svolto per creare un prodotto.
- Product owner: Membro del team Scrum incaricato di massimizzare il valore di un prodotto.
- Scrum board: Un modo semplice per visualizzare le informazioni condivise tra il team Scrum.
- Scrum Guide: La definizione originale di Scrum. La guida dettaglia i ruoli, gli eventi, gli artefatti e le regole di Scrum.
- Scrum master: Responsabile della guida del team Scrum. Si assicura che tutti abbiano una solida comprensione dei principi Scrum. Offre guida e formazione quando necessario.
- Scrum values: I valori fondamentali che guidano il framework Scrum. Questi sono: impegno, concentrazione, apertura, rispetto e coraggio.
- Self-organization: Principio cardine di Scrum secondo cui i team devono organizzare autonomamente il proprio lavoro senza interferenze da parte di team esterni.
- Sprint: Periodo di tempo di un mese o meno in cui si svolgono gli eventi Scrum. Gli sprint si susseguono senza interruzione.
- Sprint goal: Lo scopo dello sprint attuale.
- Sprint retrospective: Riunione, della durata massima di tre ore, in cui il team dello sprint si confronta e discute gli eventuali miglioramenti da implementare nel prossimo sprint.
- Sprint review: Riunione, della durata massima di quattro ore, che rappresenta la conclusione di uno sprint. Il lavoro svolto viene rivisto e gli stakeholder esaminano l’incremento per garantire che risponda alla definition of done.
- Stakeholder: Persona esterna al team Scrum. Fornisce un punto di vista esterno ed è attivamente coinvolto nelle sprint review.
E ora?
Vuoi entrare in contatto con altri project manager digitali per condividere risorse e buone pratiche? Unisciti alla nostra community di membership e accedi a oltre 100 template, esempi e modelli, e collegati con centinaia di altri project manager digitali su Slack.
