Guida per superare l’esame Scrum Master

Cos’è Scrum: definizione e contesto del framework agile

Scrum è un framework agile per sviluppare, fornire e sostenere prodotti complessi, basato su empirismo e iterazioni brevi (Scrum Guide 2020). Non è una metodologia rigida con passi predefiniti da seguire uno dopo l’altro. È qualcosa di diverso: una struttura leggera che dà al team abbastanza forma per lavorare bene insieme, lasciando però spazio alle pratiche che funzionano meglio nel contesto specifico.

Questa distinzione non è un dettaglio tecnico. È il cuore di tutto.

Chi si avvicina a Scrum per la prima volta spesso si aspetta un manuale operativo, una lista di istruzioni da eseguire. E invece si ritrova tra le mani qualcosa di più simile a un campo da gioco con regole chiare, dentro il quale il team decide come muoversi. Gli stakeholder ispezionano i risultati alla fine di ogni Sprint e adattano il lavoro per quello successivo: non c’è un piano fisso scritto a inizio anno che nessuno osa toccare. Il feedback è continuo, e il valore viene rilasciato presto, così i rischi si gestiscono prima che diventino problemi.

Origine del nome e anno di nascita

Il nome Scrum non è un acronimo. Non sta per niente. Deriva dallo scrum del rugby, quella mischia compatta in cui il gruppo si stringe insieme per riconquistare il pallone, coordinandosi, senza che nessuno diriga dall’esterno. L’immagine è precisa: un team piccolo, cross-funzionale, che si autoorganizza per raggiungere un obiettivo condiviso.

Scrum è stato introdotto ufficialmente nel 1995 da Ken Schwaber e Jeff Sutherland, che presentarono il framework alla OOPSLA Conference. Ma il lavoro alle spalle era cominciato prima, nei primi anni Novanta, quando i due iniziarono a sperimentare approcci iterativi per lo sviluppo software. Tra quei due momenti, c’è quasi un decennio di pratica sul campo.

Nei miei anni di formazione su framework agili ho notato che molti candidati all’esame scrum conoscono il 1995 come dato di memoria, ma non capiscono perché è importante. Sapere che Scrum nasce dall’empirismo, non dalla teoria, cambia il modo in cui si risponde alle domande situazionali. E nell’esame, sono proprio quelle a fare la differenza.

Scrum come framework, non metodologia

La Scrum Guide aggiornata nel 2020 da Schwaber e Sutherland è il documento ufficiale di riferimento. È scaricabile gratuitamente da scrum.org ed è di circa tredici pagine. Tredici pagine per descrivere qualcosa che molti team fanno fatica a padroneggiare in anni. Ecco perché Scrum è semplice da capire e difficile da applicare bene, come recita spesso chi lo insegna.

Ma torniamo alla distinzione che conta: framework contro metodologia. Una metodologia dice cosa fare e come farlo, passo dopo passo. Un framework dice quali elementi ci sono, come si relazionano, e poi lascia che il team decida il resto. Scrum definisce ruoli (Product Owner, Scrum Master, Developers), eventi (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) e artefatti (Product Backlog, Sprint Backlog, Incremento). Tutto il resto è a carico del team.

Anzi, è proprio in quel “resto” che si gioca la vera competenza di uno Scrum Master. Non nell’applicare le regole a memoria, ma nel capire quando il framework sta funzionando e quando qualcosa va sistemato. A mio avviso, chi studia Scrum solo come lista di definizioni da memorizzare si prepara male, sia per il lavoro sia per il test scrum master.

Tutto sommato, Scrum è uno dei framework agili più usati al mondo proprio perché non chiede di buttare via tutto e ricominciare da zero. Chiede di ispezionare, adattare, imparare. Sprint dopo Sprint.

Perché studiare Scrum è diventato complicato per chi lavora full-time

Studiare Scrum sembra semplice sulla carta: il framework si descrive in poche pagine. Ma l’esame ti chiede di applicarlo, non di ripeterlo. E questa differenza, apparentemente sottile, è esattamente dove la maggior parte delle persone si inceppa.

Materiale ufficiale frammentato tra Scrum Guide e fonti terze

La Scrum Guide 2020 ha 13 pagine totali. Tredici. A prima vista sembra un vantaggio enorme rispetto ad altri framework che richiedono manuali da centinaia di pagine. In realtà è quasi il contrario: ogni singola parola conta, ogni distinzione tra ruoli e responsabilità è carica di significato preciso, e non c’è spazio per approssimazioni.

Il problema nasce subito dopo. Chi studia per il test Scrum apre la Scrum Guide, la legge in un’ora, e poi comincia a cercare approfondimenti. Trova articoli di blog, video su YouTube, slide di corsi universitari, guide aziendali. Ognuna di queste fonti interpreta il framework in modo leggermente diverso, aggiunge sfumature, talvolta contradice la fonte ufficiale. A quel punto nella testa del candidato si forma un quadro confuso, un mosaico di definizioni che non tornano.

Tra i candidati che ho seguito negli ultimi anni ho visto questo schema ripetersi quasi sempre: studiano tanto, ma studiano cose diverse. Arrivano all’esame Scrum convinti di essere pronti, e invece scoprono che le domande presuppongono una lettura precisa e coerente del solo testo ufficiale.

La Scrum Guide è la fonte. Il resto è commento. E confondere i due livelli costa caro.

Esami PSM I e CSM con domande situazionali

Il PSM I (Professional Scrum Master I, certificazione rilasciata da Scrum.org) è strutturato in 80 domande da rispondere in 60 minuti, con una soglia di superamento dell’85%. In soldoni: puoi sbagliare al massimo una dozzina di domande. Margine quasi zero.

Ma il vero ostacolo non è la velocità. È il tipo di domanda.

L’esame Scrum non ti chiede di definire cos’è uno Sprint Backlog o quante persone compongono un team di Developers. Ti mette davanti a uno scenario concreto: uno Scrum Master che deve gestire un conflitto tra il Product Owner e i Developers, oppure un team che non riesce a rispettare la Definition of Done. E tu devi scegliere come agiresti, non cosa dice la guida.

Questo cambia tutto nel modo in cui bisogna prepararsi. Studiare le definizioni a memoria non basta. Anzi, chi si prepara solo così rischia di selezionare la risposta “tecnicamente corretta” invece di quella “situazionalmente corretta”, e le due non coincidono sempre. Personalmente trovo che questa distinzione sia la parte più difficile da interiorizzare senza fare pratica su scenari reali.

E qui emerge il nodo più concreto per chi lavora full-time: la sera, dopo otto ore in ufficio, non hai la lucidità per leggere uno scenario complesso e ragionare sui sottotesti. Hai bisogno di fare una simulazione, vedere dove sbagli e capire subito perché. Senza feedback immediato, ogni sessione di studio sera è tempo speso senza direzione.

L’errore più frequente al primo tentativo del test Scrum master? Confondere ruoli e responsabilità. Molti candidati assegnano allo Scrum Master compiti che spettano al Product Owner, o viceversa. Oppure attribuiscono ai Developers un’autonomia che la Scrum Guide riconosce esplicitamente, ma che lo studente aveva letto come “responsabilità condivisa generica”. Basta una sfumatura sbagliata per rispondere male a un’intera categoria di domande situazionali. E con una soglia all’85%, quelle sfumature costano il superamento dell’esame.

Quali sono i 3 pilastri e i 5 valori che reggono Scrum?

I tre pilastri di Scrum sono trasparenza, ispezione e adattamento: senza uno di questi, il framework smette di funzionare (Scrum.org). Non è una frase ad effetto. È una constatazione concreta che si capisce meglio guardando cosa succede quando uno dei tre manca.

I 3 pilastri: trasparenza, ispezione, adattamento

La trasparenza significa che tutti i membri del team, e anche gli stakeholder, vedono lo stesso stato del lavoro. Non versioni diverse, non interpretazioni personalizzate. Lo stesso. Questo include il Product Backlog, lo Sprint Backlog, la Definition of Done. Se due persone del team hanno una lettura diversa di quanto lavoro resta, Scrum ha già un problema.

L’ispezione è il secondo pilastro. Gli artefatti e l’avanzamento del lavoro vengono verificati frequentemente, non alla fine del progetto. In soldoni: si guarda spesso cosa sta succedendo, così i problemi emergono presto. La Sprint Review, ad esempio, è esattamente questo: il momento in cui gli stakeholder ispezionano i risultati dello Sprint e valutano se il lavoro prodotto è quello che serve davvero.

Poi c’è l’adattamento. Quando dall’ispezione emergono deviazioni rispetto all’obiettivo, il team corregge la rotta. Subito. Non aspetta la fine del trimestre. Scrum incoraggia feedback continui e rilascio di valore precoce proprio per questo: gestire il rischio prima che diventi un costo enorme.

Nei corsi che ho seguito su questo argomento, ho visto spesso candidati che memorizzano i tre nomi senza capire il legame tra loro. Eppure il legame è tutto. Trasparenza senza ispezione è cieca. Ispezione senza adattamento è inutile. E adattamento senza trasparenza è, alla fine, caos organizzato.

I 5 valori Scrum

I 5 valori Scrum definiti da Scrum.org sono: commitment, courage, focus, openness e respect. Se i tre pilastri sono la struttura portante, i valori sono la cultura che tiene in piedi quella struttura.

• Commitment (impegno): ogni membro del team si impegna verso gli obiettivi dello Scrum Team, non solo verso i propri task personali.
• Courage (coraggio): ci vuole coraggio per dire che una user story non è chiara, per sollevare un problema in retrospettiva, per dire no a richieste fuori scope.
• Focus (concentrazione): durante lo Sprint, il team si concentra sul lavoro dello Sprint. Non su tutto. Sul lavoro dello Sprint.
• Openness (apertura): il team è aperto riguardo al proprio lavoro e alle difficoltà. Ma, a mio avviso, questo è il valore più sottovalutato dai candidati all’esame scrum.
• Respect (rispetto): i membri del team si rispettano come professionisti competenti e capaci.

Questi cinque valori non sono decorativi. Reggono ogni cerimonia, ogni decisione, ogni conversazione difficile all’interno del team. Un team che non ha courage non farà mai una retrospettiva utile. Un team senza openness nasconde i problemi finché non esplodono.

Per chi si prepara al test scrum master, la domanda concreta è questa: sai collegare ogni valore a una situazione reale dello Sprint? Perché l’esame scrum non chiede di recitare definizioni. Chiede di capire cosa farebbe uno Scrum Master quando il focus del team si perde, o quando la trasparenza sugli artefatti è carente. Alla fine della fiera, è su questo livello di comprensione che si vince o si perde.

I 3 ruoli dello Scrum Team: Product Owner, Scrum Master e Developers

Uno Scrum Team è composto da Product Owner, Scrum Master e Developers: tre ruoli, una sola responsabilità collettiva sul prodotto (Scrum.org). Non è una gerarchia. Non è una struttura aziendale tradizionale. È un’unità pensata per consegnare valore in modo continuo, Sprint dopo Sprint, senza bisogno di approvazioni a cascata che rallentano tutto.

Capire bene cosa fa ciascun ruolo, e soprattutto cosa NON fa, è una delle cose che distingue chi supera il test Scrum da chi ci rimane impantanato. Ho visto candidati ben preparati sulla teoria fallire domande pratiche proprio perché confondevano le responsabilità tra Product Owner e Scrum Master. Quindi andiamo al sodo.

Cosa fa (e cosa NON fa) il Product Owner

Il Product Owner, spesso abbreviato PO, è la persona responsabile del valore del prodotto. Punto. Gestisce il Product Backlog, quella lista ordinata per priorità di lavoro ad alto livello allineata al Product Goal, e decide cosa entra, cosa esce e in quale ordine si lavora. Gli stakeholder possono influenzarlo, ma la decisione finale è sua.

Ma è qui che molti fanno confusione: il PO non assegna compiti ai Developers. Non dice a nessuno come fare il lavoro tecnico. Non entra nel merito di come una funzionalità viene implementata. Eppure all’esame Scrum trovi domande costruite apposta per farti scegliere risposte in cui il PO scavalca i Developers o gestisce il team come un project manager classico. Sbagliato. Sempre.

Il PO collabora con gli stakeholder, raffina il backlog, chiarisce i requisiti. E partecipa alla Sprint Review, quel momento in cui il team mostra agli stakeholder le funzionalità completate e si raccoglie feedback per adattare il lavoro dello Sprint successivo. Ma non comanda.

Lo Scrum Master come facilitatore

Lo Scrum Master, o SM, è forse il ruolo più frainteso di tutto il framework. Non è il capo del team. Non è un project manager rinominato. Non è nemmeno un coordinatore nel senso tradizionale.

È un facilitatore. Il suo lavoro è rimuovere gli impedimenti che bloccano i Developers, proteggere il team da interferenze esterne, aiutare tutti a capire e applicare Scrum correttamente. Serve il team, non lo gestisce. Serve l’organizzazione, aiutandola ad adottare pratiche agili. E a volte questa distinzione sembra sottile sulla carta, ma nelle domande del test scrum master diventa la differenza tra risposta giusta e risposta sbagliata.

Anzi, uno degli errori classici è pensare che lo SM debba decidere le priorità del backlog quando il PO non è disponibile. Falso. Non è suo compito. Né potrebbe farlo senza tradire il principio base del ruolo.

I Developers e l’auto-organizzazione

I Developers sono il cuore operativo dello Scrum Team. Secondo la University of Wisconsin Scrum Quick Reference (2022), si tratta di un gruppo piccolo e cross-funzionale, idealmente co-locato, composto da 3 a 8 persone. Cross-funzionale vuol dire che il team ha, al suo interno, tutte le competenze necessarie per consegnare un Incremento completo e pronto all’uso, senza dipendere da persone esterne.

Ma la cosa più importante, quella su cui l’esame scrum insiste moltissimo, è l’auto-organizzazione. I Developers decidono autonomamente come svolgere il lavoro necessario a raggiungere gli obiettivi dello Sprint. Nessuno assegna i task dall’esterno. Nessuno dice chi fa cosa. Il team sceglie, si organizza, gestisce il proprio Sprint Backlog. Questa autonomia non è un optional del framework: è un principio fondante.

Per i team co-locati, anche strumenti semplici come lavagne e post-it funzionano benissimo. Non serve tecnologia sofisticata per fare Scrum. Serve disciplina, chiarezza sui ruoli e rispetto delle regole del framework.

Tutto sommato, i tre ruoli si bilanciano a vicenda: il PO porta la direzione, lo SM garantisce le condizioni di lavoro, i Developers consegnano. Nessuno può funzionare bene senza gli altri due. E capire questa interdipendenza, a mio avviso, è la chiave per rispondere correttamente alla maggior parte delle domande situazionali dell’esame.

I 5 eventi Scrum: Sprint, Planning, Daily, Review, Retrospective

Scrum prevede 5 eventi: lo Sprint contiene gli altri 4 — Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective (Scrum Guide 2020). Non si tratta di riunioni opzionali da saltare quando si è occupati. Sono la struttura portante del framework, e capire come funzionano è essenziale sia per lavorare in un team Scrum sia per superare qualsiasi test Scrum o esame Scrum Master.

Lo Sprint come contenitore timeboxed

Lo Sprint è un evento timeboxed con durata massima di 1 mese, secondo la Scrum Guide 2020. Può durare meno — due settimane è la durata più diffusa nella pratica — ma non di più. Il punto è che ha un inizio e una fine ben definiti, e dentro quel confine temporale il team lavora su un obiettivo preciso: lo Sprint Goal.

Perché questa rigidità? Perché Scrum incoraggia feedback continui e rilascio di valore precoce per aiutare a gestire il rischio. Uno Sprint breve significa un ciclo di feedback breve. Se qualcosa va storto, lo scopri dopo due settimane, non dopo sei mesi. A conti fatti, è questa la differenza più concreta tra un approccio tradizionale a cascata e il lavoro in Scrum.

Dentro lo Sprint si trova tutto il lavoro necessario a produrre un Incremento, cioè un deliverable concreto che avanzi verso il Product Goal e soddisfi la Definition of Done del team. Niente Sprint, niente Incremento. È così semplice.

Sprint Planning e Daily Scrum

Lo Sprint apre con lo Sprint Planning. Il team si siede insieme — Product Owner, Scrum Master e Developers — e risponde a due domande: cosa si farà in questo Sprint e come lo si farà. Le User Story selezionate dal Product Backlog entrano nello Sprint Backlog, con stime di dettaglio. Da quel momento, lo Sprint è partito.

Il Daily Scrum dura 15 minuti. Esatto: quindici minuti ogni giorno, non di più. Tra i candidati che ho seguito in percorsi di preparazione all’esame Scrum, questo è spesso il punto che sorprende di più — non tanto la durata, quanto il fatto che sia un evento dei soli Developers. Non è una riunione di aggiornamento per il management. I Developers in Scrum sono responsabilizzati a organizzare e gestire il proprio lavoro, e il Daily Scrum è lo strumento con cui lo fanno.

Le tre domande classiche del Daily — cosa ho fatto ieri, cosa farò oggi, cosa mi blocca — non sono obbligatorie come formula nella Scrum Guide 2020. Ma restano un ottimo schema pratico, e nell’esame Scrum le trovi citate spesso come riferimento. Tienilo a mente.

Sprint Review e Sprint Retrospective

La Sprint Review si svolge alla fine dello Sprint. Il team mostra agli stakeholder le funzionalità e le User Story completate: non una presentazione di diapositive, ma un’ispezione concreta del lavoro fatto. Gli stakeholder guardano, fanno domande, danno feedback. E quel feedback adatta il lavoro per lo Sprint successivo. È un momento di collaborazione reale, non una formalità.

Poi viene la Sprint Retrospective. E qui molti team fanno l’errore di trattarla come un optional.

La Retrospective è il momento in cui lo Scrum Team riflette su cosa può funzionare meglio nello Sprint successivo. Non sul prodotto — quello lo si fa nella Review. Qui si parla del modo di lavorare: processi, relazioni, strumenti. Secondo me è l’evento più sottovalutato dell’intero framework Scrum, e spesso la differenza tra un team che migliora davvero e uno che gira in tondo.

In soldoni: Review guarda il cosa è stato fatto, Retrospective guarda il come si è lavorato. Confondere i due è un errore classico nel test Scrum Master, e tenerli distinti in modo netto ti aiuta sia nella pratica quotidiana sia durante l’esame.

I 3 artefatti Scrum: Product Backlog, Sprint Backlog e Incremento

Lo Scrum Team produce tre artefatti: Product Backlog, Sprint Backlog e Incremento, ciascuno con un impegno specifico associato (Scrum.org). Non sono semplici liste o documenti. Sono strumenti vivi, che cambiano sprint dopo sprint, e capire come funzionano davvero è una delle parti più sottovalutate del test Scrum Master.

A conti fatti, chi studia Scrum tende a memorizzare i nomi degli artefatti senza capire il legame con i rispettivi commitment. E poi si trova in difficoltà proprio su quelle domande dell’esame scrum che sembrano semplici ma non lo sono.

Product Backlog e Product Goal

Il Product Backlog è una lista ordinata per priorità di lavoro ad alto livello, con stime ad alto livello, allineata al Product Goal. Chi lo gestisce? Il Product Owner. È lui che decide l’ordine, che aggiorna le priorità, che decide cosa entra e cosa esce. I Developers collaborano alle stime, ma la responsabilità della lista è una sola.

Il commitment associato al Product Backlog è il Product Goal, cioè l’obiettivo a lungo termine verso cui il prodotto si sta muovendo. Ogni voce nel backlog esiste perché avvicina il team a quel goal. Se una voce non lo fa, vale la pena chiedersi perché sia lì.

Personalmente, nei corsi che ho seguito ho visto candidati confondere il Product Goal con lo Sprint Goal. Sono due cose diverse. Il Product Goal è l’orizzonte strategico. Lo Sprint Goal è l’obiettivo tattico dello sprint corrente. Livelli temporali completamente diversi.

E un dettaglio che l’esame scrum ama testare: il Product Backlog non è mai “completo”. Si aggiorna continuamente. Il termine tecnico è refinement.

Sprint Backlog e Sprint Goal

Lo Sprint Backlog contiene le User Story associate alle priorità correnti dello Sprint, con stime di dettaglio. Nasce durante la Sprint Planning. Ma non è immobile: i Developers possono aggiornarlo durante lo sprint, aggiungendo o rimuovendo lavoro secondo quanto imparano giorno per giorno.

Il commitment qui è lo Sprint Goal. È l’obiettivo che dà senso all’intero sprint. In soldoni, le User Story nello Sprint Backlog sono il come; lo Sprint Goal è il perché. Se il team si accorge a metà sprint che alcune User Story non servono più per raggiungere lo Sprint Goal, può rivedere il piano. Scrum incoraggia questo tipo di adattamento continuo.

Una cosa che trovo spesso trascurata: lo Sprint Backlog appartiene ai Developers. Il Product Owner non può modificarlo unilateralmente durante lo sprint. Può negoziare, può chiedere, ma la gestione quotidiana del lavoro è dei Developers stessi. La Scrum Guide è chiara su questo punto.

Incremento e Definition of Done

L’Incremento è un deliverable concreto che avanza verso il Product Goal e deve soddisfare la Definition of Done del team. Ogni sprint produce almeno un Incremento. Può essere rilasciato agli utenti o no, ma deve essere potenzialmente rilasciabile. Questo è un punto che il test Scrum Master verifica spesso.

Il commitment dell’Incremento è la Definition of Done (DoD), cioè l’insieme di criteri condivisi dal team che definiscono quando un lavoro si considera finito davvero. Non “abbastanza finito”. Finito. Se un’attività non soddisfa la DoD, non fa parte dell’Incremento. Punto.

Ma perché questo schema dei tre commitment esiste? Perché ogni artefatto, da solo, rischia di diventare una lista senza direzione. Il Product Goal orienta il Product Backlog nel tempo. Lo Sprint Goal dà coerenza allo Sprint Backlog nel breve. La Definition of Done garantisce che l’Incremento abbia un valore reale e misurabile. Togline uno solo e tutto il sistema perde precisione.

• Product Backlog → commitment: Product Goal
• Sprint Backlog → commitment: Sprint Goal
• Incremento → commitment: Definition of Done

Nell’esame scrum, le domande su questi tre artefatti non riguardano quasi mai la definizione pura. Riguardano i casi limite: cosa succede se lo Sprint Goal diventa irraggiungibile? Chi aggiorna la DoD? Può esistere un Incremento senza Sprint Goal? Studiare i commitment ti prepara esattamente a rispondere a questo tipo di scenario.

Come prepararti alla certificazione Scrum: approccio strutturato vs autodidatta

Prepararsi a una certificazione Scrum significa allenare il ragionamento situazionale, non memorizzare definizioni: l’esame PSM I (Professional Scrum Master I) distingue chi ha capito il framework da chi l’ha solo letto. È una differenza sottile sulla carta, enorme nella pratica. Nei candidati che ho seguito negli ultimi anni, quelli che fallivano non erano i meno preparati in senso assoluto — erano spesso persone che sapevano citare la Scrum Guide a memoria ma si bloccavano davanti a uno scenario reale di team.

Cosa offre davvero la Scrum Guide ufficiale (gratuita)

La Scrum Guide è il documento fondativo del framework, disponibile gratuitamente su scrumguides.org. Tredici pagine. Non di più.

Leggila almeno tre volte, e non tutte di fila. La prima lettura serve a orientarsi: capisci i ruoli, gli eventi, gli artefatti. La seconda ti fa notare cosa avevi saltato o frainteso. La terza — quella che pochi fanno — è quella in cui smetti di leggere passivamente e inizi a farti domande: perché il Product Owner è l’unico responsabile del Product Backlog? Perché la Sprint Retrospective viene dopo la Sprint Review e non prima? Questi “perché” sono esattamente il tipo di ragionamento che il test Scrum Master mette alla prova.

Ma attenzione. La Scrum Guide ti dà la struttura, non il contesto. Descrive Scrum come “un framework agile che offre abbastanza struttura per integrare il modo di lavorare del team, lasciando spazio alle pratiche più adatte al contesto specifico” — ed è proprio questa flessibilità intenzionale che genera confusione all’esame. Le domande non chiedono “cos’è lo Sprint Backlog”: chiedono cosa fa lo Scrum Master quando il team vuole modificare lo Sprint Backlog a metà Sprint. Capire la differenza è tutto.

Perché serve un simulatore di domande scenario-based

Lo studio autodidatta funziona. Ma solo se hai feedback immediato sugli errori.

Rileggere la Scrum Guide, prendere appunti, fare schemi concettuali: sono attività utili, però non bastano a prepararti per l’esame scrum reale. Il problema è che senza feedback non sai dove stai sbagliando. Magari hai capito benissimo la Sprint Review — “si svolge alla fine di ogni Sprint e viene usata per mostrare agli stakeholder le funzionalità completate” — ma ti fai sfuggire sistematicamente le domande sulla Sprint Retrospective o sul ruolo dei Developers. E non te ne accorgi finché non sei già dentro l’esame.

Un simulatore con domande situazionali allena il ragionamento, non la memoria. La differenza pratica è questa: invece di chiederti “quante persone compongono il team di sviluppo?”, una buona domanda scenario-based ti mette davanti a una situazione tipo “un team di sei developer vuole aggiungere un ottavo membro durante lo Sprint: cosa dovrebbe fare lo Scrum Master?” Per rispondere bene non basta sapere che i Developers sono idealmente tra 3 e 8 persone — devi capire il principio che regge quella regola e come si applica in contesto.

A mio avviso, è questo il vero scarto tra chi supera il PSM I al primo tentativo e chi ci ritorna. Non la quantità di materiale studiato. La qualità del ragionamento sotto pressione.

E il simulatore di ManagementAcademy lavora esattamente su questo: ogni domanda errata viene spiegata nel dettaglio, con il riferimento preciso al principio Scrum coinvolto. Non ti dice solo “sbagliato” — ti dice perché, e dove nella Scrum Guide trovare la logica corretta. Questo è feedback reale. Questo è ciò che accelera davvero la preparazione.

Da quante domande di prova passare prima dell’esame

La soglia consigliata è chiara: 200 domande di simulazione prima di prenotare il PSM I.

Non è un numero casuale. Sotto quella soglia, stai ancora costruendo familiarità con il formato delle domande. Sopra, inizi a riconoscere i pattern di ragionamento richiesti — non le risposte singole, ma il modo in cui il framework ti chiede di pensare. Sono due cose molto diverse.

Però il numero da solo non significa niente se non lo abbini alla qualità dell’analisi degli errori. Fare 200 domande senza rileggere quelle sbagliate è come allenarsi in palestra guardando il telefono: stai occupando il tempo, non costruendo nulla. Quindi: fai le domande, analizza ogni errore, torna alla Scrum Guide sul punto specifico, e poi rifai le stesse domande dopo qualche giorno. Se le sbagli di nuovo, il problema non è la memoria — è che quella parte del framework non è ancora chiara concettualmente.

Tutto sommato, prepararsi alla certificazione Scrum non richiede mesi di studio intensivo. Richiede metodo. La Scrum Guide gratuita come base, un simulatore con domande scenario-based per allenare il ragionamento, e almeno 200 domande superate con analisi attiva degli errori. Chi segue questa progressione arriva all’esame scrum con una testa diversa — non più quella di chi ha letto un documento, ma quella di chi ha imparato a ragionare dentro un framework.

Domande frequenti su Scrum

Le domande più frequenti su Scrum riguardano ruoli, durate e responsabilità: sono anche le aree dove cadono i candidati al primo tentativo dell’esame PSM I (Professional Scrum Master I). Non è una coincidenza. Queste aree sembrano intuitive, e proprio per questo si sottovalutano. Poi arriva la domanda d’esame e il dubbio si insinua.

Scrum è un acronimo?

No. Scrum non è un acronimo e non sta per nulla. Il nome deriva direttamente dallo scrum del rugby, quella mischia ordinata in cui il team si coordina per far avanzare il gioco insieme. Lo conferma scrum.org nella sua documentazione ufficiale. All’esame PSM I questa domanda compare in forme diverse, spesso travestita da opzione plausibile tra quattro risposte. La risposta è sempre la stessa: è un termine rubato allo sport, punto.

Quanto dura uno Sprint in Scrum?

Uno Sprint dura al massimo 1 mese. La Scrum Guide non fissa una durata minima rigida, ma nella pratica gli Sprint durano tra una e quattro settimane. La durata si sceglie una volta e si mantiene coerente nel tempo: cambiare durata ogni volta non è Scrum, è caos con un nome diverso.

Il Daily Scrum, che è l’evento quotidiano di sincronizzazione del team, dura invece esattamente 15 minuti. Non “circa 15 minuti”. Non “fino a 15 minuti se serve”. Quindici minuti. Questa distinzione torna spesso nelle domande dell’esame scrum.

Chi decide cosa fa il team in Scrum?

Qui sta uno dei tranelli più classici del test Scrum Master. La risposta corretta dipende da cosa si intende per “cosa fa il team”.

Il Product Owner (PO) ordina il Product Backlog per priorità e decide quale lavoro ha più valore. Ma i Developers decidono come organizzare e gestire il proprio lavoro durante lo Sprint. Nessuno impone loro le modalità operative: secondo la University of Wisconsin e la Scrum Guide, i Developers sono responsabilizzati a gestire in autonomia il proprio processo. Lo Scrum Master non assegna task. Il management non entra nello Sprint. Questa separazione è fondamentale e vale la pena memorizzarla bene.

Qual è la differenza tra Scrum e Agile?

Agile è un mindset, una filosofia. Scrum è un framework concreto che mette in pratica quel mindset.

In soldoni: Agile è il “perché” e il “come pensare al lavoro”, Scrum è il “cosa fare lunedì mattina”. Si può essere Agile senza usare Scrum. Ma Scrum è sempre Agile, perché si fonda sui suoi principi: feedback continuo, rilascio precoce di valore, adattamento costante. La Scrum Guide stessa descrive Scrum come un framework che offre abbastanza struttura per integrare il modo di lavorare del team, lasciando spazio alle pratiche più adatte al contesto specifico. Questa frase torna praticamente parola per parola nell’esame PSM I.

Quante persone compongono un team Scrum?

I Developers, cioè il gruppo che produce l’Incremento durante lo Sprint, sono idealmente da 3 a 8 persone. Un team troppo piccolo ha poca varietà di competenze. Uno troppo grande diventa difficile da coordinare e perde l’agilità che Scrum promette.

Attenzione però: lo Scrum Team completo include anche il Product Owner e lo Scrum Master. Quindi quando l’esame chiede “quante persone compongono lo Scrum Team?” la risposta giusta non è sempre “3-8”. Dipende da come è formulata la domanda. Leggila due volte prima di rispondere.

Lo Scrum Master è il capo del team?

No. E questo è forse il malinteso più diffuso tra chi si avvicina a Scrum per la prima volta.

Lo Scrum Master non assegna compiti, non decide le priorità, non ha autorità gerarchica sui Developers. Il suo ruolo è quello di servant leader: serve il team rimuovendo gli impedimenti, protegge il processo Scrum, aiuta l’organizzazione a capire il framework. Personalmente, ho visto candidati rispondere “lo Scrum Master gestisce il team” con una sicurezza totale, e poi restare sorpresi dal risultato. È una trappola che l’esame tende spesso, in domande scenariche dove si descrive uno Scrum Master che “assegna il lavoro” o “approva le User Story”. Entrambe le situazioni sono sbagliate. Sempre.