Backlog declutter 1: da dove partire per riordinare

Come i Product Owner possono mettere ordine nei requisiti mediante l’utilizzo del metodo KonMari 

Backlog e declutter, un binomio curioso.
Questo post è la trascrizione di un mio intervento allo IAD 2016. Datato sì, ma sempre attuale; soprattutto di questi tempi in cui abbiamo tanto tempo per fare ordine …
Il topic è nato combinando 2 interessi diversi: uno per la product ownership e l’altro per la lettura. 
Sono una lettrice compulsiva e qualche anno fa mi sono imbattuta in un libro curioso – “Il magico potere del riordino” di Marie Kondo – mentre ero alla ricerca di strumenti che semplificassero la mia vita e mi facessero sentire più leggera. 
Ma cosa diavolo c’entra un volume che ti insegna a fare ordine in casa con la gestione del product backlog? C’entra c’entra, più di quel che pensate…

Struttura del backlog

Partiamo dal backlog: è quell’artefatto che raccoglie tutti i requisiti di prodotto ordinati secondo priorità.
Diamo ora un’occhiata alla sua struttura.

Come vedete nell’immagine la granularità delle user stories è più elevata in alto (sono quelle prossime alla lavorazione) e minore mano a mano che si procede verso il basso e quindi si va più avanti nel tempo.
Altra caratteristica di questa rappresentazione è che si tratta di un elenco contenuto.
Non è tutto il possibile e l’immaginabile che riguarda il prodotto, è una selezione di ciò che produce valore per gli utilizzatori (non si tratta di una lista della spesa!). 

Com’è fatto il backlog ideale

Le caratteristiche di un backlog “da manuale” sono queste: 

  • essere dettagliato correttamente (rispettare la granularità decrescente che abbiamo visto prima)
  • avere user stories stimate al proprio interno
  • essere aperto ad accogliere nuove idee e stimoli (mantenere la caratteristica di artefatto vivente)
  • rispettare le priorità

Ma nella pratica quanti di voi hanno un backlog così ordinato?
Il vostro backlog ha davvero queste caratteristiche?
E’ possibile farsi un’idea del suo contenuto in 3 minuti?

La domanda non è peregrina… tempo fa è arrivato in azienda un nuovo manager nella funzione IT. E’ andato a conoscere i vari team e ha fatto ai PO una domanda molto semplice: “se do un’occhiata al vostro backlog sono in grado di farmi un’idea al volo dei progetti su cui state lavorando e lavorerete nel prossimo futuro?” 
La domanda di per sé è semplice, ma la risposta? 
Tutti i nostri backlog sono accessibili e possono essere consultati da chiunque in azienda, ma sono davvero comprensibili? Chi li vede per la prima volta può farsi un’idea al volo? 

Il mio backlog è esploso… e adesso?

Spesso non è così e sono tanti i motivi per cui un backlog può sfuggire al controllo.
Ma non preoccupatevi; la buona notizia è che possiamo intervenire in qualsiasi momento e riprendere le redini della situazione.
A venirmi in soccorso è stato proprio il caso letterario di questa autrice giapponese che si definisce una consulente domestica e ha venduto milioni di copie in tutto il mondo.
Ho provato ad applicare alcuni consigli e tecniche mutuati dalla gestione degli spazi fisici al mio backlog e ne ho tratto grandi benefici.

Il clutter nel backlog

Il clutter è disordine, confusione, tutto ciò che non serve ma si trova nel nostro ambiente.
C’è anche chi lo definisce come “decisioni rimandate”.
Fare declutter significa portare ordine, liberarsi di oggetti vecchi ed ingombranti e portare alla luce ciò che è realmente di valore per noi.
Penso che a questo punto vi sia chiaro il perché leggendo il libro mi si sia accesa una lampadina…
Non è esattamente il lavoro di un PO questo? Comprendere e selezionare cosa valorizza veramente un prodotto.

Fare un assessment del backlog

Come in ogni operazione di riordino che si rispetti si parte da una valutazione dello stato attuale. Dobbiamo prendere consapevolezza.
Il primo invito che vi faccio è condurre un’analisi del vostro backlog.
Proviamo ad analizzarlo rispetto a passato, presente e futuro.

Cosa è entrato in passato nel backlog e cosa ha senso che rimanga in questo preciso momento? 
Quanto è opportuno che guardi in là il mio backlog? 

Cominciate a fare una valutazione oggettiva del vostro backlog: quanti item contiene al suo interno? 30? 50? 100?
Ovviamente il numero può dipendere da tanti fattori – il prodotto che seguite, la dimensione dell’azienda, l’organizzazione della stessa – ma tenete presente che oltre una certa soglia si verificano in ogni caso dei problemi.
Un esempio? Un backlog con un centinaio di item e un team che ne lavora 5/6 ad ogni iterazione si traduce in un’attività che cuba quasi un anno.
Siamo così certi che nulla cambi nel frattempo?

Backlog di grandi dimensioni: inconvenienti

Uno dei primi effetti collaterali è che il backlog perde la caratteristica di essere emergente. 
Quando la dimensione va oltre una certa soglia si verificano comunque delle disfunzioni: è difficile avere una visione globale e unitaria di tutto ciò che è presente al suo interno.
Si crea un effetto buco nero, ovvero più caos c’è e più tende a entrarne perché si è superata la soglia di contenimento.
L’altro grosso problema è che essendo già pieno difficilmente lascia spazio all’innovazione.

Abbiamo valutato lo stato di salute del nostro backlog, vediamo ora come le pratiche di declutter possono aiutarci a risolvere il problema.
Incredibile come i consigli per il riordino degli armadi offrano supporto ai PO “congestionati”.

Pianificare il riordino 

Uno dei primi suggerimenti è che dovete pianificare questo tipo di attività.
Non pensate di fare il riordino del backlog piano piano e poco per volta perché questo approccio non porta dei risultati tangibili (parlo ahimè per esperienza). 

E’ un’operazione time-boxed a tutti gli effetti quindi dovete darvi una scadenza né troppo stringente né troppo lasca.
Dovete pianificare dei momenti di questo tipo per poterlo fare effettivamente, metteteli in agenda, se potete coinvolgete anche il team.
Evitate un’attività a spizzichi e bocconi perché questo non porta a un reale cambiamento. Facendo ordine in modo radicale cambiate la vostra forma mentis e la struttura del vostro backlog.

Visualizzare il caos

Un altro consiglio è che tutto deve essere visibile.
Questo è un principio che dovremmo già conoscere perché è affine alle metodologie agili. 

Quando questa operazione viene fatta in casa si parte dai vestiti.
Tutti vengono tirati fuori dagli armadi e posti su letto in modo da poter vedere la montagna che si crea. Stessa cosa per le librerie; tutti i libri sul pavimento. 

Ci dobbiamo confrontare con il caos, dobbiamo “sporcarci le mani”. 
Fate in modo che gli item del backlog siano stampati su un supporto fisico.
Dovete poter giocare con le carte, valutare effettivamente quante sono e vederle dispiegate davanti a voi perché in un secondo momento dovranno essere organizzate. 

Quando mi sono trovata di fronte a 300 card e oltre ho capito di avere un problema…

Eliminare prima di riordinare

Da dove si parte? Prima viene il buttare!
Il riordino è un’operazione solo successiva. 

Questo è il momento in cui interveniamo sulla dimensione del backlog e il numero di item al suo interno per riportarli sotto controllo.
Qui vi stupirete di quanto si possono snellire i backlog.

Da cosa partiamo? Esistono indubbiamente in tutti i nostri backlog una serie di elementi che possono essere tranquillamente cestinati senza timore.
Vi porto qualche esempio… vi può capitare di trovare di tutto: item che nel frattempo sono chiusi perché sono stati lavorati insieme ad altri, attività che sono rimaste nel backlog ma che in realtà sono state portate a termine, duplicati, user stories che rimangono lì per mesi e mesi… si tratta evidentemente di item che hanno un valore inferiore rispetto tutto quello che viene lavorato quindi questo ci dà un’indicazione importante.
Il tempo di permanenza nel backlog è un criterio che dobbiamo sempre tenere presente.
E’ come un vestito che non viene più messo da anni, oltre una certa soglia si può buttare buttare senza pensieri.

Ma quali criteri adottare per fare questa radicale operazione di eliminazione?
Lo vediamo nella seconda parte di questo post!

Come gestire user stories tecniche

Tre approcci ai requisiti tecnici

Capita a tutti di dover inserire tra le attività del team task di tipo prettamente tecnico.
In questo articolo vi porto l’esempio di 3 modi differenti di gestire questo tipo di richieste.
Innanzi tutto ha senso parlare di user stories tecniche?
Mhhh, dipende…
Se siamo in grado di individuare nella richiesta un soggetto, un oggetto e un beneficio esplicito è utile definirla attraverso il format della user story.
Se non è così e ci si spacca la testa per far rientrare una richiesta in un modello che non le appartiene in alcun modo meglio evitare del tutto. Non l’ha prescritto il medico che tutto ciò che entra nel backlog sia esclusivamente una user story!
Ci può essere molto altro, ad esempio task di bug fixing, attività architetturali, prototipi, spike e via così.

Ha senso tracciare queste attività tecniche?
Assolutamente sì! Il team spende del tempo su questi task così come sull’implementazione di nuove funzionalità ed è importante tenerne traccia per monitorarle e pianificare il modo migliore di gestirle nel tempo.

Come affrontare user stories tecniche

Sprint funzionali e sprint tecnici

Quando nel corso del tempo non c’è stata un’attenzione continuativa alla qualità e al refactoring possono presentarsi casi in cui il codice legacy ha raggiunto livelli decisamente problematici.
In alcuni di questi casi mi è capitato di vedere i team di sviluppo alternare sprint in cui venivano implementate nuove funzionalità e sprint tecnici dedicati soprattutto al refactoring e alla “messa in sicurezza”.
Ad esempio a 3 sprint funzionali seguiva uno sprint tecnico.
Dico subito che non sono una fan di questa soluzione perché per la mia esperienza produce più svantaggi che vantaggi.

Svantaggi
E’ di difficile “digestione” da parte del business che fatica a comprendere uno stop forzato ogni mese e mezzo; è spesso difficile individuare un chiaro obiettivo dello sprint tecnico; il product owner ha difficoltà a misurare il valore di questo tipo di interventi (che peraltro poco si prestano a demo); richiede una maturità di gestione se possibile ancora più elevata da parte del team.
Infine spesso e volentieri questo sforzo non porta comunque un miglioramento effettivo in tempi brevi del codice legacy.

Vantaggi
Il team è fortemente focalizzato sulla risoluzione degli aspetti tecnici, li gestisce in totale autonomia e non subisce interruzioni.

User stories funzionali e tecniche nel medesimo sprint

Questa modalità di gestione è piuttosto frequente.
Il tempo disponibile dello sprint è suddiviso tra sviluppi funzionali e attività di tipo tecnico. Diciamo che il team concorda con il product owner di dedicare ad esempio l’80% del tempo ai primi ed il restante 20% ai secondi.
E’ il classico esempio di “un colpo al cerchio e uno alla botte”…

Svantaggi
Il team fa contest switching all’interno dello sprint (si tratta spesso di attività a sé stanti rispetto al resto); è difficile individuare un unico sprint goal.
Richiede comunque tempi lunghi per vedere effettivi benefici a livello di legacy.

Vantaggi
E’ un compromesso più che accettabile per il business perché non richiede periodicamente uno stop delle attività; questa modalità di gestione può essere adottata in ogni sprint; al termine di ogni iterazione consente di avere workable software da mostrare durante le demo.

Aspetti funzionali e tecnici nella medesima user story

Questa è un’altra possibilità e devo dire che tra tutte è quella dalla quale sento di aver tratto maggior beneficio.
In sostanza in ogni storia il team stima una quota parte di refactoring del codice e/o dei test. Questo si traduce in prima battuta in user stories che vengono valutate con un peso maggiore (e quindi in una diminuzione iniziale della velocity del team), ma in un tempo relativamente breve la situazione torna alla normalità e – addirittura – a migliorare.
E’ importante notare che richiede grande maturità tecnica ai membri del team e la capacità di fare solo ciò che è opportuno e nulla di più (no virtuosismi se non sono necessari).

Svantaggi
Il refactoring viene effettuato sulle sole storie funzionali lavorate nel corso dello sprint; iniziale diminuzione della velocity.

Vantaggi
Non ha effetti collaterali sugli stakeholder; questa modalità di gestione può essere adottata continuativamente; aumenta da subito la qualità del software e l’attenzione del team a questo aspetto; nel tempo porta grande confidenza ai dev sulle parti che hanno toccato e maggiore velocità di sviluppo.

E voi quale tipo di approccio adottate?
Quale ritenete più utile per il vostro caso? Avete esplorato altre possibilità?
Ci sono casi in cui per risolvere problemi di legacy avete dovuto adottare approcci più radicali?
Sono curiosa di sentire le vostre esperienze…

Non solo user stories nel 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!