Relazione tra user story, feature ed epic?

In realtà sono termini molto generici. Ci sono molti modi per interpretarli, variando la letteratura e il modo in cui le persone li vedono. Prendi tutto quello che dico con un granello di sale.

Di solito, un Epic comprende una funzionalità molto globale e non molto ben definita nel tuo software. È molto ampio Solitamente viene suddiviso in una piccola user story o feature quando cerchi di dare un senso a questo e di renderlo adatto a un'iterazione agile. Esempio:

Epica
- Permetti al cliente di gestire il proprio account tramite il Web

Caratteristica e User Story sono funzionalità più specifiche, che puoi facilmente testare con i test di accettazione. Spesso è consigliabile che siano abbastanza granulari per adattarsi a una singola iterazione.

Le caratteristiche tendono solitamente a descrivere ciò che fa il tuo software:

Funzione
- Modifica delle informazioni sul cliente tramite il portale web

Le storie degli utenti tendono a esprimere ciò che l'utente desidera fare:

User story
Come impiegato di banca,
Voglio essere in grado di modificare le informazioni sul cliente
in modo che possa tenerlo aggiornato.

Non penso che ci sia davvero una gerarchia tra i due, ma puoi averla se vuoi o se si adatta al tuo modo di lavorare. Una User story può essere una giustificazione specifica per una funzionalità o un modo specifico per farlo. Oppure può essere il contrario. Una funzionalità può essere un modo per realizzare una user story. Oppure possono denotare la stessa cosa. Puoi utilizzare entrambi: storie degli utenti per definire ciò che porta valore aziendale e funzionalità per descrivere il vincolo del software.

User story : come cliente, voglio pagare con le carte di credito più popolari
Feature supporta l'API XML GOV-TAX-02 del governo .

C'è anche la questione dello scenario, che di solito è un modo in cui una storia di personaggi / utenti verrà eseguita. Di solito mappano in modo pulito a un test di accettazione specifico. Ad esempio

Scenario : Prelievo di denaro
Dato che ho 2000 $ nel mio conto bancario
Quando ritiro $ 100 Poi ricevo $ 100 in contanti
E il mio saldo è 1900 $

È così che definiamo quei termini dove lavoro . Quelle definizioni sono lontane da una definizione matematica o un termine standardizzato. È come la differenza tra un politico di destra o un politico di sinistra. Dipende da dove vivi. In Canada, ciò che è considerato di destra può essere considerato di sinistra negli Stati Uniti. È molto variabile.

Seriamente, non mi preoccuperei troppo di questo. L'importante è che tutti i membri del team concordino su una definizione in modo che tu possa capirsi a vicenda. Alcuni metodi come la mischia tendono a definirli in modo più formale, ma scegli ciò che funziona per te e lascia il resto. Dopotutto, non è agile su Individui e interazioni su processi e strumenti e Software di lavoro su documentazione completa ?

Epic : una user story molto grande che alla fine viene suddivisa in storie più piccole.

User story: una definizione ad altissimo livello di un requisito, contenente solo informazioni sufficienti in modo che gli sviluppatori possano produrre una stima ragionevole dello sforzo per implementarlo.

link

Funzionalità : una caratteristica o funzionalità distintiva di un'applicazione o di una libreria software (ad esempio, prestazioni, portabilità o funzionalità).

link

Ti avverto di non applicare una gerarchia troppo rigida a questi termini. Abbiamo provato a farlo nel mio precedente lavoro. Due volte. Entrambi i tentativi erano diversi e entrambe le volte abbiamo scoperto che ci eravamo limitati inutilmente. L'unica costante era la definizione di User Story . Dal punto di vista della pianificazione, una storia è la componente basilare di un progetto. I termini più grandi (epico, funzionalità, ecc.) Sono in effetti solo tag . I tag sono un modo semplice per consentire a una storia di esistere come parte di più Epic e più funzionalità contemporaneamente. Non vale lo sforzo mentale per essere più severo di quello.

I tag funzionano per Stack Exchange e possono funzionare anche per te.

Il modo in cui lavoriamo con Epics, Stories and Features è il seguente

All'inizio del ciclo del progetto, arriviamo con Epics . Questi sono punti di funzionalità di altissimo livello, quasi centrati sul marketing. Il tipo di cosa che puoi usare in un sommario esecutivo, come,

Our new web site will allow customers to browse products, view availability and pricing, place orders and see their past order history

Questo porta a Epics come

• Sfoglia il catalogo prodotti
• Visualizza disponibilità
• Visualizza prezzi
• Inserisci ordine
• Visualizza cronologia ordini

Questi sono scritti come storie utente (es. Come cliente, voglio sfogliare il catalogo prodotti, in modo da poter prendere una decisione informata sull'acquisto), ma servire solo da titolare per dieci per quello che sarà effettivamente sviluppato e rilasciato.

Questi Epics sono ulteriormente suddivisi in User Story . Si tratta di veri e propri percorsi utente end-to-end, di ambito molto limitato e definiti in modo che stimati e pianificati indipendentemente e sviluppati , testato e rilasciato in un ciclo di rilascio.

La User Story è l'unità di consegna. È la storia dell'utente che è completa o non completa, va in diretta o non va in diretta.

An Epic può generare un numero elevato di user story, non tutte saranno sviluppate o rilasciate contemporaneamente.

Ad esempio, l'epica di Sfoglia catalogo prodotti può essere suddivisa in

• Vai alla gerarchia di categorie
• Ricerca per parola chiave
• Filtra per attributi del prodotto (ad esempio intervallo di prezzo, marca, colore, dimensione, ecc.)

Ancora una volta, ognuno di questi sarebbe scritto nel formato, ad es. Come cliente, voglio navigare nella gerarchia delle categorie, in modo da poter navigare tra i prodotti e approfondire il prodotto più adatto alle mie esigenze.

Generalmente, per la maggior parte dei nostri progetti, abbiamo decine di Epics e centinaia di storie.

Ora, mentre analizziamo il ciclo di vita della storia, taggiamo queste storie con Caratteristica s. Ad esempio, tutte le storie di ricerca e di ricerca e di articoli e prezzi saranno contrassegnate con, diciamo, "catalogo prodotti". Le storie degli ordini di pagamento da effettuare con la carta di credito possono essere contrassegnate con un'etichetta "carta di credito" e quelle relative al pagamento con PayPal verranno contrassegnate con un'etichetta "paypal".

Queste etichette servono a raggruppare le storie che appartengono insieme, non perché sono diversi tipi di eseguire la stessa attività (ad esempio tutte le storie degli ordini dei luoghi), ma perché dovrebbero essere rilasciate insieme.

Ad esempio, la storia "effettuare un ordine pagando con carta di credito" appartiene alla stessa epopea della trama "piazzare un ordine pagando con PayPal", ma non è necessario che vengano rilasciati insieme.

Mentre la storia del "fare un ordine pagando con carta di credito", la storia di "elaborare un rimborso su una carta di credito" e "permettere ai clienti di gestire le carte di credito salvate sul proprio conto" sembrano appartenere ad un altro. Sarebbero stati tutti taggati con l'etichetta della "carta di credito". cioè sarebbero tutti appartenenti alla funzione "Carta di credito". Non è molto utile liberare la possibilità di effettuare un ordine pagando con carta di credito, se non è possibile elaborare un rimborso di ritorno su PayPal, o se non è possibile gestire le carte di credito salvate sul proprio account

Nota : come regola generale, vale a dire. Questa è, alla fine, una decisione commerciale. Se il time-to-market è importante, ci può essere una ragione legittima per andare a vivere con uno di questi e non l'altro.

Così Epics serve a suddividere in storie (correlate, ma separate) che possono essere sviluppate indipendentemente, mentre le funzioni servono a raggruppare storie che dovrebbero essere rilasciate insieme.

Potresti dire che Epics si decompone in User Story e User Story vengono composti in Features. Le storie che appartengono a una funzione sono solitamente su Epics. Quindi Epics e Features sono ortogonali, non in una rigida gerarchia.

Nel nostro modo di lavorare, una volta che le Epiche sono state suddivise in storie, perdono il loro scopo. Non stimiamo o pianifichiamo Epics. Non monitoriamo i progressi su Epics. Non pubblichiamo Epics. Stimiamo, pianifichiamo e monitoriamo le User Story. E pubblichiamo le funzionalità.

Sono d'accordo come molte risposte che non ci sono davvero risposte giuste poiché questi sono solo termini che possono essere variati a seconda del campo di Agile su cui si basa e si può sicuramente creare il proprio campo come Finché tutti i membri del team, inclusi gli stakeholder esterni, capiscono cosa intendono. È solo un modo per organizzare i tuoi requisiti.

La risposta che mi piace è dal campo di Mike Cohn ed è abbastanza semplice.

link

• Epic è solo una grande storia (gerarchica)
• Il tema è solo un gruppo di storie (praticamente come tag)

In realtà evita il termine "Feature". Presumo che sia principalmente perché era un termine comune nel tradizionale mondo delle cascate. Molti campi Agile tendono a utilizzare termini diversi per enfatizzare le differenze.

Quindi, nella definizione del tuo PM, la funzione è da qualche parte nel mezzo della gerarchia di Epic-Story.

Ecco le mie informazioni grafiche di questa definizione dal mio articolo InfoQ link ;-)

Funzionalità ed epiche non sono la stessa cosa.

• Una caratteristica non è una User story
• An Epic è una User story
• Una User story può essere un'epica.
• Una User Story può contenere molte funzionalità.
• Una caratteristica può soddisfare da 1 a molte User Story.

Nelle fasi di pianificazione, le discussioni danno luogo a User Story che sono identificati come Epics perché lo sforzo di implementare soluzioni per loro è troppo grande per essere realizzato in pochi giorni. Le caratteristiche del prodotto sono identificate durante questa fase. Ma questo è solo un sottoprodotto della discussione. Funzioni vengono quindi utilizzate per pianificare una roadmap del prodotto, che è una discussione separata.

Le Epiche sono prese e discusse ulteriormente, dando come risultato User Story per ogni Epic. Le Funzioni e Epiche vengono utilizzate per guidare le discussioni nelle sessioni Rifinitura del backlog e Pianificazione dello sprint . A quel punto, le User Story che escono da tali discussioni sono perfezionate , prioritized e, in Sprint Planning , accettato in sprint per l'implementazione.

È solo una questione di decomposizione. Sono solo storie, tranne che con dimensioni diverse.

Personalmente preferisco non etichettare le loro taglie, ma se lo fai va bene pure. Chiedi a PM quale sia la definizione nel tuo spazio di lavoro.

La gerarchia del backlog del prodotto dipende in gran parte dalla dimensione del prodotto e dalla sua modularità (numero di aree del prodotto definite).

Per piccoli progetti: Epic > La storia è più che sufficiente; e tu chiami la "caratteristica".
Grandi progetti potrebbero essere simili a: Novel > Tema > Epico > Funzionalità > Storia

Il miglior esempio potrebbe essere il seguente:
Novel = MS Office
Temi = MS Word / MS Excel ...
Epic = Tabelle / Elenco caratteri ...
Caratteristiche = Tabella colori / Schemi colori tabella / Operazioni con celle ...
Storie (per la funzionalità 'Tabelle di base' all'interno di Epic 'Tabelle') = Aggiungi tabella / Disegna tabella / Inserisci grezzo / Inserisci colonna ...

Ciò che ritengo sia utile da tenere presente quando si definisce il proprio ridimensionamento per il backlog è:
1. Storia: a) sempre fattibile in uno sprint; b) non sempre testabile per gli utenti finali
2. Epic / Feature: a) non si adatta a una durata di sprint e deve essere scomposto; b) dovrebbe sempre essere testabile per gli utenti finali; c) sempre spedibile, può essere monetizzato: ottieni il ROI calcolato per esso
3. Quando consideri aggiungere o meno Epic > sezione Caratteristica o rimani fedele a Epic > Storia: mi raccomando di inserire Feature tra Epic e Story solo quando: Epic non si adatta nemmeno a 1 Release, quindi è necessario definire un elemento shippable che si adatti alla durata di 1 Release .

Spero che questo sia utile.

Nella nostra organizzazione abbiamo il seguente:

Tema = Usato per raggruppare una raccolta di storie

Epic = Descrive una grande user story (in verità un requisito) che deve essere scomposto in user story

Caratteristiche = Fa quello che dice sul barattolo, descrive una funzione del prodotto richiesto

User story = Questo è il livello di dettaglio più basso da cui derivano le attività.

La nostra organizzazione ha oltre 2.000 sviluppatori, quindi la risposta a questa domanda è importante per una comunicazione fluente e chiara tra le centinaia di team Agile che collaboriamo sul nostro prodotto comune. Per un'organizzazione molto piccola, è possibile avere una struttura molto semplice che non ha nemmeno bisogno di essere gerarchica (come altri hanno risposto). Tuttavia, per le grandi organizzazioni, c'è sicuramente bisogno di una gerarchia organizzata, ridimensionata e coerente - e qui sta il problema nel cercare di fare una gerarchia su qualcosa che non sia strettamente gerarchico.

Per inciso, ci riferiamo a ciascuno di questi livelli disparati come "oggetti di lavoro". Alcune organizzazioni (inclusi alcuni degli intervistati sopra) si riferiscono a livelli disparati come Storie o User Story (e lo abbiamo anche nel passato), ma abbiamo trovato questo troppo ambiguo, quindi ora ci riferiamo genericamente come Elementi di lavoro.

Il meglio che abbiamo "ufficialmente" fatto finora è quello di seguire la struttura SAFe di Dean Leffingwell di Investment Themes e Business Epics in cima (e secondo dall'alto) della gerarchia, poi Funzionalità sotto, e infine Storie sotto Caratteristiche. Secondo Agile, le attività sono sempre sotto Storie, quindi stiamo attenti a non riutilizzare quel termine più in alto. Abbiamo scelto di seguire SAFe per avere almeno una certa coerenza in tutti i nostri team.

Ma questo è ancora insufficiente per i nostri bisogni. Definiamo una caratteristica come un prodotto chiaramente di valore per un consumatore del nostro prodotto software (ad esempio, elenchiamo queste caratteristiche nei nostri annunci delle prossime versioni). E definiamo una storia come una quantità minore di scopo e lavoro che può essere fornita in un singolo Sprint da un singolo team di sviluppo di Agile. Stiamo anche iniziando a seguire la definizione SAFe di Investment Tema e Business Epic a livello di Portfolio (e non al di sotto di questo livello). E stiamo iniziando a NON usare le nostre vecchie definizioni di "Tema" ed "Epica".

Ora stiamo lentamente evolvendo in questa direzione, ma le ruote del progresso si muovono lentamente. Stiamo ancora lottando su come suddividere il lavoro in blocchi di dimensioni ridotte in modo da poter definire il lavoro e farlo funzionare in modo uniforme da più team. Per fare questo, vediamo la necessità di una "Sub-Feature" che sia più piccola di una Feature ma più grande di una Story. Le caratteristiche secondarie possono essere utilizzate per blocchi di lavoro eseguiti su una caratteristica da parte di OGNI squadra INDIVIDUALE, o blocchi di lavoro eseguiti da un team SINGOLO in momenti diversi (in diversi Sprint o anche in versioni diverse).

Abbiamo anche bisogno di più livelli gerarchici tra Feature e Business Epic, ma non abbiamo ancora risolto questo problema, se non quello di chiamarli semplicemente "Temi" - che sappiamo non è il termine corretto, poiché è facilmente confuso con SAFe Temi di investimento. Per alcuni grandi progetti (versioni) abbiamo 5-8 diversi livelli gerarchici, ognuno dei quali suddivide il lavoro in pezzi più piccoli e più piccoli. Puoi pensare a questi temi come a "Gruppi di funzioni", ma non è necessariamente anche il termine corretto.

Penso che sia importante cercare di usare termini che offrono chiarezza piuttosto che ambiguità. Quindi chiunque si riferisca a una storia significa la più piccola unità di lavoro che può essere fatta in un singolo Sprint (eccetto per i compiti sotto la storia), e sotto-caratteristica significa la più piccola unità di lavoro su una caratteristica che può essere fatta da un singolo squadra. Allo stesso modo, un gruppo di caratteristiche è un livello gerarchico sopra Feature. Oltre a ciò, diventa un po 'confuso, quindi di solito li chiamiamo Temi e permettiamo Temi come genitori e figli di altri temi. Cerchiamo di limitare i livelli di Feature, Sub-Feature e Story a un singolo livello ciascuno (le funzionalità non dovrebbero essere figli di altre funzionalità) ma non abbiamo ancora il 100% di successo nel limitarlo.

So che potremmo usare "Tag" per organizzarne una parte, ma i tag non ci forniscono la struttura organizzativa per la ripartizione del lavoro di cui abbiamo bisogno per classificare il lavoro tra tutti i nostri team. Per definizione, i tag sono ambigui (relazioni molti-a-molti), ma una gerarchia è strettamente uno-a-molti.

La linea di fondo è che questo è ancora un work in progress per noi, e stiamo ancora lottando con esso. Ma aderendo alle definizioni SAFe di Theme, Epic, Feature e Story ci muoviamo nella giusta direzione!