Sprint Goal: non c’è successo se non c’è un obiettivo.
Lo Scrum Framework è costituito da pochi elementi, tutti con un ruolo rilevante per il successo dei team che implementano Scrum. Fra questi lo Sprint Goal è forse uno di quegli elementi che viene più spesso sottovalutato, mal interpretato o addirittura ignorato.
Anche per chi non ha letto la Scrum Guide, ma ha un’infarinatura di base su come funziona Scrum, è facile intuire che lo Sprint Goal è l’obiettivo di uno Sprint. Racchiude il “perché” del lavoro che è stato selezionato per lo Sprint e dovrebbe essere considerato come il faro, la meta inamovibile per il team durante uno Sprint.
Spesso, invece, viene data più enfasi ai singoli elementi del Product Backlog selezionati per lo Sprint anziché all’obbiettivo che si vuole raggiungere.
Uno dei comuni fraintendimenti riguardo Scrum è che una volta pianificato uno Sprint nulla debba cambiare. Ogni modifica è vista come “infrangere le regole di Scrum” e crea frustrazione e malcontento.
In realtà questa è una concezione errata che conferisce un’idea di rigidità del tutto in contrapposizione con i principi fondamentali di Agile e Scrum.
La Scrum Guide esprime chiaramente che man mano che il team lavora verso un obiettivo, l’esatto lavoro necessario per raggiungerlo può cambiare, ciò che deve rimanere intatto per aiutare il team a rimanere focalizzato e per fornire coerenza è lo Sprint Goal.
Una famosa citazione di Jeff Bezos (n.d.r. fondatore di Amazon) recita:
“Noi siamo testardi sulla visione, flessibili nei dettagli”
Questa semplice frase riassume perfettamente il mindset con cui ogni Scrum Team dovrebbe lavorare: unito e concentrato per raggiungere lo Sprint Goal e flessibile sul lavoro necessario a raggiungerlo.
In teoria sembra semplice e quasi liberatorio: ci poniamo un obiettivo per uno Sprint, concentriamo le nostre forze sul raggiungimento di questo obiettivo e siamo aperti a modificare i dettagli di implementazione purché otteniamo il risultato finale che da valore al nostro Sprint.
Perché allora tanti team hanno difficoltà anche solo a definire uno Sprint Goal?
Ogni volta che un team esprime difficoltà nell’implementare Scrum mi risuonano in mente le parole del mio primo mentore:
“Scrum doesn’t solve problems, surfaces them”
“Scrum non risolve i problemi, li fa emergere”
Se abbiamo continuamente difficoltà a definire lo Sprint Goal, probabilmente c’è qualcos’altro che non va nel nostro team o nel nostro progetto o semplicemente nel modo in cui implementiamo Scrum.
Una delle cose che sento ripetere più spesso da team che hanno difficoltà a definire uno Sprint Goal è
“Ci sono troppe cose da fare durante uno Sprint, tutte importanti e hanno poco o nulla in comune fra di loro, come possiamo avere un solo Sprint Goal?”
In casi come questo, spesso l’impossibilità di definire uno Sprint Goal è la manifestazione di un sintomo le cui cause possono essere molteplici.
Se “ci sono troppe cose da fare durante uno Sprint”, può darsi che lo Sprint sia troppo lungo. Sprint più brevi potrebbero aiutare a ridurre la varietà di lavoro e permettere al team di focalizzarsi su un obiettivo alla volta.
Se poi le diverse “cose da fare durante uno Sprint” sono “tutte importanti”, vuol dire chiaramente che il team, o l’organizzazione, ha difficoltà a stabilire delle priorità e quando tutto è ugualmente importante, nulla alla fine è davvero importante. Nuovamente, il “trucco” di ridurre la durata degli Sprint al minimo potrebbe aiutarci a forzare la scelta di pochi elementi e quindi decidere la reale importanza e priorità. Ma, ancor di più, sarebbe bene fermarsi a riflettere su come definire le priorità e il valore degli elementi del nostro Product Backlog.
Altre volte il motivo per cui gli Sprint sono pieni di elementi non collegati fra di loro è che il prodotto è molto complesso e subisce l’influenza di diversi gruppi di stakeholder tutti con interessi diversi. In queste situazioni spesso lo Scrum Team decide di accontentare tutti mostrando continuo, seppur minimo, progresso in ognuna delle aree di interesse dei vari stakeholder invece di concentrarsi sul reale valore per il business e il cliente finale.
Fin qui abbiamo visto qual è il motivo principale per cui è importante definire lo Sprint Goal e quali possono essere alcune comuni cause della difficoltà di creare uno Sprint Goal. Ma c’è da porsi un’altra domanda fondamentale:
Quali sono le conseguenze del trascurare l’importanza della definizione di uno Sprint Goal?
Abbiamo accennato al fatto che lo Sprint Goal fornisce il “perché” di uno Sprint. Va precisato che lo Sprint Goal ha delle implicazioni pratiche per uno Scrum Team che sono esplicitamente riportate nella Scrum Guide:
- Lo Sprint Goal è l’unico obiettivo per lo Sprint;
- Durante lo Sprint non sono apportate modifiche che potrebbero mettere a repentaglio lo Sprint Goal;
- Uno Sprint può essere annullato se lo Sprint Goal diventa obsoleto;
- Lo scopo del Daily Scrum è quello di ispezionare l’avanzamento verso lo Sprint Goal;
- I Developer sono responsabili di adattare quotidianamente la pianificazione allo Sprint Goal;
Se non definiamo lo Sprint Goal eliminiamo l’obiettivo fondamentale dello Sprint, così facendo rimuoviamo l’opportunità di ispezionare e adattarci. Sarebbe come fare un viaggio senza meta ne scopo: di tanto in tanto può essere piacevole e rilassante, ma a lungo andare diventa un vagare inutile e frustrante.
A volte il vero motivo per cui alcuni team finiscono con l’ignorare la definizione dello Sprint Goal è che fa comodo non avere un obiettivo da raggiungere perché elimina la possibilità di fallimento, ma è solo un’illusione perché se non c’è possibilità di fallimento non c’è neanche successo e il lavoro si riduce a mera esecuzione.
Fatemi sapere se anche voi avete difficoltà a stabilire lo Sprint Goal e come affrontate la situazione quando questo accade.
