PMI PMP: Agile, Scrum e delivery ibrida — Guida allo studio

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Fa parte della PMP — Guida allo studio. Esercitati con risposte verificate nel centro esami PMI, oppure fai test cronometrati su ExamRoll.io.

Ruoli, Cerimonie e Artefatti di Scrum

Scrum opera con una struttura di ruoli volutamente ridotta, poiché la dispersione della responsabilità è una delle principali cause di fallimento nei progetti complessi. Il Product Owner è responsabile del cosa e del perché: definisce il valore, assegna le priorità al backlog e ha l’autorità di accettare o rifiutare gli incrementi. Lo Scrum Master è responsabile del buon funzionamento del processo: è un servant-leader che rimuove gli ostacoli, offre coaching sulle pratiche agili e protegge il team dalle interruzioni. I Developers (l’intero team di sviluppo, non solo i programmatori) sono responsabili del come: si auto-organizzano per trasformare gli elementi del backlog in un incremento funzionante a ogni sprint.

Questi ruoli devono essere ricoperti da persone reali e coinvolte. Un Product Owner disinteressato o assente è uno dei modelli più distruttivi nello sviluppo agile: senza la sua assegnazione di priorità e accettazione in tempo reale, le sprint review diventano riunioni di stato anziché eventi di validazione del valore, i cicli di feedback si allungano e il team rischia di finire per costruire il prodotto sbagliato. Di fronte a un PO assente, l’azione corretta è inoltrare il problema allo sponsor e ristabilire il ruolo, non fare in modo che lo Scrum Master prenda decisioni per suo conto in modo permanente.

Le cerimonie principali formano un ciclo di feedback chiuso:

• Sprint Planning
  • Scopo: Negoziare l’obiettivo dello sprint e la previsione (forecast)
  • Frequenza: Inizio dello sprint
  • Output principale: Sprint backlog
• Daily Standup
  • Scopo: Sincronizzarsi, far emergere gli ostacoli
  • Frequenza: Giornaliera, con un timebox di 15 min
  • Output principale: Piano giornaliero aggiornato
• Sprint Review
  • Scopo: Ispezionare l’incremento con gli stakeholder
  • Frequenza: Fine dello sprint
  • Output principale: Feedback, product backlog aggiornato
• Sprint Retrospective
  • Scopo: Ispezionare il processo
  • Frequenza: Fine dello sprint
  • Output principale: Azioni di miglioramento concrete

Gli artefatti — Product Backlog, Sprint Backlog e Incremento (Increment) — hanno ciascuno un impegno associato: rispettivamente il Product Goal, lo Sprint Goal e la Definition of Done. Questi impegni sono ciò che impedisce a Scrum di degenerare in un “waterfall iterativo”.

Gestione del Backlog e User Story

Il product backlog è un elenco dinamico e ordinato, non un documento di specifiche congelato all’inizio del progetto. Il Product Owner lo gestisce in collaborazione con il team, affinando gli elementi in modo che la parte superiore del backlog sia composta da item piccoli, ben compresi e pronti per essere presi in carico. Una cadenza comune consiste nel dedicare il 5–10% della capacità del team al backlog refinement (affinamento del backlog) in ogni sprint.

Le user story seguono lo schema familiare: Come [persona], voglio [funzionalità], affinché [beneficio]. La clausola del beneficio è importante tanto quanto la funzionalità: è ciò che permette al team di proporre soluzioni alternative e ciò che consente al PO di decidere se vale ancora la pena sviluppare la story quando le priorità cambiano.

I criteri di accettazione (acceptance criteria) sono le condizioni osservabili e testabili in base alle quali il PO accetterà la story. Si differenziano dalla Definition of Done: i criteri di accettazione sono specifici per la story (la schermata di login si blocca dopo cinque tentativi falliti?), mentre la DoD è universale per ogni story (il codice è stato revisionato, testato, documentato, distribuito in staging?).

Quando uno stakeholder presenta un nuovo requisito a metà progetto, anche se simile a un lavoro precedente, il PO non dovrebbe semplicemente sparare una data. La risposta corretta è registrare la richiesta come un potenziale elemento del backlog, collaborare con il team per stimarne la dimensione (magari usando story di riferimento come ancoraggio per una stima relativa) e quindi inserirlo nel backlog in base al suo valore rispetto agli elementi esistenti. La somiglianza con lavori precedenti accelera la stima ma non elude la discussione sulla priorità.

DoR, DoD e Pianificazione dell’Iterazione

La Definition of Ready (DoR) è un cancello di ingresso a uno sprint. Una story è “ready” (pronta) quando è abbastanza piccola da poter essere completata all’interno di uno sprint, ha criteri di accettazione chiari, ha dipendenze note identificate ed è compresa dal team. Applicare la DoR impedisce al team di prendere in carico lavoro incompleto che si bloccherebbe a metà sprint a causa di domande senza risposta.

La Definition of Done (DoD) è un cancello di uscita. È la checklist condivisa e non negoziabile che trasforma un “abbiamo finito di scrivere il codice” in “questo è un incremento potenzialmente rilasciabile”. Una DoD solida include tipicamente il superamento dei test automatizzati, la revisione del codice, la scansione di sicurezza senza problemi, la documentazione aggiornata e, aspetto fondamentale, la gestione dei requisiti non funzionali come le prestazioni e l’osservabilità. Coinvolgere i team di operations e QA nella definizione della DoD è ciò che previene il pattern in cui un incremento “funziona” durante la sprint review ma collassa sotto un carico reale in produzione. Se il team operations solleva un problema di prestazioni dopo uno sprint e i dati esistono già nei log, la risposta matura è portare tale preoccupazione nella fase di refinement, aggiungere soglie di prestazione alla DoD e creare elementi di backlog per colmare la lacuna, non liquidare il problema come “non previsto dallo scope”.

MVP, Pianificazione dei Rilasci e Consegna Incrementale

Il Minimum Viable Product (MVP) è la più piccola porzione coerente di prodotto che consente al team di testare un’ipotesi chiave con utenti reali. Il suo scopo è l’apprendimento, non la semplice consegna. La pianificazione dei rilasci (release planning) si sovrappone a questo: data una roadmap composta da un MVP seguito da rilasci incrementali, il team prevede quali funzionalità verranno incluse in ciascun rilascio usando la velocity come guida approssimativa.

La consegna incrementale è ciò che offre all’organizzazione la facoltà di scelta (optionality), ovvero la capacità di cambiare direzione sulla base di prove concrete anziché di opinioni. Attendere un rilascio “completo” prima di mostrare qualsiasi cosa agli utenti è l’anti-pattern che le metodologie agili sono specificamente progettate per prevenire.

Stima, Story Point e Velocity

Gli story point misurano lo sforzo relativo, la complessità e l’incertezza, non la durata. Una story da cinque punti richiede circa cinque volte lo sforzo di una story da un punto per quello specifico team. La velocity (punti completati per sprint) emerge quindi empiricamente dopo diversi sprint e viene utilizzata per prevedere degli intervalli, non per prendere impegni su scadenze precise.

Trattare gli story point come giorni fissi è una trappola seria per diverse ragioni. Primo, distrugge l’astrazione: se 1 punto = 1 giorno, il team si limiterà a stimare in giorni e a gonfiare le stime per rispettare le scadenze. Secondo, elimina il segnale di incertezza: una story da 13 punti non è solo “lunga”, è rischiosa, e tale rischio dovrebbe innescare una scomposizione. Terzo, permette al management di usare i numeri come un’arma (“avevate detto 40 punti, perché ne avete finiti solo 32?”), il che incentiva comportamenti di “sandbagging” (sottostimare le proprie capacità). L’uso corretto è: andamento della velocity + dimensione del backlog → previsione di rilascio probabilistica, comunicata come un intervallo.

Gestione di Impedimenti, Interruzioni e Flusso

Il compito più tangibile dello Scrum Master è la rimozione degli impedimenti. Quando un membro del team sta lottando in silenzio — forse per orgoglio o perché è nuovo e non vuole sollevare il problema — il leader del team dovrebbe intervenire direttamente, comprendere l’impedimento e aiutarlo a risolverlo o effettuare un’escalation. Ignorare lo scopo del daily standup è ciò che permette a questa dinamica di degenerare; una partecipazione incostante agli standup crea silos di conoscenza, nasconde i blocchi e permette a piccoli problemi di diventare rischi per la pianificazione. La partecipazione non è negoziabile proprio perché il valore della cerimonia risiede nella sincronizzazione, non nel riportare lo stato di avanzamento.

Le interruzioni ad-hoc — la richiesta “urgente” che bypassa il backlog — sono altrettanto corrosive. Erodono lo sprint goal, invalidano le previsioni e insegnano agli stakeholder che il processo può essere aggirato. La gestione corretta consiste nell’indirizzare le nuove richieste attraverso il PO, che decide se giustificano una cancellazione dello sprint (raro) o se devono essere inserite in uno sprint futuro (solitamente).

Per i team ibridi in cui il testing o un’altra disciplina diventa un collo di bottiglia, la visualizzazione del flusso tramite lavagne Kanban e grafici burndown/burnup espone il vincolo. Se il team identifica uno strumento che potrebbe sbloccare il testing, il project manager non dovrebbe approvare o respingere unilateralmente, ma dovrebbe valutare la proposta in modo collaborativo, verificare la governance aziendale (acquisti, sicurezza), coinvolgere il PO sull’impatto nel backlog e quindi decidere. Un’approvazione impulsiva salta la due diligence; un rifiuto impulsivo ignora la competenza del team.

Retrospective e Miglioramento Continuo

Le retrospective chiudono il cerchio. Una buona retrospective produce una o due azioni di miglioramento concrete e assegnate, non una sessione di sfogo. Coinvolgere operations e QA nelle retrospective fin dall’inizio previene i classici fallimenti di passaggio di consegne, in cui i team ottimizzano per le demo di fine sprint ma non per la realtà della produzione. Il miglioramento continuo è il meccanismo che mantiene la velocity onesta, il DoD significativo e l’engagement del team alto per tutta la vita del prodotto.

Problema Pratico: Scenario d’Uso

Scenario: Priya Nair è la Scrum Master del team “LumenPay”, che sviluppa un portafoglio mobile presso un’azienda fintech. Il team lavora in sprint di due settimane ed è composto da sei sviluppatori, un ingegnere QA e un designer UX. Negli ultimi tre sprint, il Product Owner, Marcus Reeves, ha partecipato a una sola sessione di sprint planning e a nessuna sprint review, adducendo come motivazione responsabilità conflittuali in qualità di responsabile delle Retail Partnership. Gli stakeholder dei team Compliance e Fraud Ops hanno iniziato a inviare email direttamente agli sviluppatori con richieste di priorità contrastanti, e il team ha riportato 34 degli 82 story point totali negli ultimi due sprint. La sponsor, la VP of Product Anita Chen, sta iniziando a mettere in discussione la velocity del team.

Sfida: Priya deve ripristinare il coinvolgimento del Product Owner e fermare la frammentazione del backlog senza travalicare il suo ruolo di servant-leader prendendo lei stessa decisioni sul prodotto.

Approccio Raccomandato:

1. Documentare gli impatti specifici dell’assenza del PO negli ultimi tre sprint — punti riportati, criteri di accettazione ambigui, elementi del backlog non risolti e il numero di richieste dirette da parte degli stakeholder che bypassano il PO — per costruire un caso basato sui fatti.
2. Tenere prima un incontro individuale con Marcus, condividendo i dati e chiedendo direttamente se può dedicare le 10-15 ore settimanali richieste dal ruolo, o se il ruolo debba essere riassegnato o suddiviso.
3. Effettuare un’escalation formale ad Anita Chen con le prove documentate, presentando due opzioni: riassegnare il ruolo di PO a qualcuno con la capacità necessaria, o negoziare una riduzione delle responsabilità di Marcus nelle Retail Partnership.
4. Istruire il team di sviluppo a reindirizzare tutte le richieste in arrivo dagli stakeholder al product backlog anziché accettarle ad hoc, e ribadire che solo il PO può riassegnare le priorità.
5. Una volta confermato un PO pienamente dedicato, organizzare un workshop di backlog refinement per ridefinire le priorità, ripulire i criteri di accettazione e reimpostare lo sprint goal per la prossima iterazione.
6. Stabilire un accordo di lavoro (working agreement) che specifichi la partecipazione del PO alle sessioni di planning, review e ad almeno due sessioni di refinement per sprint.

Perché Funziona: Effettuare un’escalation della problematica allo sponsor preserva l’integrità del ruolo: lo Scrum Master non deve diventare un Product Owner per procura, perché ciò maschererebbe permanentemente il problema organizzativo e comprometterebbe la prioritizzazione basata sul valore. Basare l’escalation su metriche concrete mantiene la conversazione focalizzata sui risultati di delivery piuttosto che sulle personalità, e reindirizzare il traffico degli stakeholder attraverso il backlog ripristina la disciplina della “fonte unica di verità” (single-source-of-truth) da cui Scrum dipende.

← Leadership del team e gestione delle risorse · Tutti i domini · Ambito →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →