Categoria: Scrum

Pubblicato il

Le buone user stories sono INVEST

L’acronimo INVEST creato da Bill Wake nel 2003 è un trucco che i Product Owner possono utilizzare per ricordare le qualità di una buona user story.
Cosa significano le iniziali? Semplicissimo!

Indipendent – Indipendenti

Quando le user stories non sono indipendenti tra loro possono produrre stime non corrette, vincoli di implementazione e potenziali rigidità nella pianificazione dei rilasci.
L’ideale è segmentare le storie in modo tale che possano essere implementate secondo qualsiasi ordine (qui ho parlato dei criteri di suddivisione).

Quando ci troviamo di fronte a delle dipendenze possiamo provare alcune soluzioni alternative:

  • combinare insieme le storie interessate (purché si possano concludere in uno sprint)
  • suddividerle in una maniera differente
  • segmentarle in storie più piccole.

Quando proprio non è possibile scrivere user stories indipendenti è meglio definire un ordine di implementazione e fornire stime differenti per la prima storia e le successive (ad esempio 3 punti per la prima e 1 per le successive).

Negotiable – Negoziabili

Una delle qualità più apprezzabili delle user stories – dal mio punto di vista – sta nel fatto di non essere contratti scritti nella pietra una volta per sempre.
Le storie sono brevi descrizioni delle funzionalità desiderate. Catturano l’essenza di una richiesta, non le specifiche di dettaglio.

In Scrum la definizione dell’ambito di una storia (il cosidetto “scope”) non è come nel processo waterfall appannaggio esclusivo del project manager; i dettagli sono negoziabili e vengono negoziati perché emergono dai dialoghi tra il cliente, il product owner e il team.

La user story è un invito a conversazioni future.

Valuable – Di valore

In un mondo ideale tutte le storie sono di valore per l’utente finale; nella realtà non è sempre così, ma è utile tenere a mente questa aspirazione e interrogarsi sul vero beneficiario della user story (a volte può essere il cliente che paga lo sviluppo software, il committente interno, lo sponsor, il reparto vendite o altri tipi di stakeholder).

L’importante è evitare di perdere tempo (e soldi) in storie che non solo di valore per nessuno e provare a ricercare benefici “spendibili” anche nelle storie tecniche.

Estimable – Stimabili

Dal momento che Scrum prevede iterazioni time-boxed che siano autoconclusive, la stima di una storia e del tempo necessario per produrla è un’attività fondamentale nel team.
Quando la valutazione risulta difficile siamo solitamente di fronte ad uno di questi problemi:

  1. gli sviluppatori non conoscono perfettamente il dominio e non si sentono confidenti nel dare una stima iniziale
  2. hanno una conoscenza parziale della tecnologia da utilizzare
  3. oppure le storie risultano troppo grandi o poco chiare.

Nei primi due casi si può cominciare a programmare un’attività di analisi da parte del team (una spike) per arrivare a una stima sufficiente dell’ordine di grandezza delle attività; negli altri è il Product Owner che deve farsi carico di segmentare di più le storie e dettagliare maggiormente i criteri di accettazione.

Size appropriately or Small – Della giusta dimensione

La dimensione giusta è “quanto basta”… e come nelle ricette di cucina si migliora con la pratica, perché non è sempre evidente a cosa corrisponda il fatidico q.b.
Una cosa è certa: se le storie sono troppo piccole o troppo grandi ve ne accorgerete!
Il team non mancherà di farvelo notare già in fase di refinement, quando potrebbero sorgere problemi nella stima.
Anche in questo caso bisognerà dividere le storie tanto grosse da non poter entrare in uno sprint (di solito sono epiche nascoste!) o combinare più user stories affinchè l’effort complessivo comporti almeno una mezza giornata di lavoro.

Testable – Testabili

Al termine di ogni sprint vengono rilasciate delle funzionalità che sono “done” e dev’essere possibile dimostrare al cliente finale questo stato “finito”.
Ecco perché nella user stories non possono mancare criteri di accettazione effettivamente misurabili, ognuno dei quali possa poi essere misurato attraverso i test.
Quando i test passano (proviamo ad automatizzarne il più possibile) dimostriamo che le storie sono complete.

INVEST!

Ovvero user stories indipendenti, negoziabili, di valore, stimabili, della giusta dimensione (né troppo piccole né troppo grandi) e testabili.

L’articolo originale di Wax si intitola INVEST in Good Stories and SMART Tasks.

Pubblicato il

L’80/20 applicato al Backlog

Cosa succederebbe se provassimo ad applicare il principio di Pareto (la famosa regola dell’80/20) al nostro backlog? E’ questa la riflessione a cui ci invita Stefan Haas – Agile coach con molti anni di esperienza sul campo – in uno degli ultimi articoli del suo blog.

Siamo in grado di individuare quel 20% di funzionalità che producono l’80% della soddisfazione dei nostri utenti finali? Abbiamo idea di quali siano l’80% dei requisiti che producono scarso o nullo valore per i nostri clienti?
Al di là della provocazione, sappiamo per esperienza che non tutto ciò che è contenuto nel backlog è realmente di valore per l’utente e – nonostante ciò – è nostro compito trovare spazio anche per diversi tipi di attività – ad esempio – di aggiornamento dei sistemi, business intelligence o per adeguamenti di legge.

E’ in ogni caso interessante fermarsi a riflettere sull’opportunità di individuare ed avere sempre ben presente quel 20% di funzionalità che rappresentano il cuore dei nostri prodotti, quel 20% di un’epica (poi suddivisa in user stories) che ne rappresenta l’essenza, quel 20% di attività quotidiane del team che produrrà il maggior valore nel corso dell’iterazione.

Il principio può essere infatti applicato a tutti i livelli: al prodotto nel suo insieme, alle epiche, alle singole user stories o – segmentando ancora di più – ai task.
La sfida è individuare quel 20% critico del backlog in grado di produrre l’80% del valore finale e  mettere in priorità queste attività focalizzando l’impegno del team soprattutto su di esse.

Pubblicato il

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.

Proudly powered by WordPress