User story e acceptance criteria

È una pratica comune, in Scrum e in altre metodologie agili come XP, descrivere i requisiti sotto forma di user story - in italiano: "storie utente". Le user story sono una definizione ad alto livello di qualsiasi componente e feature che costituiscono il prodotto.

Esempi di user story

Il punto di vista è quello di chi richiede o desidera la nuova funzionalità, e scrivere una user story è un po' come immaginare un discorso con un quell'utente. La quantità di informazioni contenuta in ciascuna user story è lo stretto necessario per consentire al team di sviluppo di effettuare una stima a grandi linee dell'effort richiesto per la realizzazione.

Il formato di una "storia utente" è il seguente:

As a ______ I want to  ______ so that ______

In italiano: Come <ruolo> voglio <requisito> così che <beneficio>

Ecco alcuni esempi:

• As a user I want to login so that I can access the members section
• As a user I want to share my pictures so that my friends can stay up to date
• As a blog admin I want to moderate the comments so that I don't publish spam
• As a customer I want to access transaction history so that I can see my credit card payments

Chi non è familiare con l'inglese può usare i corrispettivi in italiano:

• Come utente, voglio effettuare il login così da accedere all'area utenti
• Come utente, voglio condividere le mie foto così che i miei amici possono rimanere aggiornati
• Come amministratore del blog, voglio moderare i commenti così da non pubblicare spam
• Come cliente, voglio accedere allo storico transazioni così da vedere i miei pagamenti con carta di credito

Come scrivere user story di qualità

Scrivere le user story è piuttosto semplice, ma se si vuole fare un lavoro ben fatto bisogna ricordarsi di alcune regole racchiuse nell'acronimo INVEST, coniato da Bill Wake in questo articolo. Ti riporto qui sotto una tabellina che puoi memorizzare:

IIndependentNon deve avere interdipendenze con altre user story.NNegotiableUna buona user story cattura l'essenza e non i dettagli, e deve essere negoziabile fino a quando non è parte di un'iterazione.VValuableDeve essere in grado di portare valore aggiunto all'utente finale.EEstimableDeve essere possibile da stimare; è difficile stimare una user story che non si comprende.SSmallNon deve essere talmente grande da non poter essere pianificata o realizzata; più una user story è piccola più è facile da stimare.TTestableDeve essere testabile e avere informazioni su come eseguire i test.

Insieme alla user story bisognerebbe sempre scrivere una breve descrizione dell'attività da svolgere. Se il tuo backlog è ricavato su una parete del tuo ufficio e le user story sono note adesive, il mio suggerimento è di scrivere la user story nella parte frontale e una breve spiegazione nella parte posteriore del post-it.

Puoi anche utilizzare uno strumento di monitoraggio (bug tracker) tra quelli disponibili gratuitamente su Internet. Oltre alla breve descrizione dell'attività da svolgere, puoi anche allegare all'interno del bug tracker la documentazione e il materiale tecnico che serve al team di sviluppo in fase di implementazione.

Acceptance criteria (Criteri di accettazione)

Insieme alle user story, per soddisfare il requisito di testabilità, non dimenticarti di scrivere anche gli acceptance criteria (criteri di accettazione) in un luogo facilmente accessibile per il team, magari all'interno di una pagina wiki o nel già citato bug tracker. Ci sono diversi modi di scrivere gli acceptance criteria. Il più semplice, e quello con cui ti consiglio di cominciare se sei alle prime armi, è il seguente:

Verify that ________________

Tradotto: Verifica che <condizione>

Per esempio:

• Verify that the user is logged in (Verifica che l'utente sia loggato)
• Verify that the user area is accessible (Verifica che l'area utenti sia accessibile)
• Verify that the logout button is present (Verifica che il pulsante logout sia presente)

Puoi scrivere tutti gli acceptance criteria che ritieni applicabili alla user story, uno per riga. Non preoccuparti se in fase di stesura ne dimentichi qualcuno, aggiungine man mano che ti vengono in mente.

Questa tecnica è molto utile in quanto consente agli sviluppatori di testare le funzionalità in fase di programmazione, e allo stesso tempo definisce una checklist utilizzabile per i successivi acceptance test.

User story vs Epic

Una user story che è troppo grande per far parte di una singola iterazione rientra nella definizione di epic - dette anche "epiche", nella traduzione in italiano. Avere epic nel proprio Product Backlog non è di per sé un aspetto negativo: è una pratica abbastanza comune, quando si produce una Roadmap, scrivere epic anziché individuare ogni singola attività*.* Successivamente il Product Owner divide le epic in user story più piccole o se preferisce può lasciare il compito al team di sviluppo.

Chi scrive le user story

Le user story possono essere scritte da chiunque abbia le competenze necessarie a scriverle. In molti casi è il Product Owner, in altri casi, se presente, è il business analyst. A volte è l'intero team a scrivere insieme le user story in maniera collaborativa, magari in una sessione di backlog refinement.

In ogni caso il Product Owner rimane l'unico responsabile del Product Backlog e della qualità delle user story. Per questo motivo una buona comunicazione tra chi scrive le user story e il Product Owner è fondamentale.

Inglese o italiano?

Un ultimo suggerimento. So che potrebbe sembrarti strano utilizzare l'inglese, soprattutto se lavori in Italia, ma per favore usalo almeno in parte. Anche se non sei bravo in inglese, basta veramente poco, credimi. Oltre alla possibilità di condividere le informazioni e i requisiti con un team distribuito geograficamente in qualsiasi parte del mondo, l'inglese è una lingua estremamente sintetica che ti consente di essere conciso e diretto al punto.

Detto questo, la scelta è tua. Indipendentemente dalla lingua con cui deciderai di lavorare, l'utilizzo delle user story e degli acceptance criteria ha i suoi benefici in termini di leggibilità e praticità.

Immagine di copertina rilasciata via Creative Commons da Andrew Mason su Flickr.