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.

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.
Le 20 tecniche proposte venivano classificate in base a due criteri principali:
– quantotativo 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.
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.

Come gestire user stories tecniche

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 affrontarle?

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…