Come definire un obiettivo di sprint (con esempi)

Un obiettivo dello sprint è una singola frase che spiega perché vale la pena svolgere lo sprint. È l’unico risultato a cui il team si impegna: ciò che sarà effettivamente vero al termine dello sprint. Tutto ciò che il team seleziona dovrebbe essere funzionale a tale obiettivo e, quando i tempi si fanno stretti, è proprio l’obiettivo a indicare quale attività privilegiare e quale scartare.

La maggior parte dei team considera l’obiettivo come una sintesi dei ticket che hanno selezionato. Si tratta di un approccio errato, ed è proprio per questo che così tanti obiettivi risultano inutili.

L’obiettivo viene prima della portata

Stabilisca prima l’obiettivo, poi scelga il lavoro che contribuisca al suo raggiungimento. Un obiettivo ricavato a ritroso da una serie di ticket già selezionati («consegnare gli elementi 4, 7 e 12») non è un obiettivo: è un indice. Non può aiutarLa a prendere una decisione, poiché non esprime alcuna opinione su ciò che conta davvero.

L’ordine è il punto fondamentale. Quando si concorda il risultato prima di definire l’ambito, la selezione diventa una serie di semplici domande: questo elemento ci avvicina all’obiettivo? Se sì, lo si include. Se no, è meglio che ci sia un motivo molto valido — una correzione di sicurezza, una dipendenza imprescindibile — altrimenti viene rimandato. Quando si definisce prima l’ambito, ogni elemento sembra avere la stessa importanza, e non c’è nulla da tagliare quando il giovedì prende una piega inaspettata.

Che effetto ha un gol così decisivo

Un obiettivo si rivela valido quando è in grado di svolgere tre funzioni:

• Indica un risultato, non un elenco di attività. «Gli utenti possono reimpostare la propria password senza contattare l’assistenza» descrive cosa è cambiato nella realtà. «Completare l’epic relativo alla reimpostazione della password» indica quale bacheca Jira consultare.
• Vi aiuta a fare delle scelte prioritarie. La vera prova di un obiettivo è l’ultimo giorno dello sprint, quando non tutto andrà a buon fine. Un buon obiettivo Le indica immediatamente cosa privilegiare. Se l’obiettivo è «consentire agli utenti di reimpostare la propria password», si implementa la procedura di reimpostazione e si tralascia la riprogettazione dell’e-mail, che è un elemento accessorio. Se l’obiettivo è «portare a termine i ticket», non si ha alcun criterio su cui basare le scelte, quindi tutto subisce un leggero ritardo e nulla viene consegnato in modo impeccabile.
• Il team deve poterlo ripetere a memoria. Un obiettivo che nessuno è in grado di enunciare è un obiettivo a cui nessuno si attiene. Se il team deve aprire il documento di pianificazione per ricordarsi perché si trova lì, significa che l’obiettivo è troppo lungo o troppo vago.

Obiettivi deboli contro obiettivi forti

La differenza tra un obiettivo debole e uno forte consiste quasi sempre nel fatto che nel primo caso si definisce un’attività, mentre nel secondo si definisce un risultato.

Gol debole	Perché non funziona	Gol spettacolare
”Lavorare alla riprogettazione della procedura di pagamento.”	Indica un’area, non un risultato. Non c’è un traguardo.	”Un cliente abituale può completare la procedura di pagamento in meno di un minuto dal proprio dispositivo mobile."
"Chiudere 40 story point del backlog.”	Un risultato è un obiettivo a cui si deve tendere, non un fine in sé.	”Elenchi i tre motivi principali per cui i clienti contattano l’assistenza in merito alla fatturazione."
"Migliorare le prestazioni e correggere i bug.”	Due obiettivi, nessuna priorità, nessun compromesso possibile.	”La dashboard si carica in meno di due secondi per gli account con oltre 10.000 record."
"Completare la funzione di creazione dei report.”	Il termine «finito» nasconde l’ambito; di chi è questa definizione di «finito»?	”I responsabili possono esportare un rapporto settimanale del team in formato PDF senza bisogno del nostro aiuto.”

Si noti che gli obiettivi ben definiti hanno tutti una struttura comune: un utente o un sistema specifico, che svolge un’azione specifica, secondo uno standard specifico. Si potrebbe illustrare ciascuno di essi e i presenti concorderebbero, senza alcuna obiezione, sul fatto che sia stato raggiunto o meno.

Un unico obiettivo, non diversi

Concentratevi su un unico obiettivo. È proprio l’unicità dell’obiettivo a rendere possibili i compromessi: con due obiettivi in conflitto tra loro, non vi è alcun principio da difendere quando il tempo a disposizione si esaurisce, e si finisce per tornare alla situazione in cui “tutto scivola un po’”.

Se il lavoro si rifiuta davvero di rientrare in un unico obiettivo, consideratelo un segnale piuttosto che un problema da nascondere. Di solito significa che lo sprint è troppo carico, oppure che due flussi di lavoro sono stati uniti in un unico sprint che risulterebbe più chiaro se fossero due. Occasionalmente, una piccola quantità di attività non correlate, volte semplicemente a garantire il funzionamento quotidiano, si affianca all’obiettivo: ciò va bene, purché tutti sappiano che si tratta di un peso in eccesso, non della missione vera e propria.

A chi appartiene la porta?

Il Product Owner definisce l’intento, ovvero la motivazione aziendale per cui questo sprint è più importante rispetto alle alternative. L’intero team trasforma tale intento in un obiettivo verso cui possa effettivamente impegnarsi, il che significa che gli sviluppatori devono ritenere che sia realizzabile con la capacità a disposizione. Un obiettivo in cui il team non crede è un semplice desiderio con una scadenza.

Una volta stabilito un obiettivo per cui valga la pena impegnarsi, il resto della pianificazione diventa più semplice: l’agenda lo utilizza come criterio di selezione delle attività, mentre lo scrum quotidiano lo impiega come parametro di riferimento per misurare i progressi. L’obiettivo fissato il lunedì è il punto di riferimento che guida il team per tutta la durata dello sprint.

Domande frequenti

Che cos’è un obiettivo di sprint?

Un obiettivo dello sprint è una singola frase che spiega perché vale la pena svolgere lo sprint: l’unico risultato a cui il team si impegna a raggiungere. Viene definito durante la pianificazione dello sprint, prima della definizione dell’ambito, e fornisce al team un obiettivo condiviso a cui contribuiscono gli elementi del backlog selezionati. È la ragione per cui lo sprint esiste, non un elenco dei ticket in esso contenuti.

Quali sono le caratteristiche di un buon obiettivo di sprint?

Un buon obiettivo di sprint definisce un risultato, non un elenco di attività; è sufficientemente specifico da indicare cosa tralasciare quando i tempi si fanno stretti; e l’intero team è in grado di enunciarlo a memoria. Se il vostro obiettivo è semplicemente «portare a termine questi ticket», non potrà aiutarvi a operare delle scelte — che è proprio la funzione principale di un obiettivo.

Chi stabilisce l’obiettivo dello sprint?

Il Product Owner definisce l’intento — ovvero la ragione aziendale per cui questo sprint è importante — e l’intero team lo trasforma in un obiettivo verso cui impegnarsi durante la fase di pianificazione. Si tratta di una collaborazione, non di una direttiva. Gli sviluppatori devono essere convinti che l’obiettivo sia realizzabile con le risorse disponibili; in caso contrario, si tratterebbe solo di un desiderio.

Uno sprint può avere più di un obiettivo?

Puntate a un unico obiettivo. È proprio un unico obiettivo che consente al team di operare delle scelte sotto pressione: con due obiettivi in conflitto tra loro, non vi è alcun principio da tutelare quando il tempo stringe. Se il lavoro si divide effettivamente in due parti, spesso ciò indica che lo sprint sta cercando di fare troppo, oppure che il lavoro di due team è stato unito in un unico sprint.