Tag: product backlog

Il backlog racconta il nostro prodotto da diverse prospettive.
Sappiamo che finché esiste il prodotto esiste un backlog e che questo è principalmente costituito da user stories, ma non tutto ciò che è contenuto nel backlog deve necessariamente essere una storia.
Lo scopo di questo artefatto è condividere cos’è il prodotto che stiamo realizzando con chi lo deve implementare, validare, utilizzare e – in generale – con tutti coloro che ne sono interessati.
In quest’ottica le user stories potrebbero non essere esaustive.

Come descrivo un’interazione complessa? E l’esperienza utente? Dove condivido i dettagli delle interfacce? Come posso dettagliare gli aspetti di performance e scalabilità del software?
Le user stories a volte non bastano. In generale tutto ciò che può aiutare ad aumentare la comprensione del prodotto e a descriverne l’utilizzo da parte dell’utente finale è un elemento utile.

Nella mia esperienza un buon backlog finisce per contenere tutti questi elementi:
– user stories
– interazioni
– visual design
– requisiti non funzionali

Non mi soffermo sulle user stories, di cui abbiamo già parlato a lungo, e che hanno lo scopo di descrivere le funzionalità del prodotto.

Interazioni

A volte le funzionalità che vogliamo realizzare comportano un’interazione complessa.
Sono i casi in cui l’utente deve ad esempio compiere più step per portare a termine un’operazione o casi in cui una singola azione provoca più effetti in diversi punti del sistema.
Pensiamo alle esperienze di acquisto, alle registrazioni mediante social, alla gestione delle proprie mail nella casella di posta.
In questo caso oltre alle user stories sulle singole funzionalità è necessario dettagliare il percorso che dovrà seguire l’utente.
A questo scopo ci vengono in aiuto i diagrammi di flusso, gli scenari e le storyboard.
Mediante questi strumenti possiamo descrivere visivamente i singoli passaggi attraverso cui transita l’utente, verificare di non avere omesso degli step fondamentali e calarci nel suo percorso per verificarne la logica ancora prima di aver dettagliato l’interfaccia.
Con l’interaction design rispondiamo alle domande: come si muoverà l’utente? che cosa potrà fare nel nostro servizio?

Visual Design

Il design è un componente essenziale del successo di un prodotto ed un aspetto sempre più rilevante nei criteri di scelta da parte dell’utente finale.
Nel mondo digitale ci sono aziende di successo che hanno fatto di questa caratteristica il proprio elemento distintivo (pensate a Apple!).
Per comunicare questo tipo di caratteristiche possiamo utilizzare svariati tool: mock-up, sketch e wireframes che emulano la navigazione e le principali interazioni dell’utente finale.
Il ventaglio delle possibilità è ampio, si va dal semplicissimo disegno dell’interfaccia a matita su un foglio di carta al .psd dell’art director definito al pixel (anche se questo livello di dettaglio è eccessivo e controproducente).
Con il visual design rispondiamo alla domanda: cosa vedrà l’utente in ogni singolo step?

Requisiti non funzionali

Definiscono le proprietà e i vincoli di un sistema.
Sono gli aspetti che riguardano – ad esempio – l’usabilità, la scalabilità, le performance di un prodotto, i tempi di risposta.
Sono spesso elementi essenziali per la soddisfazione degli utenti, a volte poco tangibili ma trasversali all’intero servizio e critici per il suo corretto funzionamento.
Sono di solito problemi non indirizzati a livello di MVP (minimum viabile product)  ed anche i primi aspetti che “saltano” quando il time to market è fondamentale nella strategia di prodotto.
Pur essendo così bistrattati sono tuttavia quelle caratteristiche che rendono solido e flessibile un prodotto nel tempo.
Ecco perché prima o poi vi ritroverete a fare i conti con i requisiti non funzionali.
Possono richiedere tempi di implementazione più lunghi rispetto alle funzionalità del servizio ed è opportuno definirli il prima possibile nel corso dello sviluppo in modo tale compiere scelte tecniche e di prodotto in linea con i vincoli che caratterizzeranno il sistema.
Solitamente i requisiti non funzionali non vengono espressi mediante la formula classica delle storie (attore, funzionalità, beneficio), bensì mediante enunciati.
Qualche esempio:
– l’acquisto dei prodotti mediante carrello deve essere disponibile anche  su browser Opera
– il caricamento della pagina di risultati di ricerca deve essere inferiore a 1,5 secondi
– l’area personale deve essere consultabile in mobilità da device Android vers. 4 e superiori
Con i requisiti non funzionali rispondiamo alla domanda: di quali vincoli deve tenere conto lo sviluppo del nostro prodotto?

In sintesi il mio consiglio è questo: non forzate all’interno di user stories qualsiasi tipo di dettaglio di prodotto.
Se avete difficoltà a descrivere una caratteristica mediante la formula who/what/why provate a chiedervi se non avete forse a che fare con requisiti non funzionali, interazioni o aspetti di visual design.
Tutti questi sono elementi determinanti della user experience finale e hanno la dignità di trovare posto nel product backlog.
Più in generale non esitate ad avvalervi di qualsiasi strumento possa generare maggiore chiarezza.
Sperimentate e divertitevi a farlo!