Misurare gli obiettivi in Scrum

Misurare gli obiettivi in Scrum

Misurare gli obiettivi in Scrum è necessario per capire se stiamo realmente massimizzando il valore del prodotto.

Nell’articolo precedente, gli obiettivi in Scrum, abbiamo esplorato perché e come Product Goal e Sprint Goal forniscono focus e autonomia allo Scrum Team. Aiutandoci a concentrarci sul risultato voluto per l’utilizzatore, piuttosto che sulle funzionalità da implementare.

In questo articolo vediamo perché è importante che questi obiettivi trasparenti siano ispezionati ed adattati a frequenze regolari… empirismo all’opera con gli obiettivi!

L’effetto Cobra

Misurare gli obiettivi in Scrum - L'effetto cobra

Quando l’India era ancora una colonia inglese, Delhi e altre grandi città erano infestate di serpenti a sonagli, con problemi ovvi per la popolazione. Il governo allora decise di offrire una ricompensa a tutti coloro che uccidevano e consegnavano i serpenti alle autorità.

Questa strategia è stata molto efficace, in quanto i cobra in poco tempo sono spariti. La ricompensa però è rimasta… la popolazione ha cominciato ad allevare serpenti a sonagli, per poi ucciderli e continuare ad ottenere la ricompensa.

Questa storia è un aneddoto che puoi trovare su wikipedia.

Ci insegna tante cose e che un obiettivo, se rimane fisso, ad un certo punto può avere un effetto perverso ed diventare controproducente. Abbiamo quindi bisogno di una misura che ci permetta ispezionare ed adattare a frequenze regolari il risultato ottenuto per capire se e quando l’obiettivo è raggiunto e passare al prossimo magari aggiornando le misure di valore.

Misurare gli obiettivi in Scrum con Evidence Based Management

Evidence Based Management è un framework di misura del valore proposto da Scrum.org. Ci aiuta ad ottenere la prova della creazione di valore in modo empirico.

Il concetto usa lo stesso approccio del mondo medico, nel quale il dottore cerca la prova della malattia (attraverso gli esami clinici) per poi proporre un protocollo di cura.

Nel caso di Scrum vogliamo la prova (feedback) che il prodotto ha effettivamente creato valore per l’utente contribuendo al raggiungimento dell’obiettivo.

Evidence Based Management utilizza quattro aree di valore, ognuna con un insieme di indicatori che ci aiutano a capire come stiamo performando:

  • Current Value: il valore attualmente generato dal prodotto
  • Unrealized Value: il valore atteso dagli utilizzatori del prodotto ma non ancora disponibile
  • Capacity to Innovate: la capacità dell’azienda a creare risultati innovanti
  • Time to Market: la rapidità del passaggio dall’idea alla produzione

Quindi, attraverso le misure, otteniamo la prova che il nostro prodotto sta creando valore e siamo capaci di affermare se l’obiettivo che avevamo è stato raggiunto o meno.

Mi spiego con un esempio.

Esempio di utilizzo di Evidence Based Management

La visione di Collective Genius (e Scrum.org) è di aiutare le persone ed i team a risolvere problemi complessi.

Con Collective Genius, cerchiamo di raggiungere questa visione attraverso una strategia che si focalizza su segmenti di clientela come, ad esempio: le persone che scoprono Scrum, quelle che già praticano ma vogliono perfezionarsi, persone che vogliono auto-formarsi, manager che vogliono formare il loro team, ecc…

Le proposte di valore sono diverse come, ad esempio: coaching Scrum, formazioni di qualità con Scrum.org, creazione di contenuto gratuito e a pagamento, ecc.

Visto che le idee sono tante, ma le risorse poche, siamo costretti a fare delle scelte in termini di segmenti di clientela, proposte di valore ed esperimenti.

Trattiamo questo sito web come un prodotto, il cui focus in termini di proposta di valore è la creazione di contenuto gratuito per le persone che scoprono e praticano Scrum Professionale.

Ogni mese abbiamo un Product Goal definito e le misure dell’impatto dell’obiettivo in termini di Evidence Based Management sono fatte sul prodotto (il sito). Se l’impatto supera le soglie che ci siamo prefissati, allora vuol dire che il Product Goal è stato raggiunto. Altrimenti usiamo i dati per capire per quale ragione non abbiamo superato queste soglie. Miglioramento/adattamento continuo.

Riprendendo Evidence Based Management, per il nostro sito (prodotto), la situazione (approssimativa) è la seguente:

  • Current Value (medio): articoli e risorse scaricabili gratuite che permettono di capire e sperimentare Scrum Professionale. Possiamo fare meglio. Ce lo dicono gli indicatori in termini di visite e lettura degli articoli.
  • Unrealized Value (alto): tanti esperimenti nel cassetto che non sviluppiamo. Ce lo dicono le richieste delle persone che formiamo, i manager con cui discutiamo, ecc… Qui si possono creare business plans per ottenere finanziamenti o investitori e far crescere il prodotto.
  • Capacity to Innovate (basso): siamo molto focalizzati sul delivery di formazioni e coaching. L’innovazione è poca ed è uno dei nostri punti deboli. Qui puoi avere un’idea degli investimenti necessari per ricerca e sviluppo per il prodotto.
  • Time to Market (basso): siamo bravi ad andare dall’idea alla produzione. Un nuovo articolo del blog in tre giorni è pensato, scritto e pubblicato. Abbiamo altri indicatori di questo tipo per podcast e video che ci aiutano a capire che sotto questo aspetto non abbiamo bisogno di miglioramento. Fra le altre cose, qui si capisce quanto focus c’è in nello sviluppo del prodotto.

Essendo coscienti delle aree meno performanti, abbiamo deciso di investire nell’Unrealized Value.

Forse hai notato che ultimamente stiamo facendo qualche piccola modifica al sito. Per esempio la possibilità di registrarsi per accedere a contenuto scaricabile, oppure nuove proposte di valore come Scrum in Pratica – Team (re)startup. Questi sono tutti esperimenti che fanno parte di una strategia e ci permettono di capire meglio ciò che i visitatori considerano come valore.

Misurare gli obiettivi in Scrum
Misurare gli obiettivi

Per esempio, il mese scorso, solamente 3 persone si sono iscritte al sito per scaricare il modello per definire gli obiettivi, presente nell’articolo Gli obiettivi in Scrum. La nostra soglia era 10 download in un mese. Il prodotto ci dice che l’obiettivo non è stato raggiunto. Perché? Lo capiremo (forse) con altri esperimenti… oppure puoi dirmelo nei commenti 😚…

Altro esempio… la nuova proposta di valore Scrum in Pratica – Team (re)startup ci ha permesso di acquisire un nuovo cliente, per il quale la proposta è semplicemente perfetta. E questo dopo nemmeno un mese dalla pubblicazione dell’idea. In questo caso l’obiettivo è stato raggiunto molto prima di quello che ci aspettavamo ed è un ottimo esempio di interazione fra prodotti (sito web e formazioni).

Così abbiamo confermato la nostra idea di Unrealized Value, sperimentando. L’intuizione c’era, non la certezza. Questa è stata acquisita grazie al fatto che l’acquisto della proposta di valore è effettivamente avvenuta.

Fra qualche settimana, quindi, questa proposta passerà dall’unrealized value al current value e potremmo dire di aver migliorato entrambi perché l’unrealized value diminuisce e il current value aumenta. E qui capiamo quanto le cose sono sempre in movimento, non c’è nulla di statico.

Tutto molto logico, ma bisogna pensarci e distaccarsi dalla mania che abbiamo di concentrarsi maggiormente sull’esecuzione. Non è finita, tutto questo non lo facciamo esclusivamente per creare valore… qualcun altro ci deve guadagnare. A meno che non ti piaccia lavorare per la gloria 🏆.

Misurare gli obiettivi in Scrum e L’impatto per l’azienda

Ragionare in termini di obiettivi, da raggiungere attraverso un prodotto, permette da un lato di creare valore per l’utilizzatore e dall’altro ha un impatto per l’azienda. Questo impatto può prendere diverse forme: aumento dei guadagni, maggiore notorietà, ecc.

Prendiamo l’esempio del sito web Collective Genius: sappiamo che creiamo valore perché il numero di abbonati aumenta costantemente, certo contenuto è scaricato, il numero di visite su certe pagine ci fa capire gli argomenti da trattare in priorità, ecc. La conseguenza per noi, è un aumento della notorietà nell’arena dell’agile, più partecipanti in formazione e quindi ricavi costanti (o in aumento).

Qui si capisce quanto importante sia collaborare per capire quali sono gli obiettivi aziendali, per poterli raggiungere grazie ai nostri prodotti. Per questo dirigenza e Product Owners dovrebbero lavorare insieme per ottimizzare l’impatto che i prodotti hanno sull’azienda… ma questo è un altro discorso, che magari farò in un futuro articolo.

Conclusioni

L’agilità non vuol dire fare tutto subito e velocemente, bensì strategia e validazione costante tramite feedback quantificabile. Misurare gli obiettivi in Scrum permette di imparare e capire se le energie ed il denaro spesi stanno effettivamente creando valore o meno.

Attenzione quindi all’effetto cobra, perché avere obiettivi fissi potrebbe portarti a non massimizzare il valore creato e, nel peggiore dei casi, al disastro.

Per continuare ad imparare

Unlocking Business Agility with Evidence Based Management
Professional Agile Leadership - EBM
Gli obiettivi in Scrum

Gli obiettivi in Scrum

Gli obiettivi in Scrum

Tabella dei Contenuti

Gli obiettivi in Scrum

Saper fissare gli obiettivi in Scrum è un elemento chiave per massimizzare il valore rilasciato agli utenti del prodotto.

Alla fine di questo articolo saprai che cos’è un Product Goal ed uno Sprint Goal, come usarli per aumentare il focus, l’autonomia e controllare i rischi di uno Scrum Team.

Uno degli aspetti fondamentali dello sviluppo empirico di prodotti è quello di far emergere le soluzioni a problemi identificati. Per farlo, un’obiettivo chiaro permette di cambiare il focus dalle “esigenze da sviluppare” (spesso senza sapere realmente il perché) a un risultato che si vuole ottenere per gli utenti del prodotto (senza che le funzionalità per farlo siano tutte previste in anticipo).

Uno Scrum Master ha la responsabilità di far capire questo concetto allo Scrum Team ed all’azienda. Vediamo un modo di fare…

⚠️ Questo articolo contiene contenuto riservato ai soli utenti registrati. Se non hai ancora un account o non hai effettuato l’accesso è il buon momento per farlo e ritornare qui! ⚠️

Gli obiettivi in Scrum – il Product Goal

Il Product Goal è l’obiettivo a medio termine in Scrum, definito dal Product Owner, permette di fare un passo in più verso la visione del prodotto.

Questo è un “commitment” in Scrum, il che significa che tutto lo Scrum Team si impegna a raggiungerlo contribuendo con le proprie competenze.

Quando un Product Goal è raggiunto, se ne crea uno nuovo. Ovvero non possono esistere due (o più) Product Goal in parallelo.

 

Gestione del Product Backlog: Guida per Scrum Team
Clicca l'immagine per ascoltare l'episodio del podcast

Gli obiettivi in Scrum – lo Sprint Goal

Lo Sprint Goal è l’obiettivo a corto termine, definito dallo Scrum Team, che permette di fare un passo in più verso il raggiungimento del Product Goal

Anche questo è un “commitment” in Scrum, l’unica cosa che non può cambiare durante uno Sprint. Se lo Sprint Goal diventa obsoleto, allora il Product Owner può decidere di annullare lo Sprint e ricominciare con un nuovo Sprint Goal (caso molto raro).

Pianificazione Sprint in Scrum
Clicca l'immagine per ascoltare l'episodio del podcast

Esempi di obiettivi

Per capire meglio ecco degli esempi di Product Goal e Sprint Goal che considero corretti. Propongo diversi esempi di Sprint Goal per uno stesso Product Goal, l’ordine è completamente casuale.

Da questi esempi si possono evincere diverse cose:

    • Il Product Goal è raggiungibile con una serie di Sprint
    • C’è una coerenza fra Product Goal e Sprint Goal
    • Lo Sprint Goal è un esperimento che lo Scrum Team vuole fare, non una lista di features da implementare
    • I Goal in Scrum forniscono una direzione, non il dettaglio del lavoro da fare
    • I Goal in Scrum motivano il team a trovare soluzioni a problemi complessi
    • I Goal devono essere ambiziosi. Se avete la certezza che il goal sarà raggiunto alla fine dello Sprint, chiedetevi come potete renderlo più ambizioso
    • I Goal servono a controllare i rischi, in quanto ci aiutano a capire cosa siamo capaci di fare e cosa no. Ma anche a capire cosa ci manca per raggiungere un goal.
    • I Goal motivano le persone a dare il meglio di se per contribuire alla riuscita! Capisco che la mia competenza ha un senso ed è utile a ciò che stiamo facendo. So che da solo non potrei fare quello che stiamo facendo insieme!

Roadmap e obiettivi

Il Product Goal può essere utile per dare una visione del futuro, una roadmap da condividere con gli stakeholders.

Se il Product Owner attualmente non è capace di fornire trasparenza sulla sua strategia, allora lo Scrum Master può intervenire per aiutarlo.

Detto questo, bisogna fare attenzione a come si comunica una roadmap, in quanto l’approccio empirico di Scrum abbraccia il cambiamento e rende il futuro non (totalmente) prevedibile.

Per aiutare i Product Owner, uso spesso una versione adattata del modello di Roadmap che trovi sul sito The Product Manager di Roman Pichler (una referenza).

Gli obiettivi in Scrum - Esempio di Roadmap

Scarica il modello di Roadmap

Per aiutarti a progredire nell’utilizzo di obiettivi e roadmap, ho creato un modello ed un esempio che puoi usare nel tuo contesto lavorativo. Fammi sapere se ti è stato utile nei commenti! 

Per scaricare il contenuto, devi accedere o registrati al sito se non hai ancora un account.

Non inviamo spam e le tue informazioni sono protette. Puoi cancellare la tua iscrizione in qualsiasi momento contattandoci.

Conclusioni

Avere degli obiettivi comprensibili da tutti, ispiranti e trasparenti è un passo fondamentale verso la business agility.

Se è difficile trovare un solo Product Goal e un solo Sprint Goal per Sprint, allora vuol dire che c’è qualcosa che non va a livello di definizione del prodotto. Oppure che il lavoro è talmente orientato all’implementazione di una serie di task non coerenti gli uni con gli altri che la definizione di un obiettivo diventa praticamente impossibile.

Se questo è il caso tuo, capire come funziona Scrum e quali sono le responsabilità di un Product Owner in Scrum è un buon primo passo. 

Guidare con i valori scrum

Guidare con i Valori Scrum [E44]

ℹ️ Guidare con i valori Scrum 📅 Data: 14/04/2024 ⏱️ Durata: 11 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio esploriamo il concetto di “guidare con i valori Scrum”, dall’articolo del blog, attraverso un caso pratico di leadership Scrum. Scopriremo come i valori Scrum guidano il processo decisionale e contribuiscono a creare un ambiente di lavoro efficace, attraverso la storia di un Developer alle prese con una decisione importante.

🎧 Ascolta l’Episodio

🎯 Cosa vuol dire guidare con i valori Scrum?

Guidare con i valori Scrum rappresenta un approccio alla leadership basato sui cinque valori fondamentali di Scrum:

  • Commitment (Impegno)
  • Courage (Coraggio)
  • Focus
  • Openness (Apertura)
  • Respect (Rispetto)

🔄 Il Caso Studio

La Situazione

  • Un Developer (Luca) deve scegliere tra mantenere il proprio impegno con il team attuale o aiutare un altro team in difficoltà
  • Lo Sprint Goal è ambizioso: costruire un prototipo completo in due settimane invece delle usuali cinque
  • Il team sta facendo progressi positivi verso l’obiettivo

Vediamo cosa significa guidare con i valori Scrum!

La Decisione Basata sui Valori

  • Commitment: priorità data all’impegno preso con il team per lo Sprint Goal
  • Courage: capacità di dire “no” quando necessario
  • Focus: mantenere l’attenzione sullo Sprint Goal
  • Respect: considerare le necessità di entrambi i team
  • Openness: comunicazione trasparente delle motivazioni

💡 Benefici di guidare con i valori Scrum

  • Decisioni più chiare e allineate con gli obiettivi del team
  • Creazione di un ambiente di lavoro sicuro
  • Sviluppo dell’autonomia del team
  • Miglioramento della comunicazione
  • Rafforzamento della cultura organizzativa

⚙️ Best Practices

Per i Leader

Guidare con i valori Scrum significa:

  • Porre domande che stimolano la riflessione
  • Supportare le decisioni basate sui valori
  • Creare un ambiente sicuro per il confronto
  • Essere esempio nell’applicazione dei valori

Per il Team

  • Utilizzare i valori come guida nelle decisioni quotidiane
  • Praticare il coraggio nel dire “no” quando necessario
  • Mantenere gli impegni presi con il team
  • Comunicare apertamente le proprie motivazioni

📚 Approfondimenti Consigliati

🎓 Note del Trainer

In un’epoca dove la risoluzione di problemi complessi richiede approcci innovativi, il ruolo del Servant Leader diventa fondamentale. Non abbiamo bisogno di più manager tradizionali, ma di leader che sappiano guidare attraverso i valori, creando ambienti di lavoro dove le persone si sentono sicure nel prendere decisioni coraggiose e allineate con gli obiettivi del team

Fabio Panzavolta, Professional Scrum Trainer

🔜 Prossimo Episodio

Non perdete il prossimo episodio del podcast Scrum Italia dove continueremo ad esplorare temi fondamentali per la crescita professionale in ambito Agile.

Questo articolo è basato sull’episodio 44 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

doppi ruoli scrum innovazione tecnologica

Doppi Ruoli e Innovazione Tecnologica in Scrum [E36]

ℹ️ Doppi Ruoli e Innovazione Tecnologica in Scrum 📅 Data: 17/10/2023 ⏱️ Durata: 25 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio rispondiamo a due domande fondamentali dei nostri ascoltatori: la prima riguarda i possibili conflitti di interesse nei doppi ruoli in Scrum (Product Owner + Developer, Product Owner + Scrum Master), mentre la seconda esplora come attivare l’innovazione tecnologica in azienda attraverso il framework Scrum.

🎧 Ascolta l’Episodio

🎯 Prima Domanda: I Doppi Ruoli in Scrum

Principi Fondamentali

  • Le accountability in Scrum possono teoricamente essere ricoperte dalla stessa persona
  • Un individuo può avere le competenze per svolgere più ruoli
  • L’approccio deve essere empirico e adattativo

Considerazioni Chiave

  • Il team deve monitorare attentamente gli effetti del doppio ruolo
  • Occorre verificare l’impatto su Product Goal e Sprint Goal
  • È necessario identificare rapidamente eventuali conflitti di interesse

Segnali di Attenzione

  • Difficoltà nel raggiungimento degli Sprint Goal
  • Deterioramento della qualità del prodotto
  • Mancanza di trasparenza
  • Conflitti di interesse evidenti

🔄 Seconda Domanda: L’Innovazione Tecnologica

Ruolo del Product Owner

  • Permettere la sperimentazione
  • Non imporre soluzioni predefinite
  • Promuovere l’openness e il coraggio di sperimentare
  • Gestire il rischio limitandolo a uno sprint

Responsabilità dei Developers

  • Dedicare tempo al brainstorming
  • Studiare nuove tecnologie
  • Partecipare a hackathon e momenti di sperimentazione
  • Proporre soluzioni innovative

Ruolo dello Scrum Master

  • Assicurare la corretta comprensione e applicazione di Scrum
  • Facilitare un ambiente che promuove l’innovazione
  • Supportare il team nell’approccio empirico

💡 Best Practices per l’Innovazione

  • Definire Sprint Goal ambiziosi
  • Accettare il rischio di fallimento come opportunità di apprendimento
  • Mantenere la trasparenza sui contratti e vincoli aziendali
  • Promuovere una cultura dell’innovazione sostenibile

📚 Approfondimenti Consigliati

🎓 Note del Trainer

“L’innovazione in Scrum non è solo una questione di tecnologia, ma di approccio mentale. È fondamentale creare un ambiente dove il team si senta sicuro di sperimentare e dove il fallimento sia visto come un’opportunità di apprendimento. La chiave sta nel bilanciare correttamente le accountability e nel mantenere sempre il focus sulla creazione di valore per gli utenti.”

Fabio Panzavolta, Professional Scrum Trainer

🔜 Prossimo Episodio

Non perderti il prossimo episodio del podcast Scrum Italia dove festeggeremo i 28 anni di Scrum.

Questo articolo è basato sull’episodio 36 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

Pianificazione Sprint in Scrum

Lo Sprint Backlog: Guida alla Pianificazione Sprint [E18]

ℹ️ Pianificazione Sprint Backlog 📅 Data: 25/04/2023 ⏱ Durata: 13 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio esploriamo lo Sprint Backlog, un artefatto di Scrum che comprende lo Sprint Goal, gli elementi del Product Backlog selezionati per lo Sprint e il piano per la realizzazione dell’Incremento. Scopriremo come questo strumento supporta l’autogestione del team e contribuisce al successo dello Sprint.

🎧 Ascolta l’Episodio

🎯 Cos’è lo Sprint Backlog

Lo Sprint Backlog è un artefatto gestito dai Developer, contiene la pianificazione dello Sprint che si compone di tre elementi essenziali:

  • Lo Sprint Goal (il perché)
  • Gli elementi selezionati dal Product Backlog (il cosa)
  • Il piano attuabile per la consegna dell’Incremento (il come)

🔄 Caratteristiche Principali

Gestione e Responsabilità

  • Gestito esclusivamente dai Developer
  • Aggiornato costantemente durante lo Sprint
  • Riflette l’apprendimento e l’adattamento del team

Focus sull’Autogestione

  • Nessuna interferenza esterna nella gestione
  • Developers collaborano alla pari senza gerarchie
  • Flessibilità nel raggiungimento dello Sprint Goal

💡 Benefici dello Sprint Backlog

  • Fornisce trasparenza sul lavoro pianificato
  • Supporta l’ispezione dei progressi durante il Daily Scrum
  • Promuove la collaborazione del team
  • Mantiene il focus sullo Sprint Goal

⚙ Best Practices

Gestione Efficace

  • Mantenere lo Sprint Goal visibile e accessibile
  • Aggiornare regolarmente il backlog
  • Collaborare con il Product Owner per eventuali modifiche

Negoziazione dei Cambiamenti

  • Discutere le modifiche necessarie con il Product Owner
  • Mantenere la coerenza con lo Sprint Goal
  • Assicurare che i cambiamenti non compromettano l’obiettivo

📚 Approfondimenti Consigliati

  • La Scrum Guide: Sprint Backlog e Sprint Goal
  • Tecniche di visualizzazione del backlog
  • Gestione efficace dei cambiamenti durante lo Sprint
  • Pratiche di autogestione del team

🎓 Note del Trainer

“Lo Sprint Backlog non è solo un elenco di attività, ma uno strumento che promuove l’autogestione e la collaborazione del team. La chiave del successo sta nella sua trasparenza e nella capacità di adattarsi alle scoperte fatte durante lo Sprint, mantenendo sempre il focus sullo Sprint Goal.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo la Sprint Review in Scrum.

Questo articolo è basato sull’episodio 18 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

artefatti Scrum e loro impegni

Gli Artefatti Scrum: Trasparenza e Impegno nel Framework Agile [E16]

ℹ️ Artefatti Scrum 📅 Data: 11/04/2023 ⏱ Durata: 15 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio esploriamo gli artefatti di Scrum: Product Backlog, Sprint Backlog e Increment. Scopriremo come questi elementi fondamentali del framework rappresentano il lavoro e il valore, e come sono collegati ai rispettivi impegni (commitment) che ne garantiscono l’efficacia.

🎧 Ascolta l’Episodio

🎯 Cos’è un Artefatto in Scrum

Un artefatto in Scrum è un elemento creato dall’intelligenza umana che rappresenta informazione, lavoro o valore. Gli artefatti sono progettati per:

  • Massimizzare la trasparenza delle informazioni chiave
  • Fornire una base comune per l’ispezione e l’adattamento
  • Garantire la visibilità dell’avanzamento del lavoro

🔄 I Tre Artefatti Principali

Product Backlog

  • Contiene tutto il lavoro da realizzare per il prodotto
  • È associato al Product Goal come impegno
  • Rappresenta la visione a medio-lungo termine

Sprint Backlog

  • Contiene il lavoro pianificato per lo Sprint corrente
  • È legato allo Sprint Goal come impegno
  • Ha una durata massima di un mese

Increment

  • Rappresenta l’ultima versione del prodotto
  • È associato alla Definition of Done come impegno
  • Riflette l’approccio iterativo e incrementale di Scrum

💡 Gli Impegni (Commitment)

Ogni artefatto è associato a un impegno specifico:

  • Product Goal: Impegno a medio termine visibile nel Product Backlog
  • Sprint Goal: Impegno a breve termine (massimo un mese) visibile nello Sprint Backlog
  • Definition of Done: Impegno sulla qualità dell’Increment

⚙️ Importanza degli Impegni

Gli impegni in Scrum:

  • Rinforzano l’empirismo e i valori Scrum
  • Garantiscono la trasparenza per il team e gli stakeholder
  • Supportano il processo decisionale
  • Mantengono alta la qualità del prodotto

📚 Approfondimenti Consigliati

  • La Scrum Guide: Artefatti e loro impegni
  • Pattern di trasparenza in Scrum
  • Gestione efficace degli artefatti
  • Metriche per misurare l’avanzamento

🎓 Note del Trainer

“Gli artefatti in Scrum non sono semplici documenti o deliverable, ma rappresentano impegni concreti che il team prende verso la qualità e il valore. La loro corretta gestione è fondamentale per mantenere la trasparenza e permettere un’efficace ispezione e adattamento.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo il Product Backlog e il Product Goal in dettaglio.

Questo articolo è basato sull’episodio 16 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

Daily Scrum in Scrum Framework

Evento Daily Scrum: Sincronizzazione Quotidiana [E13]

ℹ️ Evento Daily Scrum 📅 Data: 21/03/2023 ⏱️ Durata: 13 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio esploriamo il Daily Scrum, noto anche come daily standup, l’evento quotidiano di 15 minuti che permette ai Developer di sincronizzarsi e pianificare il lavoro delle successive 24 ore. Scopriremo come questo evento del framework Scrum contribuisce al successo dello Sprint e del team.

🎧 Ascolta l’Episodio

🎯 Cos’è il Daily Scrum

Il Daily Scrum, spesso chiamato anche scrum daily meeting, è un evento di 15 minuti che coinvolge i Developer dello Scrum Team. Il suo scopo principale è:

  • Ispezionare l’avanzamento verso lo Sprint Goal
  • Adattare lo Sprint Backlog secondo le esigenze
  • Pianificare il lavoro delle prossime 24 ore

🔄 Caratteristiche Principali

Timeboxing e Partecipanti

  • Durata massima: 15 minuti
  • Si tiene ogni giorno, idealmente alla stessa ora e luogo
  • Partecipanti principali: Developer
  • Product Owner e Scrum Master possono assistere (se autorizzati dai developers) o partecipare come Developer (se contribuiscono alla creazione dell’Increment)

Focus sull’Autogestione

  • I Developer scelgono struttura e tecnica preferita per il daily standup
  • Concentrazione sullo Sprint Goal
  • Promozione dell’autogestione del team

💡 Benefici del Daily Scrum

  • Migliora la comunicazione nel team
  • Identifica rapidamente gli impedimenti
  • Promuove il processo decisionale veloce
  • Elimina la necessità di altri meeting
  • Aumenta la trasparenza del lavoro

⚙️ Best Practices

Gestione Efficace

  • Task dimensionati per essere completati in una giornata
  • Visibilità del movimento delle attività
  • Identificazione rapida dei problemi
  • Collaborazione invece di lavoro in silos

Gestione delle Discussioni

  • Separare rilevazione e risoluzione dei problemi
  • Utilizzare post-it per tracciare temi da approfondire
  • Pianificare discussioni separate per i dettagli tecnici dopo il daily scrum meeting

📚 Approfondimenti Consigliati

  • La Scrum Guide: Daily Scrum e altri eventi Scrum
  • Tecniche di facilitazione per Daily Scrum efficaci
  • Metriche e visualizzazione dell’avanzamento
  • Pattern di comunicazione efficace nei meeting agili

🎓 Note del Trainer

“Il Daily Scrum non è solo un momento di aggiornamento, ma una vera e propria occasione per i Developers di sincronizzarsi e mantenere il focus sullo Sprint Goal. La chiave del successo sta nella sua regolarità e nella capacità di mantenere l’evento conciso e focalizzato.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo la Sprint Review in Scrum.

Questo articolo è basato sull’episodio 13 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

Sprint Planning Scrum

Sprint Planning in Scrum: La Guida Definitiva [E12]

ℹ️ Sprint Planning in Scrum 📅 Data: 14/03/2023 ⏱️ Durata: 13 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio, esploriamo lo Sprint Planning secondo la Scrum Guide (versione Novembre 2020). Analizziamo come questo evento dà il via allo Sprint e stabilisce le basi per il successo del team.

🎧 Ascolta l’Episodio

🎯 I Tre Argomenti dello Sprint Planning

1. Perché questo Sprint è di valore?

  • Il Product Owner propone come incrementare valore nel prodotto
  • Lo Scrum Team collabora per definire lo Sprint Goal
  • Focus sugli outcome per gli stakeholder

2. Cosa si può fare in questo Sprint?

  • I Developer selezionano elementi dal Product Backlog
  • Selezione basata su:
    • Performance precedenti
    • Capacità futura
    • Definition of Done

3. Come si svolgerà il lavoro?

  • Decomposizione in task giornalieri
  • Pianificazione tecnica dettagliata
  • Autonomia dei Developer nelle decisioni

⏱️ Timeboxing e Struttura

  • 8 ore massimo per Sprint mensili
  • Proporzionalmente più breve per Sprint più corti
  • Concentrazione delle attività di pianificazione

🔄 Lo Sprint Backlog

  • Include:
    • Sprint Goal (commitment fisso)
    • Elementi del Product Backlog selezionati
    • Piano di consegna dettagliato

💡 Punti Chiave

  • Lavoro collaborativo dell’intero Scrum Team
  • Autonomia dei Developer nella selezione del lavoro
  • Flessibilità nella pianificazione dettagliata
  • Focus sulla trasparenza e comunicazione

📚 Approfondimenti Consigliati

  • Scrum Guide 2020
  • Sprint Goal e sua importanza
  • Tecniche di decomposizione del lavoro
  • Stima e previsione in Scrum

🎓 Note del Trainer

“Lo Sprint Planning è come un concentratore di riunioni. Tutto quello che c’è da fare per il prossimo mese è discusso durante queste ore, eliminando la necessità di ulteriori incontri di pianificazione.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo il Daily Scrum e la loro importanza nell’ispezione e adattamento quotidiano.

Questo articolo è basato sull’episodio 12 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.