Ho ereditato un product backlog… e adesso?

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.

Il primo Product Owner della storia

In questi giorni sto leggendo il libro di Jeff SutherlandFare il doppio in metà tempo: Puntare al successo con il metodo Scrum“.
Il volume racconta in maniera discorsiva come attraverso varie esperienze personali e professionali Sutherland – il padre fondatore di Scrum insieme a Ken Schwaber – sia arrivato ad elaborare il famoso framework.

Non mancano aneddoti divertenti sui progetti più disparati salvati dall’adozione di Scrum (dai sistemi di antiterrorismo sviluppati dall’FBI, ai primi ATM, agli applicativi per la gestione delle ricette online, ma anche ristrutturazioni edilizie e matrimoni).

Una delle parti più interessanti per me è il racconto di come è nata la figura del Product Owner e come se l’è immaginata ai tempi l’autore.

Tutto sta a mettere in ordine di priorità il lavoro da fare.
Come si fa? Beh, per prima cosa vi serve qualcuno che sia in grado di capire contemporaneamente qual è la visione e dove sta il valore. In Scrum lo chiamiamo “Product Owner”.

Il Product Owner decide quale dev’essere il lavoro. Gestisce il Backlog, i compiti che include, e soprattutto l’ordine in cui vanno messi in atto.
Nel 1993, quando ho avviato il primo team Scrum, non avevo un Product Owner. Facevo parte del gruppo dirigente e avevo tante altre responsabilità oltre a quella di capire esattamente cosa doveva fare il team in ogni Sprint.
Mi occupavo del management e del marketing, trattavo con i clienti e definivo la strategia. Ma in quel primo Sprint ho capito che potevo anche gestire il Backlog. Dovevo solo fare in modo di avere abbastanza “storie” e abbastanza caratteristiche su cui mettere al lavoro il team nello Sprint successivo.
Il problema era che dopo il secondo Sprint abbiamo introdotto il Daily Stand-up. La velocità è aumentata del 400% nello Sprint successivo, e il team ha portato a termine in una settimana il lavoro che avevamo preventivato su un mese.
Non c’era un altro Backlog su cui metterlo al lavoro! Avevo pensato di avere davanti un mese per creare altre “storie”.
È un problema che vorrebbero tutti, bisogna ammetterlo, ma andava comunque affrontato. Quindi ho ideato il ruolo del Product Owner e ho cercato di capire che caratteristiche dovrebbe avere idealmente chi è chiamato a ricoprirlo.

Mi sono ispirato al Chief Engineer di Toyota
… ciò che non hanno [ i Chief Engineer] è l’autorità.
Nessuno riporta a loro, semmai sono loro che riportano ai propri gruppi.
I collaboratori possono dire ai Chief Engineer che sbagliano, perciò costoro devono accertarsi di aver ragione.
Non valutano la performance di nessuno, e non concedono né promozioni né aumenti, ma decidono la visione della nuova vettura, e stabiliscono come verrà costruita, con la persuasione, e non con la coercizione.
È questa idea che volevo incorporare in Scrum.

Già agli albori di Scrum sapevo di aver bisogno di qualcuno che conoscesse molto bene il cliente.
Il Product Owner doveva essere in grado di riportare al team il feedback del cliente a ogni Sprint. Doveva dedicare metà del proprio tempo a parlare con le persone che acquistavano il prodotto (ascoltandone le opinioni sull’ultima release incrementale e su come creava valore), e l’altra metà a sviluppare il Backlog con il team (spiegando ai suoi membri cosa apprezzavano e cosa non apprezzavano i clienti).
Ricordatevi che il “cliente” potrebbe essere il consumatore in generale, una grande banca, vostro marito o chi ha bisogno del vaccino contro il rotavirus e dipende da voi per ottenerlo. Il cliente è chiunque tragga valore da ciò che fate.
Però non volevo un manager. Volevo qualcuno in cui il team credesse e di cui potesse fidarsi quando metteva in ordine di priorità il Backlog. Perciò sono andato a prendere il più bravo di tutti nel product marketing; attenzione, non nell’engineering, ma nel marketing. Ed è così che Don Rodner è diventato il primo Product Owner.
Conosceva il prodotto che stavamo sviluppando non da un punto di vista tecnico – pur sapendone abbastanza da poter comunicare con gli ingegneri – ma piuttosto dal punto di vista del cliente.
Di che cosa avevano bisogno coloro che usavano effettivamente il prodotto? Quando siete alla ricerca di un Product Owner, scegliete qualcuno che sia in grado di mettersi nei panni di chiunque tragga valore da ciò che fate.

Tecniche di prioritizzazione: 5 spunti per iniziare

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.