The Scrum Framework — Seconda edizione

Questo capitolo mantiene il contesto didattico storico e pratico della seconda edizione. Nei contenuti sottostanti è disponibile anche il percorso della terza edizione.

---

riunione di pianificazione dello Sprint Scrum
La riunione sul CHE COSA e la riunione sul COME

Lo Sprint Planning di Scrum è un incontro collaborativo e iterativo nel framework Scrum, una metodologia agile diffusa per la gestione dei progetti. È un evento centrale in cui i membri del team si riuniscono per pianificare e organizzare insieme le attività e gli obiettivi imminenti.Durante questo incontro dinamico, il team traccia la rotta dello Sprint successivo: un periodo di durata prestabilita in cui vengono completati elementi di lavoro prioritari, raccolti nel backlog. Le idee di ogni membro del team diventano centrali nello Sprint Planning: osservazioni, competenze e prospettive contribuiscono a creare un piano completo, coerente con gli obiettivi e le tempistiche del progetto.

Nel contesto Scrum, il termine «mente» sottolinea la collaborazione cognitiva durante la pianificazione. Comprende l'intelligenza collettiva e le capacità di risolvere problemi dei membri del team, che sincronizzano i propri pensieri per elaborare una strategia efficace. L'incontro incoraggia uno scambio aperto di idee e utilizza la mente collettiva del team per individuare possibili difficoltà, assegnare con criterio le risorse e formulare una rotta verso il successo. Lo Sprint Planning esprime il principio agile che dà valore alle persone e alle interazioni, evidenziando l'importanza di una mente di squadra sincronizzata per favorire adattabilità e capacità di risposta all'evoluzione dei requisiti del progetto.

La riunione sul CHE COSA

Una riunione sul CHE COSA, nelle metodologie di sviluppo agile come Scrum, è un evento centrale in cui le menti dello Scrum Team si incontrano per discutere e definire il «CHE COSA» del prossimo impegno di Sprint. Diversi membri del team discutono insieme, condividono osservazioni e decidono collettivamente le attività prioritarie che formeranno lo Sprint Backlog. Spesso utilizzano tecniche come il planning poker per stimare lo sforzo necessario per ogni attività, favorendo una comprensione condivisa e l'allineamento verso uno Sprint Goal comune. Questo evento contribuisce in modo determinante a definire la direzione dello Sprint successivo, sottolineando trasparenza, collaborazione e mentalità collettiva nello Scrum Team.

Questa edizione descrive il confronto sul CHE COSA all'interno dello Sprint Planning. L'obiettivo è concordare uno Sprint Goal e selezionare una previsione realistica del lavoro che i Developer ritengono di poter completare entro la fine dello Sprint.

Nel contesto dinamico della gestione dei progetti, la riunione sul CHE COSA offre un riferimento centrale ai team che cercano chiarezza e direzione. Fornisce un modo strutturato per sincronizzare gli sforzi e allineare gli obiettivi. Per esempio, un team che utilizza Kanban può scegliere un confronto simile sul rifornimento del lavoro; non è un evento obbligatorio di Kanban o Scrum. Può diventare un momento utile per esaminare insieme l'avanzamento e adeguare le priorità. La velocità del lavoro viene esaminata attentamente per assicurare un ritmo ottimale e si incoraggiano domande da affrontare apertamente.

Durante la riunione sul CHE COSA, l'attenzione è rivolta alla selezione del lavoro imminente, sulla base di ciò che il team ha imparato. Questo differisce da una Sprint Review nelle metodologie agili (vedi anche Sprint Review: obiettivi e consigli pratici), che esamina le attività completate e valuta le prestazioni complessive. Questo approccio iterativo consente ai team di apportare gli adeguamenti necessari e migliorare continuamente il flusso di lavoro. La riunione sul CHE COSA va oltre un semplice elenco di attività: coinvolge la mentalità collettiva del team, creando un ambiente in cui creatività e collaborazione prosperano. In questo modo, diventa un impegno di Sprint, una promessa di procedere per iterazioni ed evolvere, incarnando l'essenza dell'agilità nella gestione dei progetti.

Preparazione della riunione sul CHE COSA

Per una riunione sul CHE COSA efficace, occorre prepararsi:

• Lo Scrum Product Owner propone un obiettivo di valore; l'intero Scrum Team collabora per definire lo Sprint Goal.
• Sulla base di questo obiettivo, il Product Owner prepara gli elementi ordinati e pertinenti del backlog da discutere; i Developer scelgono che cosa includere nello Sprint.
• Questi elementi vengono aggiornati e suddivisi in storie più piccole, così da poter essere completati in uno Sprint.
• Gli elementi vengono stimati e ordinati per priorità.
• Il team definisce la propria capacità per lo Sprint successivo.

Sprint Goal

Lo Scrum Product Owner propone un obiettivo di valore; l'intero Scrum Team collabora per definire lo Sprint Goal. È una breve descrizione di ciò che lo Sprint cercherà di ottenere e deve essere realistica e comprensibile per tutti.

Capacità del team

La capacità complessiva dello Scrum Team può cambiare da uno Sprint all'altro. Per assumere impegni realistici, è necessario conoscere la capacità totale del team per lo Sprint successivo, considerando per esempio ferie, festività, tempo dedicato alle riunioni Scrum e alle altre attività durante lo Sprint.

Svolgimento della riunione sul CHE COSA

Durante l'incontro, lo Scrum Product Owner presenta lo Sprint Goal e ne discute con il team. Poi lo Scrum Team esamina gli elementi pertinenti dello Scrum Product Backlog e si impegna sugli elementi che ritiene di poter completare interamente nello Sprint. La decisione deve basarsi sulla capacità disponibile e sulla conoscenza degli elementi.

Alla fine dell'incontro, l'elenco di tutti gli elementi dello Scrum Product Backlog su cui il team si è impegnato costituisce la base della riunione sul COME e dello Scrum Backlog.

La riunione sul COME

La riunione sul COME è un evento integrante della metodologia di sviluppo agile, in particolare del framework Scrum. Offre allo Scrum Team uno spazio per allineare collettivamente idee e strategie al fine di realizzare l'impegno di Sprint. Il termine «COME» ne riassume l'essenza: approfondire i dettagli dello Sprint successivo e determinare insieme i modi più efficaci per raggiungere gli obiettivi stabiliti.

Durante la riunione sul COME, lo Scrum Team discute apertamente, attingendo alle prospettive dei suoi diversi membri. Questa inclusività favorisce uno scambio dinamico di idee e permette di utilizzare l'intelligenza e l'esperienza collettive. Il planning poker, una tecnica diffusa nelle metodologie agili, viene spesso usato per stimare lo sforzo richiesto dalle diverse attività. Questo assicura una comprensione condivisa del carico di lavoro e crea solide basi per pianificare lo Sprint successivo. La riunione sul COME è quindi una tappa fondamentale nel framework Scrum: favorisce la collaborazione, allinea le idee e rafforza l'impegno collettivo verso uno Sprint di successo.

L'obiettivo della riunione sul COME è compilare lo Sprint Backlog individuando le attività concrete necessarie per realizzare completamente gli elementi dello Scrum Product Backlog. Generalmente comprendono progettazione, implementazione, test e documentazione.

La riunione sul COME può svolgersi in una sessione separata dopo la riunione sul CHE COSA, durante quest'ultima quando il team si impegna sugli elementi, oppure in entrambe le occasioni.

Dopo aver individuato le attività necessarie, il team le stima. La base di questa stima (approfondisci Scrum Planning Poker) può essere espressa in ore-persona in questo approccio pratico. Il team stima il lavoro necessario per completare l'attività; Scrum non impone un'unità di misura e le stime delle attività in ore non vanno confuse con le dimensioni relative espresse in story point.

Guida completa allo Sprint Planning nella gestione Agile dei progetti

Gli incontri di Sprint Planning, parte integrante della gestione Agile dei progetti, sono i passi fondamentali per costruire uno Sprint di successo. Questi incontri a durata prestabilita, spesso fino a 8 ore per uno Sprint di un mese, servono a preparare con cura il piano del lavoro imminente. Contrariamente a quanto si potrebbe pensare, non si tratta soltanto di stabilire un ordine del giorno o degli obiettivi: la preparazione comprende definire le priorità, stimare il carico di lavoro e chiarire i ruoli, come un'orchestra ben preparata che si riscalda prima di un'esibizione. Aspettati l'inaspettato: i risultati possono variare molto e l'obiettivo rimane il miglioramento, non la perfezione. Iniziamo esaminando il funzionamento concreto di questi incontri.

Per ottimizzare lo Sprint Planning, assicurati che l'intero Scrum Team concordi uno Sprint Goal e che i Developer creino un piano realistico per perseguirlo. Rispetta inoltre la durata massima, concentrati sui risultati di valore e lascia spazio a discussioni aperte e adeguamenti, per creare un ambiente motivante e favorevole al successo del team. Ricorda che la preparazione è fondamentale: il Product Backlog deve essere aggiornato e affinato prima dell'incontro.

Il funzionamento concreto dello Sprint Planning

Lo Sprint Planning è come posare i binari per un viaggio ad alta velocità: ogni dettaglio conta. Durante questi incontri si prepara e si definisce attentamente il lavoro dello Sprint successivo. I partecipanti principali, Product Owner, Scrum Master e team di sviluppo, si riuniscono per stabilire che cosa fare e come farlo efficacemente. La durata è spesso prestabilita per evitare che si prolunghino troppo: generalmente fino a 8 ore per uno Sprint di un mese.

Un aspetto fondamentale dello Sprint Planning è bilanciare la definizione di ciò che si può consegnare con la comprensione di come realizzarlo, stabilendo obiettivi realistici e raggiungibili. Questo richiede un confronto tra valore, cioè ciò che conta di più, e sforzo, cioè tempo e risorse necessari. È qui che emerge pienamente la collaborazione tra Product Owner, Scrum Master e team di sviluppo.

Per esempio, se il Product Owner vuole aggiungere molte funzionalità allo Sprint Backlog, ma il team di sviluppo ritiene che siano troppe per uno Sprint, si avvia una negoziazione. Il Product Owner può aumentare o diminuire la priorità di alcune funzionalità in base alle indicazioni del team.

Perché lo Sprint Planning proceda senza intoppi, è fondamentale che tutti arrivino preparati con informazioni aggiornate. Il Product Backlog deve essere affinato e aggiornato. Una buona preparazione del Product Owner aiuta a delineare chiaramente gli obiettivi nello Sprint Backlog. Inoltre, è prassi comune svolgere un incontro di affinamento del backlog prima della pianificazione, semplificando ulteriormente il processo.

La dinamicità e l'interazione tra i diversi ruoli nello Sprint Planning sono fondamentali per creare le condizioni di uno Sprint di successo. Approfondiamo la distribuzione dei ruoli durante questi incontri e il loro impatto sui processi decisionali.

La realizzazione efficace di qualsiasi progetto dipende da obiettivi chiari e da una pianificazione fluida. Esploriamo ora il processo accurato di definizione degli obiettivi e preparazione alla gestione agile dei progetti.

Definire gli obiettivi e preparare la pianificazione

Creare obiettivi chiari e raggiungibili è il primo passo fondamentale per uno Sprint Planning efficace. Come nella preparazione di un lungo viaggio, serve una mappa che guidi il team alla destinazione. Il Product Owner assume una funzione centrale in questa fase, descrivendo lo Sprint Goal: la stella polare che orienta la pianificazione del team.

Per stabilire obiettivi efficaci, il Product Owner deve collaborare strettamente con il team di sviluppo per definirli e comprenderli. Questa collaborazione crea uno scopo condiviso, allinea entrambe le parti sui risultati desiderati e rafforza titolarità e responsabilità nei membri del team. Attraverso discussioni aperte e osservazioni collettive, il team può definire obiettivi che riflettano fattibilità e valore.

L'importanza di obiettivi dettagliati

Obiettivi ben definiti non solo indirizzano gli sforzi collettivi, ma fungono anche da riferimento per misurare l'avanzamento. Obiettivi vaghi o ambigui possono creare confusione, inefficienza e mancanza di concentrazione durante lo Sprint. Al contrario, obiettivi chiari illuminano la strada e consentono ai membri del team di prendere decisioni informate, coerenti con lo scopo complessivo.

Inoltre, stabilire obiettivi precisi per l'incontro crea le basi per gestire efficacemente il tempo. Esprimendo chiaramente ciò che deve essere raggiunto, i partecipanti possono utilizzare il tempo in modo più efficiente, evitando deviazioni inutili o lunghe discussioni su temi secondari.

Allineare gli obiettivi alle aspettative degli stakeholder

È altrettanto importante considerare le prospettive degli stakeholder oltre il team di sviluppo immediatamente coinvolto. Gli obiettivi definiti nello Sprint Planning devono rispecchiare le loro aspettative sugli incrementi di prodotto e la domanda di mercato. Questo allinea gli sforzi dello Sprint con gli obiettivi aziendali più ampi e le esigenze dei clienti, aumentando il valore del prodotto e la competitività sul mercato.

Per esempio, se un team di sviluppo software lavora a una piattaforma di commercio elettronico, gli stakeholder possono aspettarsi una migliore esperienza utente, misure di sicurezza più solide o pagamenti più semplici. Stabilire obiettivi dell'incontro che riflettano queste priorità favorisce quindi l'allineamento tra sviluppo ed esigenze aziendali.

Vediamo come una preparazione accurata renda più efficace il confronto nello Sprint Planning.

Definizione delle priorità e stima delle attività nel backlog

Nella gestione Agile dei progetti, definire le priorità e stimare le attività influisce direttamente sul successo dello Sprint Planning. Questo processo assicura che le attività più importanti vengano svolte per prime e chiarisce lo sforzo richiesto da ogni elemento del Product Backlog. Esaminiamolo e vediamo come contribuisce a una pianificazione efficace.

Definizione delle priorità

Prima di stimare le attività, è essenziale assegnare correttamente le priorità agli elementi del Product Backlog. Un possibile approccio utilizza una scala da 1 a 10, con 1 come priorità massima e 10 come minima. Scrum richiede un Product Backlog ordinato, non una specifica scala numerica. Una definizione efficace delle priorità consente al team di sviluppo di concentrarsi sulle funzionalità di maggior valore all'inizio dello Sprint, massimizzando il ritorno sull'investimento.

Immagina un Product Backlog con diverse user story. Assegnando loro livelli di priorità, il team assicura che le funzionalità fondamentali per gli utenti o le attività tecniche principali vengano affrontate per prime. Questo approccio rispetta i principi Agile, dando rilievo al valore per il cliente e promuovendo una consegna incrementale.

Stima delle attività

Dopo aver definito le priorità, è il momento di stimare lo sforzo necessario per ogni elemento del Product Backlog. Il team di sviluppo utilizza spesso gli story point come misura relativa del lavoro, anziché unità di tempo tradizionali. Gli story point consentono di confrontare e approssimare complessità, incertezza e rischio, invece di concentrarsi soltanto sulle ore o sui giorni necessari al completamento.

Per esempio, quando un team di sviluppo deve implementare una nuova funzionalità in uno Sprint, invece di stimare che richiederà 30 ore le assegna un valore in story point sulla base della complessità relativa, dell'incertezza e del rischio dell'attività. Questo facilita una valutazione più accurata della capacità per gli Sprint successivi e incoraggia l'attenzione ai risultati di valore, senza perdersi nei particolari delle singole attività.

Le stime tradizionali basate sul tempo possono sembrare precise, ma spesso trascurano fattori cruciali come complessità e incertezza, producendo valutazioni inesatte. Gli story point offrono una visione più completa dello sforzo richiesto e favoriscono il confronto aperto durante lo Sprint Planning.

Definendo efficacemente le priorità del Product Backlog e utilizzando gli story point per stimare le attività, i team Agile possono fondare lo Sprint Planning su risultati di valore e valutazioni realistiche della capacità. Queste pratiche preparano un'esecuzione efficace dello Sprint e sostengono il miglioramento continuo nella gestione Agile dei progetti.

Approfondiamo ora i ruoli fondamentali che contribuiscono a uno Sprint Planning efficiente e assicurano che ogni aspetto venga affrontato con cura per realizzare con successo lo Sprint.

Definire i ruoli per uno Sprint Planning efficiente

Uno Sprint Planning efficace nella gestione Agile dei progetti richiede ruoli e responsabilità ben definiti. Esaminiamo i ruoli più comuni e i relativi compiti durante la pianificazione, per garantire comprensione chiara e funzionamento fluido.

Ruoli e responsabilità comuni

In uno Sprint Planning tipico, diversi partecipanti fondamentali contribuiscono a definire il piano e la direzione complessivi. I più comuni sono il Product Owner, lo Scrum Master e lo Scrum Team (team di sviluppo). Possono però essere coinvolti altri stakeholder, a seconda delle dimensioni e della complessità del progetto.

• Product Owner: Il Product Owner ha un ruolo centrale nello Sprint Planning: descrive l'obiettivo dello Sprint sulla base delle priorità aziendali. Ha la responsabilità di assicurare che il Product Backlog sia affinato e pronto per il confronto durante la pianificazione. È inoltre il principale collegamento tra il team di sviluppo e gli stakeholder, comunicando la visione del progetto e assicurando l'allineamento verso l'obiettivo complessivo.
• Scrum Master: Lo Scrum Master partecipa come membro dello Scrum Team e aiuta a garantire una collaborazione produttiva. Non deve necessariamente presiedere ogni discussione né imporre il piano dei Developer. Mantiene un ambiente favorevole alla comunicazione e alle decisioni efficaci durante la pianificazione. Cerca inoltre di creare un'atmosfera positiva in cui i membri del team possano contribuire liberamente, senza impedimenti o distrazioni.
• Team di sviluppo: Il team di sviluppo è al centro dello Sprint Planning e collabora con il Product Owner e lo Scrum Master per pianificare e stimare il lavoro necessario a raggiungere lo Sprint Goal. Si impegna anche a completare il lavoro selezionato per lo Sprint, valutandone sforzo e fattibilità. Utilizza inoltre le proprie competenze per offrire indicazioni preziose su come eseguire efficacemente le attività individuate nel Product Backlog.

Ruoli chiaramente definiti assicurano che tutti sappiano che cosa ci si aspetta da loro nello Sprint Planning, rafforzando il senso di responsabilità e semplificando i canali di comunicazione.

Immagina, per esempio, il motore di un'auto: ogni parte ha una funzione specifica e deve lavorare in perfetta sintonia con le altre per ottenere prestazioni ottimali. Allo stesso modo, ogni partecipante allo Sprint Planning ha un ruolo essenziale e contribuisce al buon risultato.

La chiarezza dei ruoli permette un migliore coordinamento tra i membri del team e uno Sprint Planning più efficiente e produttivo, in cui tutti comprendono il proprio contributo al successo dello Sprint.

Pianificare il carico di lavoro e la durata dello Sprint

Quando si pianifica uno Sprint, entrano in gioco due componenti fondamentali: la capacità del team e la durata dello Sprint. Esaminiamo questi elementi essenziali e il loro impatto sul successo.

Determinare la capacità

La capacità del team di sviluppo è fondamentale nello Sprint Planning. Non riguarda soltanto le ore di lavoro: occorre considerare festività, assenze programmate e altri eventi che incidono sulla disponibilità. Le capacità e i punti di forza specifici di ogni membro sono altrettanto importanti per distribuire efficacemente le attività.

Per esempio, se uno sviluppatore ha programmato una vacanza durante lo Sprint successivo, la sua minore disponibilità può richiedere di redistribuire le attività agli altri membri. Prevedendo queste situazioni quando si determina la capacità, si può ottenere un carico di lavoro equilibrato.

Consiglio per pianificare la capacità: Monitorare le prestazioni degli Sprint precedenti e analizzare la distribuzione individuale del carico di lavoro offre indicazioni utili sulla capacità effettiva del team.

Decidere la durata

I team scelgono una durata adatta per lo Sprint, comunemente di 1–4 settimane e sempre di un mese o meno, poi mantengono una cadenza costante. Durante la pianificazione adattano il lavoro selezionato a quel limite di tempo, invece di allungare lo Sprint per contenere il carico di lavoro.

Sprint più brevi offrono maggiore adattabilità, cicli di feedback più rapidi e più attenzione alle priorità immediate. Promuovono il senso di urgenza e mantengono alta la produttività grazie a scadenze più vicine.

Sprint più lunghi, invece, possono agevolare analisi approfondite, risoluzione di problemi complessi e test completi. È fondamentale trovare un equilibrio tra approfondimento ed efficienza per evitare avanzamenti lenti o consegne in ritardo.

Supponi che il team lavori a un'importante nuova funzionalità che richiede test accurati con gli utenti e integrazione del feedback. Nel scegliere la cadenza, può valutare se uno Sprint leggermente più lungo favorisca il ciclo di feedback. Test e integrazione devono comunque accompagnare tutto il lavoro, e uno Sprint già avviato non viene esteso per completare ambito aggiuntivo.

Indicazioni per decidere la durata: osservare le prestazioni degli Sprint passati e analizzarle nelle retrospettive può fornire informazioni preziose sulla durata ideale per il tuo team.

Considerare sia la capacità sia la durata dello Sprint è fondamentale per strutturare un piano efficace nella gestione agile dei progetti. Queste scelte strategiche creano le basi di uno Sprint Planning riuscito, allineando la capacità del team a limiti di tempo ben definiti entro cui consegnare incrementi di valore.

Comprendere gli esiti e i risultati dello Sprint Planning

Lo Sprint Planning è essenziale per porre le basi di uno Sprint di successo. Uno dei suoi risultati principali è stabilire uno Sprint Goal chiaro. Questo orienta il lavoro del team durante lo Sprint e ne allinea gli sforzi verso uno scopo comune, creando unità e chiarezza e rafforzando morale e motivazione.

L'importanza di uno Sprint Goal ben definito risiede nella sua capacità di mantenere la concentrazione. Aiuta a prevenire distrazioni o ampliamenti incontrollati dell'ambito durante lo Sprint, assicurando che tutti sappiano verso che cosa stanno lavorando. Funge da guida attraverso le incertezze e i cambiamenti che possono emergere, creando una visione condivisa tra i membri del team.

Oltre a definire l'obiettivo, lo Sprint Planning produce anche lo Sprint Backlog: lo Sprint Goal, gli elementi selezionati e il piano di consegna dei Developer. Il termine «backlog concordato» in questa edizione descrive una previsione realistica, non una garanzia immutabile di ogni elemento iniziale. Lo Sprint Backlog è il piano in evoluzione dei Developer e descrive il lavoro che il team di sviluppo ritiene di poter completare nello Sprint successivo. Questo impegno è parte integrante della responsabilità e della fiducia nel team.

Il backlog di Sprint concordato richiede una comprensione approfondita del lavoro necessario a raggiungere lo Sprint Goal. Comporta stime accurate e la considerazione delle capacità individuali e collettive del team. Non si tratta di sovraccaricare le persone di attività, ma di creare un ambiente collaborativo in cui ciascuno si senta sicuro della propria capacità di contribuire in modo significativo all'obiettivo comune.

Comprendere questi risultati dello Sprint Planning permette ai team di affrontare gli incontri con intenzione e scopo chiari. Concentrandosi su obiettivi definiti e backlog realistici e adattabili, possono aumentare efficienza, lavoro di squadra e produttività in ogni Sprint, contribuendo al successo complessivo del progetto.Padroneggiare questi aspetti fondamentali dello Sprint Planning è un pilastro di risultati costantemente positivi nei progetti e favorisce una cultura di collaborazione, chiarezza e realizzazione nei team agili.