Anatomia di una User Story card – Fronte

Nel post precedente abbiamo visto cos’è una User Story e quali sono le motivazioni che la rendono uno strumento di analisi, di condivisione delle informazioni chiave e di stimolo al confronto all’interno di un team.

Adesso voglio scendere nel dettaglio della struttura di una User Story card.

Innanzitutto un primo nota bene: una User Story raccoglie in maniera discorsiva ciò che un utente fa o vorrebbe fare nel suo lavoro quotidiano.

Una User Story Card è la rappresentazione cartacea (tipicamente in formato A6) della storia ma non solo. Raccoglie altre informazioni quali la “dimensione” della storia, i task per completarla, i test di accettazione e così via.

Ha un visibilità enorme, la si può spostare, ci si scrive sopra velocemente, sono facilmente riordinabili e confrontabili e soprattutto lo possono fare tutti. Compreso il cliente.

Non esiste LA user story card che va bene per tutti, questa è il punto di partenza che utilizzo io (fronte e retro):

User-story-frontUser-story-back

Innanzitutto una nota sulla dimensione della scheda: non deve essere troppo grande in quanto non è richiesta l’esaustività delle informazioni (per quella si va su un sistema elettronico) ma il riassunto delle informazioni fondamentali.

Partiamo dal fronte.

Titolo della User Story

Il titolo della user story serve per identificare sinteticamente e univocamente la storia.

Per esempio in un sistema di commercio elettronico può essere una frase del tipo:

  • Mario Rossi può inserire il prodotto nel carrello
  • Mario Rossi può rimuovere un prodotto dal carrello
  • Mario Rossi può svuotare completamente il carrello

Tipicamente il titolo è la descrizione sintetica con cui viene caricata nel sistema elettronico di gestione del progetto (Microsoft Team Foundation Server, Jira, OnTime, RedMine, AtTask per citarne alcuni).

Descrizione della User Story

Ricordo che la user story è un frase con questa struttura:

As Who, I want What so that Why

Continuando le storie precedenti potrebbe essere:

SONO “Mario Rossi”

e dalla pagina di dettaglio del prodotto VOGLIO inserire il prodotto nel carrello

PERCHE’ potrò avere in unico punto tutti i prodotti che vorrei acquistare

Ricordo l’aspetto essenziale: la user story deve essere scritta dal punto di vista dell’utente e utilizzando il suo linguaggio. Non c’è nulla di tecnico qui, non ci sono database, C#, o pezzi di interfaccia ma solo quello che un utente vuole fare interagendo con il sistema.

Anzi la situazione ideale è che la storia venga scritta dal cliente.

Un altro aspetto da notare è che non si parla di generico utente o cliente ma si utilizza uno specifico utente che appartiene ad una categoria che scaturisce dalla fase di user role modeling (anche di questo ne parlerò in un altro post).

In questo caso Mario Rossi è stato individuato come l’utente tipico B2C ed è chiaro a tutti quali sono le sue aspettative, le sue competenze tecniche, la sua conoscenza del dominio.

Dimensione e scadenza

La domanda scontata di fronte ad un requisito o, in questo caso, ad una User Story è: quanto ci vuole per implementarla?

Giorni? Ore? Giorni ideali? Giorni uomo? E le ferie? E i 2 membri del team che la prossima settimana devono lavorare su un altro progetto?

Il riassunto di questa e di altre informazioni “temporali” è racchiuso nel concetto di Story Point.

Genericamente si può dire che lo Story Point è una unità di misura delle User Story (al pari delle ore o dei metri) ed una misura sintetica della “dimensione della storia”.

Riesce ad essere indipendente dal tempo, non risente delle ferie o dei giorni di malattia, consente una stima molto veloce e il confronto tra le schede.

Una User Story da 8 SP è sicuramente più grande di una User Story da 5 SP. Facile, immediato e comprensibile da tutti, tecnici, commerciali, cliente.

Diventa anche il miglior metodo per fare un planning, per seguire l’andamento del progetto e per stimare e migliorare la velocità del team.

Ecco perchè DEVE essere in bella vista sul fronte della User Story Card.

Un’ultima informazione che, se presente, deve essere in primo piano è un’eventuale scadenza. Le storie entrano in una sprint in base alla priorità decisa dal Product Owner ma se c’è una scadenza ovviamente questo fa si che la storia venga selezionata per entrare in una sprint in base alla data di consegna.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *