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…

 

Product Ownership: il gruppo su Linkedin

Come orientarsi nel ruolo di Product Owner?
Quali sono gli strumenti e gli skill più importanti per guidare con efficacia un gruppo di sviluppo?
Quali sono i principali problemi con cui dovrete confrontarvi in questa attività?
Cosa vi differenzia dagli altri profili “agili”?
Ma anche… sono solo o esistono altri Product Owner come me in Italia?
Se queste sono alcune delle domande che avete in mente un’altra risorsa può venirvi oggi di aiuto.

Su Linkedin è attivo da anni il gruppo “Lean Agile Italy”, che conta ormai più di 2.000 membri.
Al suo interno è stato creato un sotto-gruppo italiano espressamente dedicato alla Product Ownership.
Si tratta ancora di un piccolo nucleo di professionisti, ma posso garantirvi che è molto motivato a portare avanti discussioni ed approfondimenti su questo tema.

Una delle cose che ci unisce è la consapevolezza che su questo tema c’è ancora molto da dire, da scrivere e da condividere.
La letteratura Agile sull’argomento non è così estesa ed esaustiva, le competenze richieste sono variegate e difficilmente presenti in un’unica figura professionale, gli “scogli” che si possono incontrare esercitando questo ruolo sono numerosi e i dubbi che emergono sul campo ancora di più.

Da qui è nata l’idea di uno spazio di riflessione dedicato. E’ un’iniziativa nata a valle del PO Camp (per chi non sapesse di cosa si tratta ne ho parlato in questo post), ma è estesa a chiunque sia interessato a discutere il tema della Product Ownership.
Il gruppo è privato, ma chiunque può chiedere di essere ammesso ed è il benvenuto a portare il proprio contributo (essere un Product Owner non è un requisito obbligatorio!).

E’ un punto di partenza, ma ha tutte le caratteristiche per andare lontano. Se siete appassionati come me, vi invito ad andare a dare un’occhiata.

Una mappa per esperimenti Lean

Lean Experiment Map - Moves The Needle
Lean Experiment Map – Moves The Needle

 

Volete provare a testare velocemente l’idea di un nuovo prodotto, servizio o funzionalità? Pensate di avere trovato la soluzione ad un annoso problema per i vostri utenti?
L’Experiment Map può venirvi in aiuto!
Si tratta di uno strumento molto efficace per applicare nella pratica i principi Lean di sperimentazione, misurazione dei risultati e apprendimento discussi in un post precedente.

E’ opportuno adottare qualche accorgimento: la mappa deve essere stampata grande e possibilmente appesa in modo che sia visibile a tutto il gruppo di lavoro.
Gli step vanno seguiti nell’ordine in cui sono proposti:

  1. definizione dell’idea
  2. valutazione delle assunzioni
  3. formulazione di un’ipotesi
  4. creazione dell’esperimento
  5. registrazione dei comportamenti
  6. individuazione del target (ovvero metrica di successo)
  7. risultati
  8. analisi delle motivazioni e insight
  9. decisione relativa alla soluzione esplorata

Ad ogni passo registriamo i risultati. Un post-it è più che sufficiente per catturare appunti e idee.

Come si procede?
Vi racconto l’utilizzo che ne abbiamo fatto nel corso di un workshop sull’innovazione.
Supponiamo di partire da un problema specifico che i vostri utenti hanno evidenziato, ad esempio sul vostro sito web hanno difficoltà a trovare i prodotti a cui sono realmente interessati.
In un primo momento ogni persona ha a disposizione qualche minuto per elaborare le proprie personali soluzioni e scriverle su un post-it.
Le varie soluzioni vengono presentate a turno al gruppo di lavoro che sceglie collettivamente quella più promettente.

A questo punto si inizia a seguire gli step proposti nella mappa.
Inquadriamo bene il problema: dobbiamo definire chi ne è impattato (potrebbe trattarsi di diverse tipologie di utenti), qual è la situazione problematica che vogliamo risolvere e quale soluzione abbiamo scelto.
E’ importante fornire dettagli in questa fase ed essere il più concreti possibile.

In seconda battuta si analizzano – sempre in gruppo – le assunzioni che stanno alla base della nostra idea.
Ricordate? Cosa stiamo dando totalmente per scontato senza averne alcuna prova? E’ importante capire cosa non stiamo mettendo in discussione e classificare queste convinzioni sulla base di due variabili: la conoscenza e l’importanza.
Le assunzioni che risulteranno essere nel quadrante in alto a destra sono quelle determinanti e meno note, ovvero le idee che rivelatesi false potrebbero mettere totalmente in discussione la nostra proposta.

E’ proprio dall’assunzione più critica che partiremo per realizzare il nostro esperimento.
Facciamo un’ipotesi, proviamo a tradurre in una descrizione specifica e misurabile la nostra assunzione cruciale (ad esempio: se mostriamo agli utenti un prototipo della nuova landing page aumenteremo del 10% le entering visits).

Costruiamo quindi un esperimento. Dev’essere un test veloce e rapido, basato su un prototipo o un artefatto il più semplice possibile da realizzare. Non serve essere sofisticati! L’importante è testare l’idea (potremmo utilizzare un concierge mvp) e acquisire insight da parte dei nostri utenti (la finalità è l’apprendimento!).

Un consiglio fondamentale: evitate la tentazione del sondaggio.
Non ci interessa raccogliere un parere sulle azioni degli utenti bensì vedere i loro comportamenti all’opera. 
Vogliamo vederli interagire con un prototipo o un servizio sufficientemente realistico.
Per fare questo abbiamo bisogno di uscire dai nostri uffici e andare a incontrare queste persone. Ascoltarle, cogliere la comunicazione non verbale, sentire i loro pareri o osservarle in azione.
Un esempio? Non chiediamo se sarebbero disposti ad acquistare un determinato servizio, simuliamo che sia già operativo e verifichiamo se sono disposti a mettere mano al portafoglio.

Datevi un target, un numero di utenti che volete coinvolgere nell’esperimento e il numero di coloro che dovrebbero accogliere positivamente la vostra soluzione. Anche in questo caso è importante darsi dei criteri di successo.
Pronti? Partenza… via! Eseguite l’esperimento che avete formulato e raccogliete i risultati.
La vostra ipotesi è stata confermata?
Se sì, il risultato è andato oltre le aspettative? Quali altri insegnamenti avete raccolto sul campo?
Se l’esperimento ha avuto un esito negativo perché credete sia andato così? Cosa ha influenzato il risultato? Cosa vi hanno raccontato in merito i vostri utenti?

A questo punto – e solo a questo punto – siete pronti a prendere una decisione. Potete decidere di proseguire lungo la strada intrapresa approfondendo altri aspetti della soluzione. In questo caso reiterate il processo con un nuovo esperimento per affinare la vostra idea iniziale.

Se invece avete raccolto preziosi feedback degli utenti che vi hanno portato a riformulare l’idea iniziale potete creare un nuovo esperimento per validare queste modifiche.
C’è anche in caso in cui l’esperimento vi abbia rivelato senza ombra di dubbio che la vostra assunzione era totalmente sbagliata (a noi è capitato così!).
Consolatevi! Siete pronti per ripartire da capo lungo questo percorso con una soluzione tutta nuova senza avere buttato dalla finestra mesi di sviluppo per un prodotto/servizio che nessuno dei vostri utenti avrebbe mai adottato.

In termini di investimento il rapporto costo/beneficio dato dall’adozione di questo tipo di approccio è sconcertante (come abbiamo fatto senza finora?!).
Provatelo sul campo e fatemi sapere se anche per voi funziona così bene.

Non abbiate paura di sperimentare… provate a spingervi un po’ oltre e adottare una prospettiva differente. Chiedetevi “cosa cambierebbe di 10 volte il comportamento degli utenti?

Nota: un particolare ringraziamento a theleanapps.com, che mette a disposizione una variante dello strumento particolarmente interessante.