Certificarsi Product Owner

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

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:

  • le responsabilità del Product Owner
  • la stima del business value
  • la pianificazione delle release
  • la gestione del product backlog
  • il ruolo del PO in relazione alle altre figure Scrum e molto altro ancora

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

La logistica non arride a noi italiani, ma qualcosa si sta muovendo anche qui …
Sino al 2013 era quasi impossibile trovare un corso di certificazione da Product Owner nel nostro paese, a differenza di quelli per Scrum Master per i quali c’è invece maggiore offerta. Questo è il motivo per cui oltre un anno e mezzo fa ho scelto Londra per ottenere l’attestato di CSPO.

Per il 2016 facendo una veloce ricerca su Internet trovo in programmazione ben 4 appuntamenti: uno a Milano ad aprile tenuto da Pierluigi Pugliese,  un corso a Bologna a giugno tenuto da Agile 42 ed altri due corsi sempre a Milano – a giugno ed a settembre – tutti riconosciuti da Scrum Alliance.
Nessuna data italiana invece per corsi targati Scrum.org o Scrum Inc.
Ho trovato inoltre alcune società che offrono corsi online di Scrum Product Owner Certified – SPOC™ (iLearn ed E-quality Italia) ed altre che li erogano direttamente presso le aziende su richiesta e con un numero minimo di partecipanti.

A seconda del vostro caso potete vagliare qual è la soluzione più opportuna.
Personalmente tuttavia non prenderei in considerazione i corsi online perché ritengo parte fondamentale di questo tipo di formazione i role playing che avvengono in aula con il docente e con gli altri partecipanti.

Quanto costa

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 cosidetta “early bird”) pari a ca. 1.000 euro + IVA.
Il prezzo pieno parte dai 1.200 euro + IVA per corsi tenuti in Italia, a salire per quelli disponibili nel resto d’Europa (sino a circa 1.700 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 transizione agile … ;-)

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 300 euro + IVA).

Quale trainer

Il formatore può dipendere del tutto dalla logistica se non avete la possibilità di fare il corso di certificazione all’estero.
In ogni caso i trainer accreditati presso le maggiori organizzazioni che promuovono Scrum nel mondo offrono garanzie di professionalità e grande esperienza.

Se però avete possibilità di scelta vi consiglio 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, ad esempio, potete selezionare tra un numero elevato di trainer alcuni dei quali sono dei guru indiscussi della product ownership.

Perché 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: in questo momento in Italia la professione di Product Owner non è ancora così affermata.
Diverse aziende che cominciano ad avvicinarsi alle metodologie agili decidono di investire sulla figura dello Scrum Master ma non sentono subito l’esigenza di assumere o far crescere un PO (Date pure un occhio ai numeri…).

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 (provate a fare una ricerca su Linkedin se non mi credete) vi darà il vantaggio dei first mover!

4 livelli per requisiti agili

Recentemente ho avuto occasione di seguire un workshop di Sally Elatta dal titolo “4 levels of Agile Requirements”.
L’idea centrale della relatrice – fondatrice di Agile Transformation e Agile coach – è che sia fondamentale approcciare i requisiti agili secondo diversi gradi di astrazione.

Questo modus operandi non è una novità.
Abbiamo già parlato di come l’introduzione di una gerarchia nel Product Backlog possa essere d’aiuto sia per il team sia nei rapporti con gli stakeholder di progetto.

Sally Elatta ripropone questa idea sottolineando l’importanza di avere punti di vista sul progetto che vanno dal generale al particolare, ovvero:
epiche
funzionalità
user stories
– singole attività (task)

Considerare i requisiti secondo questi 4 livelli di astrazione consente di legare le singole attività implementative con la “big picture” del progetto e dare così valore alle scelte che dovremo effettuare nel corso dello sviluppo.

Livelli di progetto

La continuità tra i vari livelli è ben rappresentata nell’immagine.
In relazione al Backlog ci interessa concentrare l’attenzione sui 3 livelli centrali.

USER STORIES

Le user story rappresentano il secondo livello dal basso, quello in cui propriamente avviene l’azione o interazione.
Descrivono brevemente ciò che il sistema può fare per risolvere un problema specifico di un utente ben definito.
La caratteristica principale delle storie è essere focalizzate sul valore che producono per il soggetto, a differenza dei singoli task che sono invece una segmentazione delle attività ai fini della lavorazione da parte del team.

 

FUNZIONALITA’

Ad un livello superiore di astrazione rispetto alle user stories troviamo le funzionalità (features), che costituiscono una descrizione più tradizionale del comportamento del sistema.
Sono il livello intermedio tra i bisogni dell’utente e la soluzione progettuale complessiva.
Il concetto di funzionalità ha dal mio punto di vista un enorme pregio: collega le singole attività portate avanti dal Team Scrum con una terminologia utilizzata abitualmente da figure professionali quali Program Manager, Product Manager e manager in generale.
Mediante un elenco di funzionalità siamo in grado di descrivere il nostro progetto con un discreto grado di approfondimento e di spiegarlo anche ad interlocutori non avvezzi alle metodologie agili.

In alcune realtà aziendali di dimensioni medio-grandi anche i team di sviluppatori potrebbero essere organizzati intorno a queste feature.

 

EPICHE

Infine le epiche rappresentano il livello più alto di espressione del bisogno di un utente.
Sono i pilastri della big picture, le caratteristiche costituenti.

Le epiche sono i primi elementi che emergono dal concept di progetto. Si tratta di storie di grandi o grandissime dimensioni che
permettono di comunicare il perimetro di progetto in poche battute ma non consentono di effettuare una stima iniziale dato l’elevato livello di astrazione.

Il collegamento tra questi 3 livelli – storie, funzionalità ed epiche – ci consente di avere maggiore controllo sullo stato di avanzamento del progetto ed offre una chiave di lettura di immediata comprensione agli interlocutori.

Per questo motivo può essere molto utile verificare la consistenza del backlog salendo e scendendo attraverso questi 3 livelli.

Facciamo qualche esempio di “prova del 9“:

  • Possiamo ricondurre tutte le user stories ad un’epica corrispondente?
    Se non è così probabilmente potremmo avere “lavoro sommerso” e sprint goal poco definiti.
  • Ci sono epiche a cui sono collegate pochissime user stories?Verifichiamo di aver compreso bene le aspettative degli stakeholder. Potremmo aver perso qualcosa per strada o non aver spacchettato correttamente il lavoro.
  • Siamo in grado di tradurre il backlog della release in una lista di funzionalità? Possiamo sintetizzare con una percentuale di avanzamento a che punto sono queste feature ?

Potreste accorgervi – come nel mio caso – che non state utilizzando coerentemente o con continuità tutti e 3 i livelli.
Non resta che ispezionare e adattare il backlog, in perfetto spirito agile…