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. 

Gestione del Product Backlog: Guida per Scrum Team

Gestione del Product Backlog: guida per Scrum Team [E17]

ℹ️ Gestione del Product Backlog 📅 Data: 18/04/2023 ⏱ Durata: 19 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 Product Backlog, uno degli artefatti di Scrum che rappresenta l’unica fonte di lavoro per lo Scrum Team. Scopriremo come questo “living artifact” evolve nel tempo e come contribuisce al successo del prodotto attraverso una gestione efficace e collaborativa.

🎧 Ascolta l’Episodio

🎯 Cos’è il Product Backlog

Il Product Backlog è un elenco emergente e ordinato di tutto ciò che è necessario per migliorare il prodotto. Rappresenta:

  • L’unica fonte di lavoro per lo Scrum Team
  • Un documento vivente che evolve con il prodotto
  • Il punto di riferimento per qualsiasi modifica o miglioramento

🔄 Caratteristiche Principali

Elementi Ready

  • Gli elementi nella parte alta del Product Backlog sono considerati “Ready”
  • Sufficientemente dettagliati per essere selezionati nello Sprint Planning
  • Raggiungono la trasparenza necessaria dopo il Refinement

Product Backlog Refinement

  • Attività continuativa di scomposizione degli elementi
  • Il Product Backlog refinement aggiunge dettagli come descrizione, ordine e dimensione
  • Collaborazione tra Product Owner e Developers
  • Stime effettuate esclusivamente dai Developers

💡 Product Goal

  • Descrive uno stato futuro del prodotto
  • Serve come obiettivo a lungo termine per lo Scrum Team
  • Deve essere raggiunto o abbandonato prima di definirne uno nuovo
  • È visibile nel Product Backlog

⚙️ Best Practices

Gestione Product Backlog

  • Elementi più piccoli e atomici possibile
  • Trasparenza nel movimento delle attività
  • Gestione efficace attraverso la collaborazione continua
  • Visibilità degli impegni del team

Responsabilità e Ruoli

  • Lo Scrum Product Owner gestisce il Product Backlog
  • Developers stimano la dimensione degli elementi
  • Tutto lo Scrum Team partecipa al Refinement
  • Product Owner definisce il Product Goal

Responsabilità e Ruoli

  • Product Owner gestisce il Product Backlog
  • Developers stimano la dimensione degli elementi
  • Tutto lo Scrum Team partecipa al Refinement
  • Product Owner definisce il Product Goal

📚 Approfondimenti Consigliati

  • La Scrum Guide: Product Backlog e Product Goal
  • Tecniche di Refinement efficace
  • Gestione degli elementi del Product Backlog
  • Pattern di collaborazione nel Refinement

🎓 Note del Trainer

“Il Product Backlog non è una semplice lista di requisiti, ma un artefatto vivente che riflette l’evoluzione del prodotto e le necessità degli stakeholder. La chiave del successo sta nella sua gestione dinamica e nella collaborazione continua tra Product Owner e Developers.”

🔜 Prossimo Episodio

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

Questo articolo è basato sull’episodio 17 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.