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". Scrum non prescrive l'uso delle user story, che restano una pratica complementare per descrivere ad alto livello componenti e feature del 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.

Un formato diffuso, ma non obbligatorio, per 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. Per valutarle può essere utile l'euristica INVEST, coniata da Bill Wake in questo articolo. Non è un insieme di regole richieste da Scrum. 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 può essere utile 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)

Se scegli di utilizzare gli acceptance criteria (criteri di accettazione), scrivili in un luogo facilmente accessibile per il team, magari all'interno di una pagina wiki o nel già citato bug tracker. Anche questa è una pratica complementare, non un elemento obbligatorio di Scrum. 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.

Il Product Owner rimane accountable per la gestione efficace del Product Backlog, ma può delegare ad altri la scrittura delle user story e non è necessariamente l'unico autore o controllore della loro qualità. 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.