Guida Agile · Pratiche Agile
Epic vs story vs task: la gerarchia del lavoro Agile spiegata
Epic, user story e task sono tre livelli della gerarchia del lavoro Agile. Un'epic è un obiettivo ampio che si estende su più sprint, una user story è una piccola porzione di valore per l'utente che rientra in uno sprint e un task è un passaggio tecnico necessario per completare una story.
Punti chiave
- Le epic sono obiettivi ampi, le story sono piccole porzioni di valore per l'utente e i task sono passaggi tecnici.
- Story ed epic forniscono valore; i task da soli no.
- Il product owner definisce epic e story; gli sviluppatori creano i task.
- Mantenete la gerarchia semplice e coerente in tutto il team.
La gerarchia in sintesi
| Livello | Che cos'è | Dimensione tipica | Scritto di solito da |
|---|---|---|---|
| Iniziativa o tema | Un obiettivo ampio o un'area di interesse | Da mesi a un anno o più | Leadership, product management |
| Epic | Un ampio insieme di lavoro con un unico obiettivo | Diversi sprint | Product owner o product manager |
| User story | Una piccola porzione di valore per un utente | Pochi giorni; rientra in uno sprint | Product owner, insieme al team |
| Attività | Un passaggio tecnico per completare una story | Da qualche ora a un giorno | Gli sviluppatori che svolgono il lavoro |
Differenze principali
| Epic | User story | Attività | |
|---|---|---|---|
| Scopo | Raggruppare story correlate sotto un obiettivo | Fornire valore visibile a un utente | Scomporre una story in passaggi |
| Punto di vista | Risultato per il business o per l'utente | Utente | Tecnico o del team |
| Fornisce valore di per sé? | Sì, una volta completate le sue story | Sì | No |
| Stimato in | Dimensione approssimativa o somma degli story point | Story point o simili | Ore, o non stimato |
| Compare in | Roadmap e piano di rilascio | Product backlog e sprint backlog | Sprint backlog e task board |
| Completato quando | Il suo obiettivo è raggiunto | Criteri di accettazione e Definition of Done sono soddisfatti | Il passaggio è completato |
Esempio svolto
Epic: Prenotazione online dei corsi per una catena di palestre.
- Story: In qualità di socio, voglio prenotare un posto in un corso in modo che sia riservato a me (5 punti).
- Task: realizzare il pulsante di prenotazione e la schermata di conferma (4 ore).
- Task: aggiungere l'endpoint di prenotazione e il controllo della capienza (6 ore).
- Task: scrivere test automatizzati per corsi al completo e con posti disponibili (3 ore).
- Task: aggiornare l'orario per mostrare i posti rimanenti (2 ore).
- Story: In qualità di socio, voglio cancellare una prenotazione in modo che qualcun altro possa prendere il mio posto (3 punti).
- Task: aggiungere un pulsante Annulla con conferma (2 ore). Task: liberare il posto e avvisare la lista d'attesa (5 ore).
Il product owner monitora l'epic sulla roadmap, il team pianifica le story durante lo sprint planning, e gli sviluppatori creano e aggiornano i task durante lo sprint.
Come scomporre il lavoro
- Partite da un risultato presente nella roadmap e scrivetelo come un'epic con una misura di successo.
- Suddividete l'epic in user story usando criteri come fasi del workflow, tipi di utente o prima il percorso standard.
- Raffinate le story principali finché non soddisfano INVEST e possono essere stimate; vedi backlog refinement.
- Durante lo sprint planning gli sviluppatori scompongono in task le story selezionate.
- Monitorate quotidianamente i task sulla task board; chiudete la story quando tutti i criteri sono soddisfatti.
- Chiudete l'epic quando il suo obiettivo è raggiunto, anche se alcune story di minor valore restano non realizzate.
Errori comuni
- Usare i task per rappresentare il valore per l'utente, così il backlog diventa una lista di cose da fare senza risultati chiari.
- Creare epic così grandi da non chiudersi mai.
- Stimare i task in ore e le story in punti, per poi sommarli.
- Assegnare i task alle persone durante lo sprint planning invece di lasciare che sia il team a prelevare il lavoro.
- Aggiungere livelli extra (sub-epic, sub-sub-task) che rendono il backlog più difficile da leggere.
Modelli gratuiti per questo argomento
Domande frequenti
Epic vs story vs task: qual è la differenza tra un'epic e una story?
Un'epic è un obiettivo ampio che richiede diversi sprint; una story è una piccola porzione di quell'obiettivo, incentrata sull'utente, che rientra in uno sprint.
Epic vs story vs task: qual è la differenza tra una story e un task?
Una story fornisce valore a un utente; un task è un passaggio tecnico che aiuta a completare una story e non ha valore per l'utente di per sé.
Epic vs story vs task: i task hanno bisogno di story point?
Di solito no. Gli story point si applicano alle story; i task vengono spesso stimati in ore o non stimati affatto.
Epic vs story vs task: chi crea i task?
Gli sviluppatori che svolgeranno il lavoro, di solito durante lo sprint planning e per tutta la durata dello sprint.
Epic vs story vs task: un sub-task è la stessa cosa di un task?
In strumenti come Jira, un sub-task è un task che appartiene a una story. Il concetto è lo stesso.
Epic vs story vs task: cosa c'è sopra un'epic?
I team usano spesso iniziative o temi per raggruppare le epic sotto un obiettivo strategico.
Epic, story e task fanno parte di Scrum?
No. Scrum definisce solo il Product Backlog e i suoi elementi; questa gerarchia è una pratica comune per organizzarli.
Epic vs story vs task: una story può esistere senza un'epic?
Sì. Le story piccole e autonome non hanno bisogno di un'epic di riferimento.
Epic vs story vs task: quante story dovrebbe avere un'epic?
Non esiste una regola. Molte epic hanno da una manciata a qualche decina di story; se ne ha molte di più, valutate di suddividerla.
Epic vs story vs task: dove si collocano i bug?
La maggior parte dei team tratta un bug come un elemento del backlog a livello di story, talvolta collegato a un'epic, e lo scompone in task se necessario.
Dove si monitorano epic, story e task?
In uno strumento di gestione del backlog; vedi strumenti e tecniche Agile e il confronto tra strumenti.