Tag: product backlog

Pubblicato il

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!

Pubblicato il

Ho ereditato un product backlog… e adesso?

backlog

Sarà capitato anche a voi.
Non sempre si ha la possibilità di partire con un progetto da 0, avendo davanti una tabula rasa.
Spesso nella nostra professione si subentra al lavoro di qualcun altro ereditando gioie e dolori di progetti già esistenti.
Se avete sperimentato questa situazione sapete di cosa parlo.
Mi è capitato già due volte di ereditare un backlog creato da altri e siccome sono certa di avere fatto errori entrambe le volte e che avrei potuto fare di meglio, penso sia giunto il momento di tirare le somme. Magari il post consentirà a voi di risparmiare tempo prezioso.

Diciamolo francamente: ereditare un product backlog realizzato da altri con user stories annesse e connesse è un po’ come per i programmatori dover mettere le mani sul codice altrui.
Difficilmente sarete entusiasti di ciò che troverete.
Non perché il vostro predecessore abbia fatto necessariamente un cattivo lavoro, semplicemente il vostro modo di formulare le user stories, di suddividere i temi o di organizzare il tutto secondo epiche è semplicemente “vostro”, ovvero personale.
E’ un po’ come riempire una lavastoviglie: ognuno lo fa a modo proprio!

Che fare in questi casi? Come procedere?
Vi condivido alcune idee, che – col senno di poi – si sono rivelate utili.

Delimitare i progetti

Partiamo da un livello “macro”. Prima di tutto è opportuno suddividere le storie in base ai progetti a cui appartengono.
Magari sarete fortunati e avrete un unico grande progetto su cui lavorare, il più delle volte tuttavia erediterete di tutto un po’.
Partite dalle basi e verificate che ogni progetto abbia un ambito chiaro e ben definito, in caso contrario dovete poter arrivare a delinearne i confini. Quindi cercate di associare ogni item a un progetto di riferimento.
Se qualcosa non torna è un indizio da seguire. Ha senso mantenere quella storia? E’ ancora valida o può essere considerata superata?

Individuare le epiche

Che siano presenti esplicitamente nel backlog o meno, lo step di individuare le epiche e formularle in maniera comprensibile a voi e al team vi aiuterà molto a chiarire le idee.
Se, ad esempio, state iniziando a lavorare su un dominio nuovo il lavoro sulle epiche sarà il primo passo per organizzare le nuove conoscenze.
Potreste non avere le idee chiare sui dettagli, ma a livello più alto vi sarete fatti una visione a 360 gradi del progetto.
Createle ex-novo o modificatele secondo le vostre necessità, ma non saltate questo passaggio. Sarà più utile di quanto pensiate anche nella comunicazione con i vari attori.
Ricordate che anche a questo livello potete effettuare dei tagli.

Distinguere le user stories da storie tecniche… o altre amenità

Su questo punto ci sarebbe da scrivere un romanzo intero!
Chiariamo qualche presupposto: un titolo non è una user story, una soluzione tecnica non è una user story, la lista della spesa sulle modifiche al layout non sono storie, un componente applicativo non è il soggetto di una user story… non vado oltre.
Ciò che intendo dire è che il vostro backlog dovrà contenere per la maggior parte delle vere user stories, pensate e formulate secondo i canoni. Controllate che sia effettivamente così.
Poi ovviamente saranno presenti anche altre cose, non ultime tutta una serie di attività tecniche. Ma è opportuno che queste siano ben distinte dalle altre, anche per verificarne il peso complessivo e poter creare il giusto mix funzionale-tecnico ad ogni sprint.
Anche le storie tecniche devono avere un perché: migliorare le performance, risolvere un bug, rendere più facili gli sviluppi futuri, garantire la stabilità della piattaforma. Se il team non è in grado di individuarne il valore da solo educateli gentilmente a questa pratica. E’ utile per tutti.

Scartare le storie che sono già soluzioni

Almeno alcuni di questi esemplari li troverete sicuramente nel backlog in eredità (sono pronta a scommettere!).
Evitatele come la peste.
Apparentemente vi hanno già risolto un problema indicando la soluzione da adottare, in realtà nascondono spesso scarsa chiarezza sui bisogni ai quali rispondono.
Se trovate user stories che sono già la soluzione al problema procedete al contrario. Risalite la corrente e andate a verificare le necessità dalle quali hanno avuto origine. Cercate chi può darvi queste risposte e se non trovate nessuno o non è possibile risalire al reale bisogno buttatele nel cestino.

Associare le user stories alle epiche

Adesso che avete definito le epiche dei vostri progetti e avete distinto gli aspetti tecnici da quelli funzionali non vi resta che associare ogni user story alla relativa epica.
Questo passaggio potrebbe portarvi anche a riformulare le epiche secondo un nuovo schema. Poco male, purché veicoli una maggiore comprensione.
Nel caso in cui qualche storia rimanga “orfana” provate a chiedervi se avete dimenticato qualche parte del progetto non censito dalle epiche o se – piuttosto – sia la storia a dover essere riconsiderata (in molti casi si rivelerà materiale di cui potete fare a meno).

Individuare le user stories di maggior valore

Siam sempre lì.
Il nostro lavoro è la celebrazione dal principio di Pareto.
Ricordate l’idea dell’80/20 applicato al backlog? E’ proprio ciò di cui sto parlando.
Per ogni epica che avete definito dovreste riuscire ad individuare le user stories fondamentali. Di certo non avranno tutte il medesimo valore.
Ordinatele secondo questo criterio e abbiate ben chiare quali sono quelle chiave. Le altre potrebbero rivelarsi superflue strada facendo.

Chiedere, chiedere, chiedere

Fate una marea di domande ai vostri stakeholder e interlocutori. Avete tutto il diritto di non capire ciò che è stato sintetizzato da altri quindi vincete il timore di passare per stupidi e – piuttosto – siatelo. Finché non capite cosa vi stanno chiedendo di portare a termine e perché, non sarete in grado di fare il bene il vostro lavoro. Quindi mettete da parte ogni remora e fatevi sotto!

Fare declutter

Alla fine di tutto questo lavoro avrete comunque la sensazione che ci sia del superfluo e di sicuro… avete ragione! Ogni occasione è buona per fare pulizia nel backlog, ma l’occasione della “prima volta” non vi ricapiterà più quindi non fatevela sfuggire.
Non temete di essere troppo radicali, buttate!
Mal che vada se si tratta di cose fondamentali le richieste torneranno ad emergere. Ma nella maggior parte dei casi ciò che pensate non sia importante non sarà più sollecitato da nessuno.
Vi consiglio solo di fare questa operazione nel momento in cui vi sentite relativamente confidenti sul dominio. Avete scelto di fare dei tagli, ma lo avete fatto consapevolmente.

Puntare all’essenziale

Questo punto è un rinforzo del paragrafo precedente. Anche se temete di eliminare qualcosa che “prima o poi viene buona”, resistete alla tentazione del “non si sa mai”.
State per iniziare un lungo viaggio. Viaggiate leggeri.
Portate con voi l’essenziale perché inevitabilmente il materiale crescerà lungo la strada del progetto.
Se invece siete così abili da avere ridotto il vostro backlog a non più di una trentina di item, vi prego contattatemi. Voglio intervistarvi e imparare i vostri trucchi!
Se al contrario vi sentite troppo timorosi per effettuare tagli sfidate voi stessi: cosa succederebbe se di tutte le storie contenute nel backlog ne cancellassimo un quarto, un terzo, la metà?

Tenere sotto controllo la dimensione

Quanti item contiene il backlog che avete davanti?
30? 50? 100? Oltre?
Questo numero può darvi delle indicazioni importanti.
Se il backlog contiene più di un centinaio di storie è difficilmente gestibile e già 100 sono un numero oneroso.
Provate a verificare se qualcosa può essere cancellato o, nel caso, accorpato. Inutile avere dettagli minuziosi su attività che verranno portate a termine tra mesi. Concentratevi su ciò che dovrà essere lavorato nell’arco dei prossimi 2-3 mesi; il resto può essere sintetizzato in epiche o temi.
Un grande backlog fa rallentare, defocalizza il team e offusca i progressi. Al contrario un backlog troppo minuto è l’indizio che o non avete lavorato bene sul futuro più prossimo o è ora di andare a fare quattro chiacchiere con i vostri stakeholder.

Verificare gli obiettivi

Provate a guardare il vostro backlog dal punto di vista degli obiettivi, non  delle epiche.
Quello che vedete è un’immagine coerente ed equilibrata?
E’ allineata con la fase del ciclo di vita del prodotto?
Questa è la “prova del 9” del product backlog.
Ci possono essere delle fasi in cui si punta maggiormente alla monetizzazione o alla riduzione dei costi, ma ci sono tanti altri criteri oltre al soldo che definiscono un buon prodotto e un’azienda vincente (market share, usabilità, scalabilità, branding, innovazione tecnologica, ecc.).
Se la quasi totalità delle vostre user story punta alla generazione di ricavi e dimentica tutto il resto è la spia che il backlog debba essere attentamente riconsiderato.

Pubblicato il

Tecniche di prioritizzazione: 5 spunti per iniziare

prioritizzazione

Recentemente ho visto girare in rete un articolo molto interessante che presentava le tecniche di prioritizzazione attraverso la metafora della tavola periodica degli elementi (a cura di Folding Burritos).

Le 20 tecniche proposte venivano classificate in base a due criteri principali:
– quantitativo vs. qualitativo
– interno vs. esterno

Alcune di queste – come il Kano model, il MoSCoW, lo story mapping e l’opportunity scoring – le conoscevo bene, altre di nome ma non di fatto (ad esempio le tecniche di analisi finanziaria che non ho mai avuto modo di sperimentare in prima persona), altre ancora erano una novità assoluta.

Nell’articolo trovate un link per scaricare – previa registrazione – un ebook in cui le 20 metodologie sono analizzate in dettaglio (ne vale la pena!).
Da questa lettura ho ricavato qualche consiglio su come approcciarsi alle varie tecniche di prioritizzazione, che riporto qui sotto.

1. Non esiste uno strumento infallibile per definire le priorità

Prima di iniziare una doverosa premessa: tutti i metodi sono validi ma nessuno è un oracolo. Pensiamo ad esempio ai metodi quantitativi e qualitativi.

Le persone tendono ad associare i metodi quantitativi ai numeri, quindi alla precisione e alla confidenza nella stima, ma non esistono strumenti infallibili!
E’ vero che le tecniche quantitative si basano su metriche, classificazioni, voti o ranking, ma si fondano pur sempre su assunzioni ed ipotesi che devono essere validate nella realtà.

Allo stesso modo le metodologie qualitative non sono da ritenersi “inaffidabili” in quanto non oggettive. Sono per loro natura più esplorative che confermatorie e possono offrire molto velocemente insight importanti.

2. Qual è il criterio migliore in assoluto? Dipende dal contesto…

Abbiamo capito che non esiste la bacchetta magica quando si parla di tecniche di prioritizzazione, ma la buona notizia è che abbiamo tante frecce al nostro arco.
Le metodologie sono diverse ed è opportuno verificare l’ambito al quale devono essere applicate e le condizioni di contorno.

Come sceglierle? Applichiamo il buonsenso e cerchiamo di capire quale strumento può essere più utile – o più accessibile – in relazione al nostro prodotto, al suo ciclo di vita, al team di lavoro e all’azienda.

Torniamo alla distinzione precedente: le metodologie qualitative possono essere più utili nel momento in cui il prodotto è ancora ad una fase iniziale, quando l’esigenza più importante è raccogliere feedback dal mercato e costruire un modello dei propri utenti. In questo caso sceglieremo tecniche che ci consentano di raccogliere un ampio ventaglio di informazioni e di esplorare i bisogni più in profondità.

Le metodologie quantitative sono più adatte ad un prodotto in una fase più matura quando è richiesto un minimo di base dati da cui partire. Consentono di verificare le ipotesi di partenza e garantiscono maggiore oggettività delle analisi.
Le tecniche orientate verso l’esterno esplorano meglio obiettivi e funzionalità di alto livello; quelle interne funzionano meglio per problemi concreti.

3. Parti ad alto livello e non perderti nei dettagli

Tutte le tecniche proposte funzionano bene quando si tratta di dare priorità ad epiche, temi ed obiettivi dell’utente; a più basso livello tendono a perdere di efficacia e di significato.

L’obiettivo è di arrivare a definire cosa ha valore per l’utente e cosa non ne ha, non decidere se un criterio di ordinamento per rilevanza è più o meno importante di quello per prezzo.
Il mio consiglio è di partire a prioritizzare le macro-funzionalità tenendo ben presente la visione strategica di prodotto e confrontandosi – se possibile – con gli utenti.
Alcune delle tecniche proposte – ad esempio lo story mapping, il MoSCoW, il Kano model o Buy a feature – si prestano perfettamente a questo scopo.

Una volta definite le priorità ad alto livello si può pensare di approfondire i dettagli principali di un tema attraverso altri strumenti quali Opportunity scoring, Score card, Theme screening e Valore vs. Costo/Rischio.
Esplorate le possibili declinazioni di un tema, ma tenetevi a distanza dalle minuzie.

4. Prioritizzare è un lavoro di gruppo

Il confronto è particolarmente importante in quest’ambito. Senza di esso potremmo avere un punto di vista totalmente falsato.
E’ opportuno che la prioritizzazione non sia lo sforzo di una singola persona.

Ci sono alcuni metodi estremamente semplici che potreste portare avanti da soli, ma è sempre meglio fare questo lavoro con persone che abbiano punti di vista differenti sul prodotto, siano essi clienti, utenti, stakeholders o membri del team di sviluppo.
Fate lo sforzo di mettere in discussione le vostre convinzioni e ascoltate cosa emerge dal confronto. Oltre ad avere una visione più chiara di quali siano le reali priorità questa opportunità potrebbe farvi scoprire prospettive nuove ed interessanti che non avete considerato.

5. Mix and match!

Gli strumenti sono tanti, ognuno di essi ha vantaggi e svantaggi quindi non limitatevi ad un’unica tecnica di prioritizzazione.
Sperimentatene diverse, provate a combinarle tra loro, mettetele a confronto sul medesimo set di funzionalità. Col tempo scoprirete quali vi sono più congeniali e quali sono più efficaci in un determinato contesto.

E dopo? Per ogni priorità definite degli obiettivi misurabili

Una volta che siete riusciti a definire ad alto e medio livello quali sono le priorità che porteranno maggior valore ai vostri utenti, non dimenticate di mettere alla prova questi risultati mano a mano che lo sviluppo rilascerà le funzionalità secondo l’ordine concordato.

Stiamo perseguendo lo scopo di creare valore, quindi dovremmo essere in grado di definire un cambiamento misurabile nel comportamento dei nostri utenti.
Verifichiamo l’effetto delle nostre scelte analizzandone l’impatto, il ROI, i comportamenti di utilizzo e qualsiasi kpi di business faccia al caso vostro (sul tema impatto e come misurarlo abbiamo discusso a lungo in questi post).

La finalità non è la prioritizzazione in sé, ma arrivare ad essere sempre consapevoli se ciò che facciamo sta effettivamente portando valore agli utilizzatori finali. Se scoprissimo che non è così avremo indicazioni su ciò che va ripensato.

Proudly powered by WordPress