Tabella modello per il Product Backlog
Vorrei mostrarti un modo molto semplice per rappresentare le User Stories in un Product Backlog tabulare. L'idea mi è venuta dopo aver ritrovato un mio vecchio Product Backlog di nove anni fa e aver pensato: "Wow, rispetto a quello che faccio oggi, è piuttosto obsoleto." Quindi ti mostro qui un modello per un Product Backlog sotto forma di tabella (ad es. Excel).
Come forse già sai, sono un grande fan di scrivere il Backlog con l'aiuto delle User Stories e di strutturare queste User Stories nel modo seguente:
"Come ______ voglio ______, affinché ________"
Potrebbe essere così: "Come frequent flyer voglio poter accedere a Internet durante il volo, in modo da poter aggiornare il mio blog anche durante il viaggio, invece di salvare solo un documento di testo con cui aggiornare il blog più tardi." (Riesci a indovinare dove ho scritto questo?)
Quando si lavora con una tabella Excel, trovo più semplice utilizzare gli elementi della User Story come intestazioni di colonna. In questo modo si ottengono le intestazioni "Come", "voglio" e "affinché". Il messaggio chiave di ogni Story è quindi ben riconoscibile. Si possono aggiungere anche altre colonne, ad es. per numerazione, note, stato ecc. Nell'esempio seguente ho aggiunto anche una colonna per il tema generale della rispettiva Story.
| ID | Tema | Come... | voglio... | affinché... | Note | Priorità | Stato |
| 2 | Gioco | Moderatore | creare un nuovo gioco inserendo un nome e una descrizione opzionale | possa invitare altre persone a valutare | Se non si possono salvare i giochi e tornare in seguito, la descrizione non è necessaria | obbligatorio | done |
| 2 | Gioco | Moderatore | invitare altre persone a valutare fornendo loro un URL con cui possono partecipare al gioco | possiamo iniziare il gioco | L'URL dovrebbe essere formattato in modo da poterlo comunicare facilmente per telefono | done | |
| 5 | Gioco | Estimator (persona che deve fornire una valutazione) | partecipare a un gioco inserendo il mio nome sulla pagina per cui ho ricevuto l'URL | possa partecipare al gioco | done | ||
| 6 | Gioco | Moderatore | avviare un round inserendo un item in un campo di testo multilinea | possiamo valutarlo | done | ||
| 8 | Gioco | Estimator | vedere l'item che deve essere valutato | sappia per cosa sto fornendo una valutazione | done | ||
| 40 | Gioco | Partecipante | avere le carte sempre nello stesso ordine quando le pesco più volte | sia più facile confrontare le valutazioni | Sostituito da A08, affinché la Story non parli di "stesso ordine", perché questo può essere un dettaglio dell'interfaccia | done | |
| 35 | non funzionale | Utente | che l'applicazione reagisca rapidamente alle mie azioni | non mi annoi | done | ||
| 36 | non funzionale | Utente | buone pagine di errore quando qualcosa va storto | possa fidarmi del sistema e dei suoi sviluppatori | done | ||
| A11 | non funzionale | Ricercatore | che i risultati vengano salvati in modo non identificabile | possa studiare dati come ad es. se le stime somigliano alla prima opinione data da "Estimator A" | Non devono essere salvati né nomi né testo, ma ogni carta, chi l'ha giocata e la stima finale | ||
| A05 | Gioco | Moderatore | modificare uno degli item da valutare | rifletta meglio la comprensione dell'item da parte del team | |||
| 22 | Archivio | Moderatore | esportare i dati di un gioco come file CSV | possa continuare a lavorare sulle Story e sulle stime | Il file esportato dovrebbe poter essere reimportato direttamente nel sistema | done |
