In agile (scrum), come si fa a scomporre una user story?

Generalmente, una storia utente viene creata da un requisito fornito dal cliente o dal potenziale utente del sistema. Spesso ha il formato "Come {ruolo}, voglio {obiettivo} > in modo che {vantaggi}". Il set collettivo di user story cattura i requisiti funzionali del sistema che viene costruito. Il rappresentante del cliente o del cliente dà la priorità a ciascuna storia utente, in genere in base al valore aggiunto con la funzionalità specificata nella storia.

Una volta scritti, le storie degli utenti vengono ridimensionate e stimate. Ci sono un certo numero di tecniche per farlo. Il metodo di stima più comune che ho visto è la quantità di sforzo necessaria per completare l'attività, in valori arbitrari. C'è una unità di base su cui tutti possono essere d'accordo, e usarla come una struttura comune per fornire stime sullo sforzo richiesto. Ho visto questi come valori senza unità chiamati "punti storia", ma non vedo perché non è stato possibile stimare la storia dell'utente in ore. La chiave deve essere coerente in tutte le storie degli utenti.

Per la prima iterazione, il team stima quanti punti della storia possono essere completati in una determinata iterazione e passano a quel numero di punti nel backlog per un'iterazione. Se si stima in ore, è possibile determinare quante ore il team di sviluppo dedicherà al progetto durante l'iterazione e ridurre di molte ore il valore del lavoro. Dopo l'iterazione, determini quanti punti o ore hai effettivamente completato e abbassi quella quantità di lavoro per l'iterazione successiva.

Durante l'intero processo, il tuo arretrato generale di storie sta cambiando. Le funzionalità potrebbero essere rimosse, è possibile aggiungere nuove funzionalità o modificare la priorità. Tuttavia, nulla di ciò influisce sul lavoro che è stato tirato giù per l'iterazione corrente. Solo tra le iterazioni dovresti regolare su cosa stai lavorando. In genere, si dispone di un rappresentante del cliente in loco o di qualcuno che può agire come voce del cliente ed è in contatto con le persone appropriate dell'organizzazione del cliente. Stanno perfezionando continuamente i requisiti e i criteri di accettazione per tutto il progetto.

Il modo in cui dividi ulteriormente le storie degli utenti in attività dipende da te. Potrebbe essere una preferenza non documentata dell'ingegnere, o potrebbe esserci un'analisi dettagliata di esattamente ciò che ogni storia di utenti comporta. È qualcosa che deve essere specificato personalizzando il processo per soddisfare le esigenze della tua organizzazione, squadra e progetto.

Dovresti avere una definizione di fatto , che può essere usato per determinare quando una determinata user story è spedibile. Questo definisce tutto dalla progettazione, implementazione, test, garanzia della qualità, criteri di accettazione e documentazione. È possibile specificare quali strumenti e metodi si utilizzano per garantire che venga eseguita una determinata funzionalità come specificato da una User story. Una volta completata e integrata la user story, il prodotto dovrebbe trovarsi in uno stato potenzialmente spedibile, il che significa che confezionarlo e consegnarlo al cliente aggiungerebbe un valore alle proprie operazioni o soddisferà alcune delle loro esigenze.

In definitiva, è necessario personalizzare i processi per lavorare per la propria organizzazione, team e progetto. Fare qualsiasi cosa "dal libro" è solitamente una ricetta per i problemi. Solo perché qualcosa è stato documentato e funziona bene per alcuni team che lavorano su determinati progetti non significa che si adatta a tutto ciò che ti serve per fare.

Potresti essere interessato a questo articolo InfoQ sulla stima della storia utente e Scott Ambler's Introduzione alle User Story .

È Agile, in quanto conforme al manifesto Agile .

Non è Scrum, in quanto Scrum suggerisce di utilizzare i punti di complessità per stimare tutto.

Ma nessuna di queste cose è così importante. In realtà, sostengo che la stretta aderenza a Scrum, nonostante tutte le prove che non dovresti essere, non è Agile.

Ecco la domanda che dovresti porci: ti è utile?

In che modo migliora il processo di completamento del lavoro? Cosa offre in termini di visibilità? In che modo aiuta i tuoi utenti a ottenere il prodotto che vogliono? Cosa offre alla qualità?

Se non puoi rispondere a queste domande, non preoccuparti di farlo. Se non sei sicuro, prova, misura e aggiusta di conseguenza.

Dove lavoro abbiamo un paio di condizioni diverse che causeranno la suddivisione di una storia in più storie:

1. I punti poker sono troppo alti o la trama sembra troppo vaga per tentare anche di stimare. Se la trama ha più di X punti, allora è troppo grande per essere trattata come una storia da fare in uno sprint. Questo impedisce al team di essere eccessivamente impegnato, perché a volte una grande storia può essere difficile stimare quante ore ci vorranno e quanto velocemente può essere fatto. "Come visitatore del sito, voglio acquistare prodotti in modo da poter avere quei prodotti a casa mia", sarebbe il tipo di storia che è troppo vaga. Amazon.com non è stato realizzato in uno sprint di 2 settimane.

2. Ottenere la trama in uno sprint non sembra probabile e c'è un modo semplice per dividere la storia in più parti. Ad esempio, una prima parte potrebbe essere quella di investigare e progettare una soluzione. Un'altra parte è quella di implementare quella soluzione. Ogni parte può essere eseguita in uno sprint, ma non sembra probabile che entrambe vengano eseguite nello stesso sprint.

A volte può essere nel vedere l'elenco delle attività che segue una storia che mostrerà che rientra in quel secondo caso o che ci sarà così tanto QA richiesto quando verrà ricostruita una parte importante della funzionalità che la storia deve essere suddiviso.