Epic Agile: definizione, esempi e modelli

Riepilogo: un epic Agile è una porzione di lavoro che può essere suddivisa in task specifici (chiamati storie utente) in base alle esigenze/richieste dei clienti o degli utenti finali. Gli epic sono una pratica importante per i team Agile e DevOps.

Se utilizzi le pratiche Agile e DevOps, gli epic servono a gestire i task. Si tratta di una porzione di lavoro definita che viene segmentata in task specifici (chiamati "story" o "user story") in base alle esigenze/richieste dei clienti o degli utenti finali.Un modello di monitoraggio dei task consente ai team di organizzare i propri task, definirne le priorità e monitorarli in modo efficace.

Gli epic sono un modo utile per organizzare il lavoro e creare una gerarchia. L'idea è di suddividere il lavoro in porzioni rilasciabili in modo da completare effettivamente i progetti di grandi dimensioni e continuare a rilasciare valore ai clienti su base regolare. Gli epic aiutano i team a suddividere il proprio lavoro, pur continuando a lavorare verso un obiettivo più grande.

Mantenere l'agilità quando si organizzano task di grandi dimensioni, come gli epic, non è un compito da poco. Imparare in che modo gli epic si relazionano con le giuste best practice Agile e DevOps è una competenza essenziale a prescindere dalle dimensioni dell'organizzazione.

L'epic corrisponde a una grande porzione di lavoro che può essere suddivisa in varie story più piccole, a volte chiamate "ticket" in Jira. Gli epic spesso includono più team e più progetti e possono anche essere monitorati su più board.

Gli epic vengono quasi sempre consegnati su una serie di sprint. Man mano che un team impara di più su un epic tramite le attività di sviluppo e il feedback dei clienti, le storie utente vengono aggiunte e rimosse secondo necessità. Questa è la chiave degli epic Agile: l'ambito è flessibile, basato sul feedback dei clienti e sul ritmo del team.

Immaginiamo che sia il 2050 e che lavoriamo per un'organizzazione di viaggi spaziali ricreativi. Facciamo circa una decina di lanci all'anno, quindi ogni lancio non è la cosa più importante che facciamo nell'arco di un anno, ma è ancora lontano dal diventare una routine e richiederà molte ore di lavoro per essere completato. Si tratta di una dimensione perfetta per un epic.

L'epic di esempio, "Lancio del turismo nello spazio di marzo 2050", include story per elementi di lavoro di routine oltre che story volte a migliorare gli aspetti chiave del lancio dello shuttle, dai clienti che acquistano i biglietti al lancio del razzo stesso. Pertanto, più team contribuiranno a questo epic lavorando su una vasta gamma di story.

Il team software che supporta l'acquisto dei biglietti per il lancio di marzo 2050 potrebbe strutturare l'epic in questo modo:

Allo stesso tempo, i team di propulsione potrebbero contribuire allo stesso epic con queste story:

Un epic dovrebbe fornire al team di sviluppo tutto ciò di cui ha bisogno per avere successo. Da un punto di vista pratico, questo è il livello più alto della gerarchia del lavoro. Tuttavia, capire come un epic si relaziona con altre strutture Agile fornisce contesto importante per il lavoro di sviluppo quotidiano.

• La roadmap di prodotto è un piano d'azione su come un prodotto o una soluzione si evolverà nel tempo.
• Il tema è un obiettivo dell'organizzazione alla base della creazione di epic e iniziative.
• La roadmap di prodotto è espressa e visualizzata come un insieme di iniziative tracciate lungo una timeline.
• Dividere le iniziative in epic aiuta a fare in modo che il lavoro quotidiano del team, espresso in story più piccole, resti collegato agli obiettivi aziendali generali.

Un insieme di epic completati guida un'iniziativa specifica, che consente al prodotto nel suo complesso di continuare a svilupparsi ed evolversi insieme alle richieste del mercato e dei clienti oltre che ai temi organizzativi.

Nell'esempio sopra, un tema sarebbe l'aumento dei lanci dello space shuttle, la roadmap seguirebbe l'aumento dei lanci da 3 per trimestre a 4, le iniziative sarebbero ridurre i costi e aumentare le vendite dei biglietti e ogni epic avanzerebbe verso le iniziative.

Quando crei un nuovo epic, tieni in considerazione gli altri strumenti di pianificazione e organizzazione che il tuo team potrebbe già utilizzare. Creare epic sugli obiettivi trimestrali o sugli OKR di un team è un ottimo inizio. Quando crei un epic, considera quanto segue:

• Creazione di report: crea epic per i progetti che i manager e i dirigenti vorranno tenere d'occhio.
• Storytelling: usa gli epic e le story che li compongono come meccanismo per raccontare la storia di come sei arrivato allo stato attuale di una funzione o di un prodotto.
• Cultura: lascia che la cultura organizzativa imponga le dimensioni e la granularità di un epic.
• Tempo: la maggior parte dei team di sviluppo fa affidamento sui framework di stima anziché sul tempo, ma è un controllo che vale la pena fare per assicurarsi che il completamento degli epic richiederà un paio di settimane. Un intervallo di tempo né troppo lungo, né troppo corto.

Scopri come funzionano gli epic in Jira.

Suddividere un epic in story più pratiche aiuta a comprendere un progetto e a mantenere lo slancio, ma può essere un task arduo per i meno esperti. Non esiste una soluzione valida per tutti per creare story da un epic, ma ci sono molte buone opzioni da considerare:

• Ruolo utente o utente tipo: crea una story unica per ogni utente tipo. "Accesso più rapido per i nuovi visitatori", "accesso più rapido per i clienti abituali" ecc.
• Passaggi ordinati: suddividi il processo e crea una story per ogni passaggio.
• Cultura: lascia che le norme del team stabiliscano se una story è un task veloce o un progetto di una settimana.
• Tempo: salvo un'altra convenzione concordata, le story di design che possono essere completate in uno sprint o meno.

Non esiste una definizione universale che tracci una linea tra una grande story e un epic. In generale, qualsiasi ambito di lavoro che il team stima verrà completato in "settimane" (o più tempo), piuttosto che in "ore" o "giorni" dovrebbe essere considerato un epic e suddiviso in story più piccole.

I grafici burn-down possono essere utilizzati per visualizzare gli epic e servono a mantenere i team motivati e gli stakeholder aziendali informati. L'agilità di un'organizzazione si vede negli ottimi grafici burn-down degli epic.

I grafici burn-down degli epic mostrano la quantità effettiva e stimata di lavoro da svolgere in uno sprint o epic. L'asse x orizzontale del grafico burn-down indica il tempo, mentre l'asse y verticale indica story o ticket.

Utilizza un grafico burn-down per tenere traccia del lavoro totale rimanente e per fare una previsione sulla probabilità di raggiungere l'obiettivo dello sprint. Monitorando il lavoro rimanente durante l'iterazione, il team può gestire l'avanzamento e agire di conseguenza.

Monitorando un grafico burn-down, diventa chiaro come sta avanzando il team e dove si trovano i bloccanti. Avere questi punti di dati chiaramente visibili fa in modo che tutti si trovino sulla stessa lunghezza d'onda e facilita una conversazione aperta sull'evoluzione del prodotto e sulle previsioni di completamento. Senza contare che la trasparenza crea fiducia!

Scopri come configurare i grafici burn-down in Jira

Dopo aver imparato come funziona la creazione di epic e story, potresti fare ancora di più e scoprire come ottimizzare i processi utilizzando l'automazione. Ecco tre delle regole di automazione più comuni utilizzate per gli sprint in Jira.

1. Aggiungi automaticamente tre story al momento della creazione di un epic. Vai alla regola.
2. Chiudi automaticamente le story quando l'epic è contrassegnato come completato. Vai alla regola.
3. Cambia lo stato di un epic quando cambia lo stato di uno dei suoi ticket collegati. Vai alla regola.

Consulta queste regole di automazione e centinaia di altre regole nella libreria dei modelli di Jira Automation.

Vai alla libreria

Gli epic non sono la base assoluta di un programma Agile, ma sono i promotori pratici della maggior parte dei team Agile e DevOps. Capire dove si inseriscono in un programma Agile sano crea contesto per il tuo lavoro, mentre suddividerli in story contribuisce allo slancio.