Il ruolo del Product Owner

Cosa significa Scrum Product Owner

“Che lavoro faccio? Lo Scrum Product Owner“.
“Interessante, ma esattamente cosa vuol dire?”
Dato che la domanda è ricorrente e spesso mi rendo conto che le persone non hanno  un’idea precisa di cosa siano le metodologie agili e lo Scrum (men che meno del ruolo di Product Owner…) ho pensato di fare un riassunto delle principali competenze di questa figura.

Il Product Owner – recita la Scrum Guide – ha la responsabilità di massimizzare il valore del prodotto e del lavoro svolto dal Team di Sviluppo.
E’ colui o colei che decide cosa deve essere fatto, quali funzionalità deve avere un prodotto o un servizio e quando rilasciarle sul mercato (qui trovate le varie attività riassunte in un’immagine).

Su cosa dobbiamo esattamente intendere per “valore” da massimizzare la Scrum Guide non da indicazioni puntuali. Ed è comprensibile perché non è semplice trovare una formula valida per tutti (trovate maggiori dettagli sul tema valore in questo post).
Spesso il valore è identificato con le revenue, ma potrebbe anche essere la riduzione del rischio, la riduzione dei costi, la visibilità del marchio o altro.
Nella mia esperienza ciò che è di valore per un’azienda potrebbe non esserlo per un’altra, così come all’interno della stessa società ciò che è di valore oggi potrebbe non esserlo più nel tempo. 

Le caratteristiche di un buon Product Owner

Per poter guidare efficacemente lo sviluppo il PO deve avere un’ampia conoscenza dei bisogni degli utenti finali e comprendere come il prodotto possa rispondere a queste necessità. Attenzione a questo punto perché è determinante: il PO rappresenta la voce del cliente in azienda ma per essere davvero tale deve conoscerlo, avere contatti diretti, parlare con lui e avere elaborato un profilo delle principali tipologie di cliente (qui è dove parliamo di personas).

Il Product owner deve saper gestire gli stakeholder di progetto, avere un’idea dei processi di sviluppo software ed essere in grado di comunicare la propria vision di prodotto al team di sviluppo.
Il suo scopo principale è produrre valore per l’utente finale e l’azienda (viene infatti indicato come colui che ha la responsabilità di massimizzare il ROI).

Un coach con cui ho lavorato tempo fa mi diceva di saper riconoscere un buon Product Owner dalla “frenzyness”. Letteralmente frenesia …. Per me significa essere appassionati del proprio prodotto e dei propri utenti, avere una curiosità incessante per i problemi da risolvere e cercare sempre nuovi spunti di miglioramento.

Il Product Owner è un ruolo multi-sfaccettato ed è davvero difficile indicare tutte le caratteristiche che una persona dovrebbe avere, ma ci sono 3 aspetti secondo me imprescindibili: l’empatia, la capacità di articolare una visione e la leadership.

Gli strumenti del PO

Per gestire lo sviluppo di prodotto il Product Owner si avvale di alcuni strumenti e “cerimonie” Scrum.
Attraverso il product backlog definisce, comunica e ordina secondo priorità i requisiti di prodotto tramite user stories.
Pianifica sessioni di approfondimento dei requisiti (i “backlog refinement”), prepara il materiale necessario per lo Sprint planning meeting e, al termine delle iterazioni, approva o rifiuta quanto sviluppato dal team sulla base dei criteri di accettazione che ha precedentemente condiviso.

A livello strategico è responsabile di articolare la visione di prodotto, definirne la strategia complessiva e la roadmap.
A seconda della dimensione del prodotto e dell’organizzazione aziendale queste attività potrebbero essere in carico a persone diverse (qui abbiamo parlato di Big PO e Small PO).
In ogni caso è fondamentale che ogni Product Owner abbia un’idea chiara di quali risultati voglia ottenere attraverso il proprio prodotto e come possa evolvere nel tempo.

Un ruolo ibrido

Pur non essendo parte del team di sviluppo è una figura chiave all’interno dello Scrum team (il corrispettivo di un “regista” nella produzione di un film).
Collabora attivamente con gli sviluppatori chiarendo dubbi, rispondendo alle domande e definendo obiettivi di sviluppo in linea con la roadmap di prodotto e i desiderata degli utenti.

Come tutte le figure “ibride” si trova ad agire su una soglia.
E’ un’interfaccia che si colloca internamente all’azienda tra il business e l’IT, ma anche tra l’azienda e il mercato, tra i committenti e gli utenti finali.
Per mediare questi punti di vista – a volte in contrasto – il Product Owner non deve mai perdere la voglia e l’energia di comunicare con tutti gli interessati.

Qualche altro spunto di riflessione …

Per chi fosse interessato ad approfondire le caratteristiche di questa figura ecco due preziosi riferimenti, nonché “guru” della product ownership:

E qualche ulteriore spunto per approfondire le sfumature di questo fantastico ruolo: si parla di cosa sia la product ownership nel video animato di Henrik Kniberg; dei possibili ambiti di intervento del PO, a seconda dell’organizzazione dell’azienda, e infine di una delle capacità più importanti del Product Owner, ovvero saper dire di no.

User stories efficaci: 5 regole per non sbagliare

Una guida per scrivere user stories

Quest’estate, mentre ero alla ricerca di titoli relativi al product management e alla raccolta dei requisiti, mi sono imbattuta in un piccolo manualetto dal titolo “Writing effective user stories” di Thomas e Angela Hathaway.

Si tratta di un libro in formato digitale di dimensioni molto contenute (si legge in un soffio) che offre alcuni consigli di taglio molto pratico sulla formulazione delle user stories.

La formula delle user stories a cui fa riferimento il testo è quella classica, costituita da 3 elementi cardine: il punto di vista dell’utente (meglio sarebbe dire dello stakeholder), il risultato atteso e la motivazione per la quale viene realizzata l’attività in questione.

Ovvero: “In qualità di <utente> desidero che <risultato> così da <motivo>”.

La formula sembra facile, addirittura banale rispetto ai classici documenti di requisiti. Eppure nella sua essenzialità si rivela veramente efficace per descrivere ciò che dev’essere realizzato… a patto che… a patto che si rispettino queste 5 semplici regole!

Perseguire la semplicità

La user story deve indicare un solo risultato atteso, non di più!
Gli autori suggeriscono di evitare l’utilizzo di frasi composte e perifrasi, di star ben attenti alle espressioni che contengono congiunzioni quali “se”, “e” o “ma” ma anche “a meno che” ed “eccetto”, perché è molto probabile che – data la formulazione – nascondano più obiettivi o risultati.
In questo caso è sempre meglio separare più concetti in diverse storie, così da garantire maggiore facilità di elaborazione.

Esprimere il cosa, non il come

E’ fondamentale distinguere tra il cosa (il risultato atteso) ed il come (la soluzione adottata per raggiungere quel determinato risultato).
Il “come” è oggetto di elaborazione del team di sviluppo, non degli stakeholder.
Focalizzarsi sul risultato di business evitando di concentrarsi su come raggiungerlo ci consente di non arrivare a prospettare una soluzione troppo presto.
Pensiamo alla meta finale, non al viaggio.
Evitiamo premature decisioni tecnologiche e lasciamo al team l’onere e l’onore di individuare il modo più adeguato di soddisfare il bisogno.
Una user story che si focalizza sul “cosa” esprime maggior valore.
Per esperienza non è così semplice astrarsi dal “come”… meglio rileggere più volte ciò che è stato formulato.

Mantenere la rilevanza nei confronti del progetto

La user story è coerente con la finalità generale del progetto? E’ in linea con il project charter (se presente)? E’ sempre bene porsi questa domanda, perché troppo spesso nel backlog sopravvivono requisiti poco rilevanti o di nessuna utilità.
Una user story rilevante descrive funzionalità rilevanti per il progetto in termini di business, che non eccedono o sono al di fuori del suo scopo e che non creano effetti “a cascata”.
Mantenere solo le storie rilevanti fa risparmiare all’azienda tempo e denaro, oltre a sostenere la motivazione del team.

Evitare l’ambiguità

Dato che è difficile individuare formulazioni ambigue quando si è gli autori delle user story in prima persona gli autori ci suggeriscono di provare a cambiare prospettiva.
Tentiamo di metterci nei panni del lettore.
Proviamo a rileggere quanto abbiamo scritto in un contesto diverso, ad un’ora diversa del giorno.
Meglio ancora – se ne abbiamo la possibilità – chiediamo a qualcuno di riscrivere o riformulare la nostra user story mantenendone il significato ma utilizzando tutte parole diverse.
Questo trucco costringe l’interlocutore a pensare fuori dagli schemi.
Una volta che la “traduzione” è fatta verificheremo se le due storie coincidono nel significato. Se c’è aderenza la user story iniziale non presenta ambiguità; in caso contrario si disporrà di indicazioni preziose per riformulare la storia.
Il semplice atto di analizzare il modo in cui qualcun altro interpreta le nostre storie originarie offre preziosissime indicazioni.

Rendere misurabili i requisiti non funzionali

Non è sufficiente formulare il risultato che si vuole ottenere, dobbiamo poterlo esprimere in termini misurabili in modo da renderlo chiaro a qualsiasi tipo di pubblico.
Per sviluppare una soluzione che soddisfi i bisogni del richiedente gli sviluppatori hanno la necessità di avere requisiti funzionali e non funzionali espressi in termini misurabili (ricadono tra questi ultimi quelli relativi ad esempio a frequenza, urgenza, volumi, accuratezza, usabilità, flessibilità, scalabilità, affidabilità, ecc.).
Ricordiamoci che ciò che è oggettivamente misurabile può essere validata anche da terze parti.
Solo fornendo un requisito realmente misurabile saremo in grado – a lavoro terminato – di verificare il raggiungimento del nostro obiettivo.