Certificarsi Product Owner

Periodicamente ripropongo questo post che suscita sempre un certo interesse vedendo le statistiche. Nell’ormai lontano 2015 scrivevo così…

Di ritorno da una 2 giorni londinese con Roman Pichler ho deciso di scrivere un post per tutti coloro che stanno meditando sul tema certificazione Scrum Product Owner.
A ruota libera seguono alcune informazioni pratiche e qualche consiglio di prima mano.

Quando fare la certificazione

Nel mio caso il corso di certificazione arriva dopo qualche anno che svolgo il ruolo di Product Owner.
Non sarò imparziale ma ritengo che per trarre il massimo da questo corso sia utile affrontarlo dopo aver svolto un po’ di esperienza sul campo ed aver toccato con mano quali possono essere i problemi più comuni nell’adozione di Scrum e nelle transizioni agili.

Durante il corso della durata di 2 giorni vengono trattati tutti gli argomenti relativi alla product ownership:

Oltre ad approfondire la teoria vengono chiariti dubbi tramite esempi ed esercitazioni in aula. E’ un’ottima occasione per mettere alla prova le vostre conoscenze e portare esempi di prima mano. Fate domande e confrontatevi con i vostri colleghi di corso. Solo così sfrutterete al massimo il corso (quando mai vi capita di ritrovarvi con decine di Product Owner a portata di mano?).

Dove trovare un corso valido

Ai tempi della mia certificazione la logistica non arrideva certo a noi italiani.
Sino al 2013 era quasi impossibile trovare un corso da Product Owner nel nostro paese, a differenza di quelli per Scrum Master per i quali c’era già maggiore offerta. Questo è il motivo per cui 5 anni fa ho scelto Londra per ottenere l’attestato di CSPO.

Fortunatamente oggigiorno il panorama è cambiato e la scelta è molto più ampia.
Online trovate pagine e pagine di annunci sui corsi di certificazione; ce ne sono così tanti che è davvero difficile orientarsi per chi è alle prime armi.
Quindi se nel post originario elencavo le poche alternative presenti, adesso mi permetto di suggerirvi le società che conosco personalmente, che hanno maggiore esperienza sul campo e sono veramente attive nella community Agile italiana (aka sanno perfettamente di ciò che parlano).
Ecco qui di seguito in ordine sparso i corsi che offrono.

Certified Scrum Product Owner®Connexxo

C’è un corso online in inglese tenuto da Pierluigi Pugliese verso la fine di gennaio e uno in lingua italiana all’inizio di febbraio. Di fatto trovate un corso di certificazione ogni mese quindi vi consiglio di tenere d’occhio il calendario.
Pierluigi è un trainer di grande esperienza che, oltre alle conoscenze teoriche, può trasmettervi consigli e suggerimenti per il lavoro sul campo.

Certified Scrum Product Owner®Agile42

Anche in questo caso parliamo di un corso remoto che consente di acquisire la certificazione CSPO di Scrum Alliance. I coach di agile42 che lo tengono sono Giuseppe De Simone e Roberto Bettazzoni. Il primo appuntamento è in programma per il 17 febbraio 2021 ma trovate anche date successive.

Professional Scrum Product Owner PSPO IInspearit

Tre date disponibili nel 2021 per la certificazione rilasciata da Scrum.org.
La formazione prevede molti workshop pratici e giochi per facilitare l’apprendimento dei concetti e per stimolare a proseguire con l’allenamento delle abilità dopo il corso.

Agile Reloaded

Agile Reloaded è una realtà tutta italiana che aiuta aziende, enti e organizzazioni ad applicare la metodologia agile per migliorare i processi, la collaborazione e il time to market. E’ un team di coach di tutto rispetto e anche se il sito non riporta in questo momento un elenco di corsi a catalogo vi consiglio di contattarli perché sanno la loro sul tema Product Ownership.

Sembra che nel nuovo anno tutta la formazione rimanga online per ora e – date le difficoltà attuali – va bene così.
Tuttavia quando la situazione tornerà normale considerate la possibilità di optare per i corsi in presenza perché ritengo parte fondamentale di questo tipo di training i role playing che avvengono in aula con il docente e con gli altri partecipanti (si possono fare anche con il supporto di tanti tool online, ma non è la stessa cosa).

Quanto costa certificarsi Product Owner

Una cosa è certa: non è regalato!
Se pianificate il corso con un certo anticipo e non avete particolare fretta di ottenere la certificazione potrete beneficiare di una tariffa scontata (la cosiddetta “early bird”) pari a ca. 1.000- 1.100 euro + IVA.
Il prezzo pieno più basso che ho visto parte dai 1.035 euro + IVA per corsi tenuti in Italia, la media è intorno ai 1.300 euro + IVA; più cari invece i corsi disponibili nel resto d’Europa (si va da 1.500 a oltre 2.300 euro).

In ogni caso non si tratta di una cifra banale, motivo per cui vi consiglio di tenere d’occhio con largo anticipo il calendario dei corsi e – se possibile – provare a proporre in prima persona questo percorso di formazione alle risorse umane. Chissà mai che ve lo accordino o lo prendano in considerazione come parte di un intervento più ampio di digital transformation … ;-)

Se invece dovete risparmiare a tutti i costi ma non volete rinunciare ad un attestato riconosciuto sappiate che i corsi online in modalità self-study hanno prezzi decisamente più contenuti (parliamo di circa 350 euro + IVA). E’ un’opzione anche questa, ma non mi sento di caldeggiarla.

Quale trainer scegliere

In tempi normali alcuni formatori sono inaccessibili per via della logistica ma dovendo andare online in ogni caso se non avete problemi con la lingua inglese scegliete tra i top di gamma.
Tenete presente in ogni caso che i trainer accreditati presso le maggiori organizzazioni che promuovono Scrum nel mondo offrono garanzie di professionalità e grande esperienza.

Se avete possibilità di scelta vi suggerisco di selezionare un  coach che non sia solo un esperto di metodologie agili e Scrum, ma che abbia una specifica esperienza sul campo come Product Owner. Sul sito di Scrum Alliance e Scrum.org, ad esempio, potete scegliere tra un numero elevato di trainer alcuni dei quali sono dei guru indiscussi della product ownership.

I motivi per certificarsi

Ho scelto di certificarmi perché mi piace portare a compimento quello che faccio e allo stesso tempo mettere in discussione le mie conoscenze.
Ho avuto la fortuna di accedere al corso a spese della mia azienda, ma sono stata io stessa a proporlo al mio responsabile come un importante gradino di crescita nel mio percorso professionale.
Ho avuto l’opportunità e l’ho presa, ma avrei sostenuto il corso a mie spese?

Sono realista: quando mi sono certificata in Italia la professione di Product Owner non era ancora così affermata.
Diverse aziende che cominciavano ad avvicinarsi alle metodologie agili decidevano di investire sulla figura dello Scrum Master ma non sentivano l’esigenza di assumere o far crescere un PO.

Dal post originale del 2015…
E’ questione di tempo. Mano a mano che lo sviluppo software adotterà sempre più pratiche agili anche le figure professionali legate a questa metodologia saranno più richieste.
A quel punto avere in mano una certificazione che è una rarità in Italia vi darà il vantaggio dei first mover!

Oggi alla fine del 2020 posso dire che si è davvero realizzato quello scenario; Linkedin indicizza 22.000 Product Owner in Italia.
Le aziende hanno compreso l’importanza di questo ruolo e cercano persone preparate che le aiutino nelle tante sfide digitali presenti e future.
Sono sempre di più le persone che si certificano, in alcuni casi senza neanche avere esperienza sul campo. A tutte loro auguro di incontrare favolosi mentor com’è stato per me e di non smettere mai di crescere nelle competenze della product ownership.

Backlog declutter 2: come mettere ordine tra le user stories

Come scegliere i requisiti da tenere seguendo il criterio della felicità… dei clienti!

Questa è la seconda parte di un post dedicato al declutter del backlog.
Qui, se ve la siete persa, trovate la prima parte.

Ci siamo lasciati parlando di user stories che hanno campeggiato troppo a lungo nel product backlog senza mai essere state portate in priorità. 
Vediamo quali altri casi sono buoni candidati per l’eliminazione.

Le user stories che ho nel mio backlog  hanno individuato un soggetto reale?
Stiamo parlando di persone o di moduli?
Si tratta di un’attività di valore?
Abbiamo individuato un reale bisogno o solo una soluzione tecnica?
Queste storie sono ottimi spunti per fare pulizia.
E poi la coerenza con la strategia generale. Potremmo avere in realtà degli item così vecchi che sono ormai superati perché le strategie aziendali hanno preso una direzione differente.

Sono tutte considerazioni che possiamo fare.
Non temete di eliminare troppo, non rimarrete mai senza nulla…
Se invece vi sentite sopraffati dall’impresa non scoraggiatevi. 
C’è sempre chi ha affrontato di peggio, come nel caso di una transizione a LESS in cui si è passati da 508 item a 23 user stories. Qui probabilmente si erano spinti un po’ troppo in là con la granularità, però è un buon esempio del fatto che è possibile fare un’operazione significativa di pulizia. 
Come? Seguendo gli step che stiamo percorrendo noi… hanno fatto un lavoro colleggiale, hanno stampato tutti gli item e li hanno classificati, che è esattamente il passo successivo.

Adesso con tutte le card davanti a noi concentriamoci su quali criteri utilizzare nel processo di eliminazione.

Categorizzare le user stories

Per fare ordine dopo la fase dell’eliminazione si passa al categorizzare. 
Riordinare per categoria è un altro principio cardine nella gestione del clutter fisico. 
Non si riordina stanza per stanza ma categoria per categoria: vestiti, libri carte, ricordi.
Andremo a individuare delle categorie e a classificare gli item uno alla volta. 
Ognuno di voi dovrà trovare il criterio che meglio si adatta al proprio caso. 

Ecco qualche idea: categorizzate per epiche, step dello user journey, impatti, stakeholder o obiettivi di business. Potete focalizzarvi sul contenuto, sul valore, sugli interlocutori e molto altro. 
Il mio consiglio fondamentalmente è di provare varie classificazioni e vedere quella che meglio si adatta al vostro caso. Personalmente ho iniziato utilizzando gli step del processo poi mi sono resa conto che non era esattamente ciò di cui avevo bisogno, era troppo vincolante mentre mi sono trovata molto meglio con quelli focalizzate sulla parte dei contenuti.

Mettere a confronto

Una volta che siete riusciti a categorizzare le vostre storie dovete fare un lavoro all’interno di ognuna di queste categorie e procedere per confronti.
In sostanza avete definito dei sotto raggruppamenti nel backlog e in ognuno di questi fate un lavoro di prioritizzazione.
Potreste scoprire anche in questa fase che qualcosa può essere ancora eliminato. Ad esempio se provassimo a vedere ognuna di queste categorie attraverso il principio di Pareto qual è il 20% delle user stories che producono 80% del valore?
Quali sono dei must? Quali should o could?
Siamo in grado di individuare i must-have per gli utenti e quelle storie che invece possono fare la differenza ed essere dei delighters?
Trovate il focus!
Provate a riconsiderare ognuna di queste categorie sulla base di varie tecniche di prioritizzazione. Più una… che ho tenuto a parte.

La felicità come criterio di scelta

Questa è un’idea mutuata proprio dal declutter: non dovremmo scegliere che cosa buttare bensì scegliere cosa tenere. E il criterio in questo caso è conservare solo ciò che ci rende felici, che ci fa sentire bene, che ci risuona emotivamente.
Non voglio prendere una deriva new-age fricchettona, dico solo che questa idea può essere trasposta nella gestione del backlog.
Quanta felicità una determinata storia porta ai nostri utenti?
In una scala di felicità siamo sicuri che l’ordinamento che ci siamo dati sia quello corretto? Riesco a produrre un impatto significativo nei miei utenti?

Continuare a prendersi cura

Bene una volta che abbiamo fatto questo repulisti, abbiamo organizzato i nostri item per categorie e abbiamo dato anche un ordine di priorità guardiamo con un occhio più attento ogni singolo elemento che abbiamo conservato.

Dobbiamo verificare che sia tutto effettivamente in ordine. Andare a vedere se ognuno di questi item che abbiamo conservato è completo, ha la struttura corretta, se abbiamo individuato realmente chi sono gli interlocutori e quali sono i loro bisogni.
E capire se sono coerenti con lo scenario attuale.

Una delle cose che si possono fare è focalizzarsi sulla prossima release di prodotto e cercare di associare al backlog una roadmap di prodotto per gli sviluppi più avanti nel tempo. 
Anche qui facciamoci delle domande per verificare che effettivamente quello che abbiamo conservato sia in buono stato: abbiamo tenuto conto di tutti gli interlocutori?
Abbiamo individuato bisogni espliciti ed impliciti?
Tutto questo è coerente con la strategia più generale?

Dopodichè non ci resta che…

Evitare le ricadute

Bisogna evitare di tornare nella situazione dalla quale siamo partiti. Come possiamo farlo? Dobbiamo avere attenzione nei confronti di ciò che a questo punto entra all’interno del backlog. E qui possiamo cogliere diversi spunti.
Diamoci una finestra temporale. In un armadio teniamo i vestiti per la stagione in corso, perché non nel backlog?
Facciamo in modo che il nostro backlog sia focalizzato sui prossimi tre mesi massimo sei mesi magari.

Utilizziamo un criterio che definisca esattamente che cosa è pronto per il backlog e tutto quello che non lo è può essere inserito in una sorta di waiting box / may be box (un contenitore dove inseriamo tutta una serie di buone idee da cui potremmo andare a pescare successivamente).

Teniamo sott’occhio la ratio delle cose che entrano ed escono oppure diamo un limite esplicito al nostro backlog. Alcuni ad esempio si impongono una certa soglia oltre la quale non andare proprio perché appunto la visione complessiva del backlog si sfilaccia.

Vedere l’ordine

Un altro suggerimento che potrebbe esservi d’aiuto nel mantenere l’ordine è tenere sotto controllo il backlog utilizzando diverse modalità di visualizzazione.

Chi ha letto il libro di Marie Kondo sa che uno dei consigli più preziosi e totalmente controintuitivi è disporre gli indumenti nei cassetti in un modo diverso che uno sopra l’altro bensì in verticale.


Questa idea mi ha fatto riflettere e mi sono resa conto che a volte siamo troppo condizionati dalla strumento che utilizziamo per gestire il backlog.
Proviamo ad andare oltre jira e tool simili che mostrano il backlog come una lunga lista di item.
Vi invito a sperimentare modalità alternative che tengano conto non solo della quantità ma anche del contenuto del backlog.

Non voglio sapere semplicemente quanti item ho ma vorrei capire anche meglio come sono distribuiti sui vari contenuti.
Ricordate le categorie di cui abbiamo parlato prima? Voglio capire che tipo di gerarchia esiste tra i vari elementi, voglio avere più visibilità delle connessioni, voglio vedere la granularità. 

Qui le possibilità sono svariate: dal classico backlog analogico su parete, alla modalità story mapping, mappe mentali e mappe ad albero.
In questa presentazione potete vedere i vari spunti che ho solo raccolto alcuni spunti ma sono curiosa di capire se voi ne vedete altri o ne avete magari già utilizzato alcuni che ritenete particolarmente efficaci.

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!