Il ruolo del 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).

Quali sono 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 diventare una risposta a queste necessità; 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).

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 “grooming”), 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.

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.

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

 

“Dreaming”, un intervento illuminante allo IAD 2013

Tra i vari interventi interessanti che sono stati presentati all’Italian Agile Days 2013 di Reggio Emilia (29 e 30 novembre) uno mi ha particolarmente colpita.

E’ stato l’ottimo speech di Andrea Provaglio intitolato “Dreaming“.

Non capita tutti i giorni di sentire il proprio lavoro paragonato alla dimensione del “sogno“.
Secondo l’autore i cicli di iterazione possono essere interpretati alla luce di un modello che contiene la dimensione del sogno (l’intento, la vision, il backlog stesso), dell’azione (la produzione, le competenze) e dell’ordine (i ruoli, le funzioni, le cerimonie).

Due, in particolare, sono le osservazioni che mi hanno fatto riflettere:

  1. la dimensione del sogno è una dimensione fluida, dove tutto è ancora possibile. Eppure troppo spesso i nostri backlog (che si iscrivono nella dimensione del sogno) rivelano una scarsa capacità di envisioning già in fase iniziale di progettazione
  2. Quale percentuale di sogni e di bisogni contiene il vostro backlog?
    Una certa quantità di bisogni, di defect fixing è del tutto naturale in un prodotto, ma qual è la soglia critica oltre la quale il sogno – ciò che porta reale valore all’utente finale – rischia di essere soffocato dagli obblighi e dalle necessità immediate?

Per non rischiare che i frammenti di sogno solidi che realizziamo ad ogni iterazione si rivelino irreali o – peggio – inutili, vi invito a farvi ispirare…

User stories efficaci: 5 regole per non sbagliare

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.