Le Basi di Scrum - Elementi associati a Scrum

12 – Elementi associati a Scrum

Gli elementi associati a Scrum sono strumenti, pratiche e più in generale “tattiche di gioco”, che non sono obbligatorie in Scrum e che si sono rivelate utili nel tempo.

Tuttavia, in un contesto di complessità e imprevedibilità, non è automatico che questi elementi associati a Scrum vi siano utili.

Suggeriamo di sperimentarli e, eventualmente, adattarli al proprio contesto in maniera empirica.

Gli elementi associati a Scrum non dovrebbero essere imposti ad uno Scrum Team, eccone un elenco non esaustivo.

  • Product Backlog Refinement: si tratta di un’attività ricorrente, durante la quale lo Scrum Team aggiunge dettaglio agli elementi del Product Backlog. Questa attività è molto utile quando diversi Scrum Team lavorano insieme per creare un prodotto o servizio. La durata e la frequenza di questa sessione di lavoro è definita dallo Scrum Team.
Esempio di Burndown chart
Esempio di Burndown chart
  • Burndown chart: un modo per rappresentare visivamente il lavoro svolto e ancora da fare. Può essere applicato sia al Product Backlog che allo Sprint Backlog. Fornisce trasparenza sullo stato di raggiungimento dello Sprint Goal. Spesso assume la forma di un grafico che mostra sull’asse verticale la quantità di lavoro e sull’asse
Carte Poker Planning
Carte Poker Planning
  • Poker Planning: tecnica per stimare la complessità del lavoro da svolgere. Un gioco divertente che permette ai Developers di allinearsi su un determinato argomento e comprenderne la complessità. Planning Poker si basa sulla sequenza di Fibonacci, presentata sotto forma di carte da gioco (un esempio delle carte Collective Genius fornite ai partecipanti durante una formazione). Ciascun partecipante, una volta discussa l’elemento del Product Backlog, sceglie una carta corrispondente al livello di complessità di realizzazione che percepisce (0 poco complesso, 55 molto complesso). I Developers girano le proprie carte contemporaneamente, rivelando così la propria percezione della complessità, senza esserne influenzati. Potrebbero esserci differenze nelle stime, nel qual caso gli estremi motivano la loro scelta e, dopo aver discusso le differenze i partecipanti rivotano. Alla fine otterremo una stima dei Developers, non di una singola persona.
  • Business Model Canvas: è un modo per creare un business case agile in modo collaborativo e guidato. Usiamo questo Canvas nei nostri corsi di formazione Professional Scrum Product Owner per esplorare le diverse strategie business riconducibili alla visione aziendale.

E tu, quali altri elementi associ a Scrum?

Le Basi di Scrum - Elementi associati a Scrum
Le Basi di Scrum – Elementi associati a Scrum

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire la conoscenza del framework Scrum!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Artefatti Scrum: Increment

11 – Artefatti Scrum: Increment

Incremento Scrum
Clicca l’immagine per ascoltare l’episodio del Podcast

Un Increment è un primo passo concreto verso il Product Goal ed è l’ultima versione del prodotto. È utilizzabile e potenzialmente pubblicabile in produzione.

Un Increment fornisce valore agli utilizzatori del prodotto.

Durante uno Sprint è possibile creare più Incrementi e potenzialmente rilasciarli durante lo Sprint, la somma degli incrementi viene ispezionata durante la Sprint Review. Il lavoro può essere considerato parte di un incremento solo se soddisfa la definizione di Done.

Le Basi di Scrum - Artefatti Scrum: Increment
Le Basi di Scrum – Artefatti Scrum: Increment

Commitment: Definizione di Done

La Definizione di Done è una descrizione formale dello stato dell’Incremento quando soddisfa le misure di qualità richieste per il prodotto.

La definizione di Done crea trasparenza consentendo a tutti di comprendere il lavoro svolto nel contesto dell’Increment.

Se la definizione di fatto fa parte degli standard dell’organizzazione, tutti gli Scrum Team devono seguirla, eventualmente arricchendola. In caso contrario, lo Scrum Team deve creare una definizione appropriata di Done per il prodotto.

I Developers sono tenuti a rispettare la definizione di Done. Se più team Scrum lavorano insieme su un prodotto, devono definire una definizione di Done unica che prenda in considerazione le problematiche di integrazione.

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Artefatti Scrum: Sprint Backlog

10 – Artefatti Scrum: Sprint Backlog

Lo Sprint Backlog è un artefatto costituito dallo Sprint Goal  (perché fare lo Sprint?), da tutti gli elementi del Product Backlog scelto per lo Sprint (cosa fare in questo Sprint?), nonché da un piano d’azione per la realizzazione dell’Incremento (come fare a creare valore in questo Sprint?).

Lo Sprint Backlog è un piano sviluppato dalle persone che faranno il lavoro, i Developers. Fornisce informazioni trasparenti, in ogni momento, sul lavoro svolto e ancora da fare per raggiungere lo Sprint Goal.

Pianificazione Sprint in Scrum
Clicca l’immagine per ascoltare il Podcast

Di conseguenza, lo Sprint Backlog viene aggiornato durante lo Sprint in base a ciò che lo Scrum Team impara.

Lo Sprint Backlog è un artefatto che viene creato durante lo Sprint Planning. Il suo contenuto tecnico, definito dai Developers, emerge durante lo Sprint grazie all’esperienza e alle nuove informazioni acquisite. L’emergere di nuove informazioni può avere un impatto sulle previsioni iniziali fatte dai Developers, che si impegnano a realizzare lo Sprint Goal.  Si accetterà che la quantità di lavoro sia più o meno importante secondo gli Sprint perché in un mondo complesso e imprevedibile, le informazioni e le contingenze non sono mai congelate e conosciute in anticipo.

Le Basi di Scrum - Artefatti Scrum: Sprint Backlog
Le Basi di Scrum – Artefatti Scrum: Sprint Backlog

ENGAGEMENT: Sprint Goal

Lo Sprint Goal è l’unico obiettivo dello Sprint. Offre una certa flessibilità in termini di lavoro necessario per raggiungere questo obiettivo.

Lo Sprint Goal viene creato durante lo Sprint Planning e visibile nello Sprint Backlog, è immutabile per tutta la durata dello Sprint.

Se, a seguito dell’emergere di nuove informazioni, il contenuto dello Sprint deve essere modificato, gli sviluppatori lavorano con Product Owner per modificare il perimetro dello Sprint Backlog senza che questo modifichi lo Sprint Goal.

Nella tabella qui sotto ho riportato due esempi di Sprint Goal, abbastanza frequenti sul lato non accettabile

Sprint Goal AccettabileSprint Goal non accettabile
Essere in grado di autenticarsi sul sito WebCorreggere l’anomalia #34, #356-implementare l’accesso con Google – Se c’è tempo per correggere l’anomalia #234 (troppo dettagliato e rigido, lo Sprint Goal corrisponde a una quantità di lavoro da fare)
Mostrare i migliori prodotti nella home pageMostrare i nostri migliori prodotti e fare in modo che la campagna marketing XY possa partire in tempo (due Sprint Goal distinti invece di uno unico)
Esempi di Sprint Goal

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Artefatti Scrum: il Product Backlog

9 – Artefatti scrum: il Product Backlog

Il Product Backlog è un elenco ordinato e evolutivo di tutto il lavoro ritenuto necessario dal Product Owner per creare, pubblicare, mantenere e migliorare un prodotto.

artefatti Scrum e loro impegni
Clicca l’immagine per ascoltare l’episodio del Podcast

Ogni prodotto ha un solo Product Backlog, è in continua evoluzione grazie al feedback constante degli stakeholder e alle Sprint Review, gestito da un solo Product Owner.  

Per rendere trasparente il Product Backlog, il Product Owner garantirà, tra le altre cose:

  • Un ordine e una priorità nel contenuto: in modo tale da rispecchiare la sua visione
  • Accessibilità al contenuto a tutto lo Scrum Team (e alle persone che lo richiedono in azienda)
  • La comprensione condivisa del suo contenuto. Spesso, ad esempio, ogni elemento del Product Backlog avrà le seguenti informazioni: un titolo, una descrizione, criteri di accettazione, un valore aziendale, una stima della complessità.
Le Basi di Scrum - Artefatti Scrum: il Product Backlog
Le Basi di Scrum – Artefatti Scrum: il Product Backlog

commitment: PRODUCT GOAL

Il Product Goal descrive uno stato futuro del prodotto che può servire come destinazione per lo Scrum Team durante la pianificazione. Il Product Goal è visibile nel Product Backlog, è un obiettivo a lungo termine dello Scrum Team. Esiste un solo Product Goal in Scrum. Una volta raggiunto questo obiettivo ne verrà creato uno nuovo.

Gestione del Product Backlog: Guida per Scrum Team
Clicca l’immagine per ascoltare l’episodio del Podcast

ADATTAMENTO DEL PRODUCT BACKLOG

Questo è fondamentale per massimizzare il valore del prodotto, ma cos’è esattamente questo adattamento?

  • Ridare un ordine e una priorità ai contenuti, a seguito del feedback degli stakeholder in Sprint Review e di continuo
  • Aggiunta di nuove idee
  • Rimozione di idee obsolete che non si adattano più al Product Goal (e quindi non hanno più valore)
  • Qualsiasi altra azione che renda il Product Backlog ordinato correttamente

IL VALORE È L’UNICO CRITERIO PER ORDINARE IL BACKLOG DEL PRODOTTO?

No. In effetti, il valore è un concetto soggettivo. Il Product Owner ordina il Product Backlog interagendo con gli Stakeholder. Altri parametri da considerare per ordinare il Product Backlog sono:

  • Valore aziendale: il problema più urgente per gli utenti, un vincolo normativo, una funzionalità che nessun concorrente possiede, ecc.
  • Il rischio: in Scrum il rischio non viene gestito, viene trattato per primo. Ciò ha un impatto sulla pianificazione
  • La dimensione degli elementi del Product Backlog: gli elementi importanti e di valore superiore avranno una dimensione giudicata dai Developers realizzabile in uno Sprint

In nessun caso l’ordine è dettato dalla difficoltà di realizzazione. Il Product Owner tiene conto dell’opinione dei Developers, senza concentrarsi prima sul “facile da fare”, perché questo non corrisponde a massimizzare il valore.

QUALE LIVELLO DI DETTAGLIO DOVREBBE AVERE UN ELEMENTO DEL Product BACKLOG

Un livello sufficiente per consentire a tutti di comprendere e ricordare l’argomento da discutere, quando sarà il momento.

Agile Estimating and Planning
Lettura consigliata: Agile Estimating and Planning

Ricorda uno dei quattro principi del Manifesto Agile: “gli individui e le interazioni più che i processi e gli strumenti”. Un elemento del Product Backlog, inizialmente, serve per contrassegnare l’idea non appena arriva e poi svilupparla quando diventa una “priorità”.

Non c’è bisogno di passare ore a scrivere specifiche dettagliate, in quanto si tratterebbe di una perdita di tempo ed energia che potrebbe essere dedicata ad argomenti di immediato valore per gli utenti.

L’attenzione si concentrerà sulla cooperazione di tutte le persone pertinenti sull’argomento al momento opportuno.

Vuoi andare oltre nella stima e nella pianificazione Agile? Il libro di Mike Cohn “Agile Estimating and Planning” è un buon inizio.

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint Retrospective

8 – Eventi Scrum: Sprint Retrospective

La Sprint Retrospective è un’opportunità per lo Scrum Team d’ispezionare l’andamento dello Sprint e creare un piano di miglioramento per il prossimo Sprint.

Questo event ha una timebox di 3 ore per uno Sprint di un mese, proporzionalmente meno per uno Sprint più breve.

Immagina di far parte di una squadra di rugby, non avendo mai giocato a questo gioco. L’efficienza del team nelle prime partite non sarà ottimale. Dopo ogni partita, il team discuterà le azioni di miglioramento da attuare per il prossimo gioco, come ad esempio:

Sprint Retrospective Scrum: facilitazione e miglioramento continuo del team agile
Clicca l’immagine per ascoltare l’episodio del Podcast
  • Il livello di comprensione dei valori e delle regole del gioco da parte dei giocatori;
  • L’efficacia del processo messo in atto per soddisfare lo scopo del gioco;
  • Verificare se gli strumenti utilizzati quotidianamente sono efficaci per raggiungere l’obiettivo: semplificano le nostre vite o la complicano?
  • Relazioni tra giocatori e stakeholder del team

Lo Scrum Master farà in modo che l’intero Scrum Team partecipi all’evento e che l’obiettivo sia chiaro a tutti.

Può facilitare la sessione, su richiesta del team, o parteciparvi contribuendo all’emergere di nuove idee di miglioramento.

Le Basi di Scrum - Eventi Scrum: Sprint Retrospective
Le Basi di Scrum – Eventi Scrum: Sprint Retrospective

TRE ORE SONO TROPPO PER UNA RIUNIONE!

Scrum aiuta a creare un processo empirico per fornire un prodotto o un servizio complesso. Il tempo dedicato alla ricerca del miglioramento non è tempo sprecato, è tempo investito per il futuro.

Spesso la frase citata nel titolo viene pronunciata in ambienti di lavoro dove:

  • Si è affetti da “riunionite”: è una malattia che è nota in molte aziende e che consiste nell’organizzare incontri che non hanno uno scopo specifico, in cui ci si annoia. In questi contesti, comprensibilmente, le persone fanno molta attenzione prima di accettare una riunione;
  • Tutti sono sempre sopraffatti: manca l’attenzione per potersi dedicare pienamente ad un argomento;
  • L’Individualismo: un processo empirico richiede trasparenza. Non partecipare agli eventi Scrum è come guardare attraverso un vetro opaco. Come possiamo migliorare insieme se non prendiamo il tempo di stare insieme?

Inoltre le tre ore di Sprint Retrospective sono un timebox, ciò vuol dire que se l’obiettivo dell’evento è raggiunto rapidamente, si potrà tornare al lavoro ben prima delle tre ore di lavoro previste in generale per uno Sprint di un mese.

IL PRODUCT OWNER DEVE PARTECIPARE ALLa SPRINT Retrospective?

Naturalmente! È membro del Team Scrum e in quanto tale la sua partecipazione è fondamentale. Se non partecipa, come potranno migliorarsi le interazioni fra Product Owner, Scrum Master e Developers?

Uno dei punti di forza di Scrum è abbattere i compartimenti stagni… quindi se il Product Owner è una persona del business (come sales, marketing, dirigente, ecc.), deve capire che far parte di uno Scrum Team richiede coinvolgimento e collaborazione!

SIAMO IN RITARDO, RISPARMIEREMO TEMPO CANCELLANDO La SPRINT Retrospective!

Quante volte ho sentito questa frase… Anche tu?

Immagina una squadra di Rugby che decide di non andare negli spogliatoi alla fine del primo tempo perché è meglio rimanere sul campo a fare autografi, è possibile?

La cancellazione della Sprint Retrospective è spesso motivata da:

  • Pressione esterna allo Scrum Team, spinto a “fare sempre più cose”, sempre più velocemente… senza prestare attenzione al valore creato, o alla qualità.
  • Un Product Owner che spinge il team di sviluppo a fare sempre di più, anche se significa utilizzare le ore della Sprint Retrospective per sviluppare più funzionalità.
  • Un Scrum Master che non è in grado di mediare e proteggere il team dalle incitazioni degli altri dipartimenti (o peggio non previsto nel budget) e che non può rivelare i malfunzionamenti nell’applicazione Scrum. (nota che uno Scrum Team senza Scrum Master non gioca a Scrum, è come giocare a Rugby in 14). Guarda questo video per approfondire l’argomento.

Scrum non è rigido, è una struttura molto semplice, con regole del gioco chiare e descritte nello Scrum Guide.  Se si desidera creare un prodotto o un servizio complesso empiricamente con Scrum, bisogna giocare secondo le regole di Scrum!

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint Review

7 – Eventi Scrum: Sprint Review

La Sprint Review è l’evento in cui lo Scrum Team e gli stakeholder (usualmente invitati dal Product Owner) si incontrano per ispezionare l’Incremento e adattare il  Product Backlog.  Questa frequenza di ispezione e adattamento del lavoro svolto è molto importante per capire se la direzione intrapresa è corretta e insieme decidere cosa fare in seguito.

Si tratta di un evento informale, che non ha bisogno di preparazione, perché verrà ispezionato un Incremento Done e quindi, per definizione, corretto e senza anomalie, pronto per essere messo in produzione se il Product Owner lo decide.

Evento Sprint Review in Scrum
Clicca l’immagine per ascoltare l’episodio del Podcast

Un possibile risultato di questo evento potrebbe essere (vedi la Guida Scrum): 

  • Presentazione dello Sprint Goal (definito in Sprint Planning) dal Product Owner
  • Descrizione degli elementi del Product Backlog implementati dalla definizione di Done e non Done, relativo allo Sprint Goal, dal Product Owner
  • I Developers condividono i contenuti dell’Incremento con le scelte tecniche effettuate per le soluzioni implementate
  • Rendere l’Incremento disponibile agli Stakeholders per ottenere feedback
  • Adattare il Product Backlog con nuove idee, un ordine diverso, l’eliminazione di alcuni elementi, ecc.
  • Revisione del Product Backlog e condivisione delle date estimate di consegna in funzione dei progressi compiuti fino ad oggi (dati empirici).
Le Basi di Scrum - Eventi Scrum: Sprint Review
Le Basi di Scrum – Eventi Scrum: Sprint Review

LA SPRINT REVIEW NON È

  • Una demo: ad esempio solo un video, con le nuove funzionalità, mostrato agli Stakeholders.
  • La lettura di un Power Point: teorico, possibilmente con screenshot, che spiega cosa è stato fatto.
  • Una presentazione del lavoro svolto dai Developers al Product Owner, allo Scrum Master o ad un manager.

nella SPRINT REVIEW Non abbiamo nulla da mostrare

C’è sempre qualcosa da ispezionare in Sprint Review, se la Scrum Team si trova in una situazione in cui non c’è nulla da mostrare agli Stakeholders, si deve avere il coraggio di mantenere l’evento e spiegare in modo trasparente gli ostacoli (impediments) che hanno impedito la creazione dell’Incremento Done alla fine dello Sprint.

Le disfunzioni riscontrate sul terreno, che portano a questo tipo di situazione, possono essere:

  • Elementi del Product Backlog troppo grandi da sviluppare durante lo Sprint;
  • Lo Scrum Team non ha tutte le abilità per creare un Incremento Done;
  • Lo Scrum Team, che lavora su diversi progetti/prodotti in multitasking, senza potersi concentrare sulla creazione dell’Incremento
  • Un prodotto esistente che viene tagliato in strati tecnici
  • L’assenza di uno Sprint Goal

Qualunque cosa accada, lo Scrum Team si auto-organizzarsi per poter, in Sprint Review, portare del valore agli stakeholders. L’interesse deriva dall’essere riusciti a creare una variazione del valore del prodotto rispetto all’ultima volta. Questo può essere difficile all’inizio, in alcune situazioni. L’annullamento della Sprint Review non aiuterà a migliorare, al contrario, avrà un effetto negativo sulla trasparenza del lavoro e impedirà allo Scrum Team di ricevere feedback preziosi.

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Daily Scrum

6 – Eventi Scrum: Daily Scrum

Il Daily Scrum è un evento quotidiano che mira a ispezionare i progressi verso lo Sprint Goal e ad adattare lo Sprint Backlog, se necessario. Ha una time-box di 15 minuti.

Il Daily Scrum si svolge sempre nello stesso luogo alla stessa ora, per ridurre la complessità. Sono i Developers che decidono le modalità d’organizzazione.

Il Daily Scrum consente agli sviluppatori di capire se lo Sprint Goal verrà raggiunto o meno entro la fine dello Sprint. Se il Product Owner o lo Scrum Master stanno lavorando attivamente su elementi dello Sprint Backlog, partecipano come Developers.

I Developers, per capire se lo Sprint Goal è raggiungibile, utilizzeranno un modo per rendere trasparente il lavoro svolto e quello ancora da fare. Molto spesso sentiremo parlare di “Burndown Chart” (vedi il glossario di Scrum), in formato cartaceo o elettronico. L’importante è la trasparenza delle informazioni.

Daily Scrum in Scrum Framework
Clicca l’immagine per ascoltare l’episodio del Podcast

IL DAILY SCRUM NON È…

… un incontro per risolvere i problemi, il suo scopo è quello di rivelarli per affrontarli al momento giusto e a seconda della loro gravità.

… una riunione di follow-up e lo stato di avanzamento del lavoro dei Developers da parte dello Scrum Master, del Product Owner o di un manager.

… un evento settimanale, il suo nome “Daily” significa ogni giorno… troviamo dunque la risposta alla domanda: “Abbiamo deciso di fare il Daily ogni due giorni, perché vederci ogni giorno non aveva senso”. In questo caso, bisogna pensare alla mancanza di trasparenza nello Scrum Team e all’occasione mancata per sapere se si è ancora in grado di raggiungere lo Sprint Goal.

Non bisogna dimenticare che la base di un approccio empirico è la trasparenza… in quale altro modo potreste ispezionare correttamente il lavoro e adattarlo?

Le Basi di Scrum - Eventi Scrum: Daily Scrum
Le Basi di Scrum – Eventi Scrum: Daily Scrum

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint Planning

5 – Eventi Scrum: Sprint Planning

Eventi Scrum: Sprint Planning. Lo Sprint Planning è il primo evento dello Sprint. Il suo obiettivo è quello di collaborare alla pianificazione del lavoro da fare durante lo Sprint. Ha un timebox di 8 ore per uno Sprint di un mese, proporzionalmente meno per uno Sprint più breve. L’intero Scrum Team partecipa per tutta la durata.

Sprint Planning Scrum
Clicca l’immagine per ascoltare l’episodio del Podcast

I tre argomenti seguenti vengono discussi durante lo Sprint Planning.

1 – PERCHÉ QUESTO SPRINT È IMPORTANTE?

Il Product Owner propone come il prodotto potrebbe aumentare il valore e l’utilità durante l’attuale Sprint.

La parte superiore del Product Backlog sarà costituita da elementi abbastanza piccoli, conosciuti e compresi dall’intero Scrum Team e coerenti con la visione del Product Owner.

Lo Scrum Team lavora insieme per definire uno Sprint Goal realistico e realizzabile per la fine dello Sprint.

2 – COSA POSSIAMO FARE in questo SPRINT?

I Developers selezionano gli elementi del Product Backlog realizzabili in uno Sprint, collaborando con Product Owner. 

Alcuni fattori hanno un impatto sulle stime dei Developers, come: 

  • Definizione di Done 
  • Prestazioni passate
  • Azioni di miglioramento da implementare
  • La capacità dello Scrum Team (ferie, assenze varie, assegnazioni parziali).

3 – COME VERRÀ SVOLTO IL LAVORO SCELTO?

Per ogni elemento del Product Backlog (non necessariamente tutti), gli sviluppatori pianificano il lavoro necessario per creare un incremento che soddisfi la definizione di Done, con più o meno dettagli a seconda dell’esperienza.

Lo Sprint Goal, gli elementi del Product Backlog per lo Sprint, così come il piano per consegnarli costituiscono lo Sprint Backlog. Accetteremo che lo Sprint Backlog cambi in base alle informazioni che emergono durante lo Sprint.

OSSERVAZIONI IMPORTANTI

  • In un contesto complesso, come lo sviluppo software, le interazioni non sono mai lineari. Aspettatevi che tutti e tre gli argomenti siano ridiscussi più volte durante lo Sprint Planning.
  • L’unico commitment preso dallo Scrum Team è il raggiungimento dello Sprint Goal. Non è la quantità di lavoro, o gli elementi del Product Backlog sviluppato alla fine dello Sprint che conta, è il fatto che lo Scrum Team sia riuscito a raggiungere lo Sprint Goal e a creare un incremento Done potenzialmente rilasciabile in produzione. Anche il più piccolo.
  • Da “Push” a “Pull”: solo i Developers possono fare previsioni su quanti elementi del Product Backlog verranno realizzati durante lo Sprint. Si dice che i Developers “tirano” il lavoro da fare in base ai suggerimenti del Product Owner. Nessuno può imporre loro o “spingere” una quantità di lavoro da fare. Rinunciare ad accettare questo modo di lavorare significa depotenziare i Developers e spesso porta ad effetti collaterali come: mancanza di commitment, mancanza di qualità, debito tecnico, turnover, ecc.
  • I Developers selezioneranno gli elementi del Product Backlog nell’ordine definito dal Product Owner.  Non si sceglie l’elemento più facile da raggiungere, per comodità.
  • Il Product Owner partecipa e collabora alle discussioni sull’argomento “3 – Come verrà svolto il lavoro scelto?”.  Sì! Rimane per il motivo indicato nel primo punto di questa lista. Ci si deve sempre aspettare interazioni non lineari all’interno dello Scrum Team durante lo Sprint Planning.
  • Lo Sprint Backlog non necessità dettagli in tutti i suoi contenuti. L’importante sarà avere abbastanza dettagli per poter avviare lo Sprint. Si accetterà l’emergere del lavoro durante lo Sprint (e le modifiche conseguenti allo Sprint Backlog).

Al termine dello Sprint Planning, lo Sprint Goal, le previsioni degli elementi del Product Backlog  da sviluppare (realizzati dai Developers) e il piano per raggiungerli saranno tutti elementi visibili nello Sprint Backlog.

Le Basi di Scrum - Eventi Scrum: Sprint Planning
Le Basi di Scrum – Eventi Scrum: Sprint Planning

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire la conoscenza del framework Scrum!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint

4 – Eventi Scrum: Sprint

COS’È UNO SPRINT?

Scrum prescrive cinque eventi, lo Sprint è il cuore e il contenitore di tutti gli altri. Ha una durata di massimo un mese, durante il quale viene creato e potenzialmente rilasciato un incremento di prodotto finito (“Done”) in produzione, (cfr. Guida scrum).

Lo Sprint consente una frequenza regolare di ispezione e adattamento del prodotto e della maniera di lavorare insieme nello Scrum Team e al di fuori. Il miglioramento continuo è alla base di Scrum.

Uno Sprint può essere considerato un mini-progetto con: 

  • Un obiettivo chiaro e immutabile (lo Sprint Goal)
  • Una durata fissa (massimo un mese)
  •  Una qualità impeccabile (resa trasparente nella definizione di Done)

…  e il contenuto?

Eventi Scrum e Sprint
Clicca l’immagine per ascoltare l’episodio del Podcast

Delle previsioni in merito al contenuto dello Sprint vengono fatte durante lo Sprint Planning dai Developers, perché per un prodotto complesso si accetterà l’adattamento del contenuto in relazione all’emergere di nuove informazioni (positive o negative).

Al termine dello Sprint, lo Scrum Team raggiunge lo Sprint Goal, materializzato da un Incremento di prodotto che aderisce alla definizione di Done.

L’unica eccezione sarebbe l’obsolescenza dello Sprint Goal nel corso dello Sprint, ad esempio un cambiamento delle condizioni di mercato. In questo caso, solo il Product Owner può decidere di annullare lo Sprint, che termina prematuramente con gli eventi rimanenti.

Tutto il lavoro degli sviluppatori viene eseguito all’interno dello Sprint e ha come origine il Product Backlog. Ciò implica che le tradizionali attività di ingegneria del software (analisi, progettazione, sviluppo, test, integrazione, ecc.) si svolgono in uno Sprint, in modo non lineare e attraverso la collaborazione di tutti. 

Formalizzeremo meno e collaboreremo di più.

Fabio Panzavolta

Pertanto, uno Sprint non ha aggettivi: lo Sprint 0, lo Sprint di Stabilizzazione, il Test Sprint, lo Sprint di concezione, ecc. non esistono in Scrum.

Le Basi di Scrum - Eventi Scrum: Sprint
Le Basi di Scrum – Eventi Scrum: Sprint

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire la conoscenza del framework Scrum!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Il Team Scrum

3 – Lo Scrum Team

Lo Scrum Team è autogestito e multidisciplinare.

Podcast Scrum Team Collective Genius con Fabio Panzavolta
Clicca sull’immagine per ascoltare l’episodio del Podcast

Scrum definisce tre responsabilità specifiche all’interno dello Scrum Team:

  • Product Owner (proprietario del prodotto): massimizza il valore del prodotto e gestisce il backlog del prodotto.
  • Developers: creano l’incremento “Done” potenzialmente finito ad ogni sprint e gestiscono e implementano lo sprint backlog.
  • Scrum Master: rimuove gli ostacoli che impediscono al team scrum di creare un incremento finito e gestisce il l’ambiente scrum.

L’avrete notato, in Scrum le persone non sono gestite, d’altra parte si fissano gli obiettivi e gestiscono gli artefatti.

La Guida Scrum descrive queste responsabilità in modo più accurato. È importante mantenere questa semplicità e immaginare come le responsabilità aziendali esistenti possano convergere con quelle di Scrum. L’unica domanda da porre dovrebbe essere:

Quali competenze sono necessarie per creare valore per i futuri utenti?

L’auto-gestione di Scrum è fondamentale per essere in grado di fornire prodotti complessi più velocemente. È possibile solo se tutti i membri dello Scrum Team capiscono le proprie responsabilità. In questo caso, come nel caso di un campo magnetico, ci sarà un equilibrio di forze che consentirà un’efficienza senza pari nella creazione di valore.

In questo video ci occupiamo di questo argomento.

Le Basi di Scrum - Il Team Scrum
Le Basi di Scrum – Lo Scrum Team

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!