Sì è vero: in qualche post fa abbiamo già accennato al Product Backlog. Oggi faremo però un passo avanti, scoprendo insieme molto di più. Toccheremo l’argomento da vari punti di vista: quali? Vedremo cosa è nello specifico il Product Backlog, cosa contiene, faremo degli esempi, insomma lo conosceremo da vicino. Ma andiamo con ordine.
Product Backlog, cosa è.
“Disporre le cose in ordine di priorità secondo il valore fa in modo che le persone producano prima quel 20%. Spesso quando hanno finito si rendono conto che non hanno bisogno veramente del restante 80, oppure che quello che sembrava importante all’inizio non lo è più.”
Product Backlog, le caratteristiche principali.
È un documento vivo: ogni giorno il Product Backlog viene aggiornato e modificato dal Product Owner attraverso un'attività che prende il nome di Backlog Refiniment, di cui vi parleremo più avanti.
Il documento è sempre prioritizzato. Nella lista gli elementi sono indicati in ordine di priorità: quelli più alti sono più dettagliati rispetto a quelli in basso. Perché accade ciò? Perché più un elemento starà in alto più sarà alta la probabilità che questa sia sviluppato pertanto ha bisogno di tutti i dettagli possibili per passare in produzione.
Tutti gli elementi devono aggiungere valore all’utente finale: il Product Backlog non è una semplice lista di to do.
Non esiste una rappresentazione standard del Product Backlog.
Il Product Owner è responsabile del Product Backlog e deve aggiornarlo costantemente. Il Product Backlog rappresenta ciò che verrà sviluppato e implementato per apportare valore al prodotto e alla sua usabilità. Il Product Owner insieme al team e agli stakeholder popola il Product Backlog.
Product Backlog, cosa contiene.
Il Product Backlog contiene quattro tipologie di elementi:
Le User Story: sono delle brevi e chiare descrizioni narrative dei task, delle funzionalità, costruite su ciò che immaginiamo l’utente possa fare durante l’interazione con il prodotto. (se te lo fossi perso, torna un post indietro e approfondisci le User Story)
I Bug: sono dei comportamenti inaspettati del software che portano al suo malfunzionamento. Tipicamente sono causati da errori nella scrittura del codice sorgente di un programma. A causa dei bug l’utente non può completare facilmente un’azione: ciò è strettamente correlato al valore del prodotto (basso in presenza di bug). Ecco perché sono presenti nella Product Backlog: il Team deve lavorarci per migliorare l’usabilità del prodotto, impiegando e consumando anche molte ore per correggere gli errori ed eseguire quindi il bug fixing.
Knowledge Acquisition: la conoscenza acquisita è più importante di quello che pensi. Fermati un attimo a pensare: come fai ad agire senza conoscere? Ecco la Knowledge Acquisition è tutto ciò che tu devi imparare, sperimentare e fare prima di iniziare qualcosa di nuovo. La conoscenza acquisita quando è direttamente rivolta all’User, quindi all’utente, viene chiamata Product Discovery e comprende tutti quei processi che hanno il loro goal nella riduzione del rischio di insuccesso nello sviluppo del prodotto. Si parla invece di Spike quando i task svolti per creare la Knowledge Acquisition sono prettamente tecnici: ad esempio si scrive del codice solo per sperimentare, integrare, per carpire che tecnologia utilizzare.
Tech Task: basta un esempio per capire di cosa (purtroppo!) si tratta :)! Chi di voi non ha mai dovuto combattere con la migrazione dei server? Ecco i Tech Task sono proprio quelle attività che cerchi sempre di rinviare perché non aggiungono valore al prodotto ma consumano molto tempo per il Team. Sono attività essenziali però per far vivere nel tempo il prodotto. Non rimandarle!
Backlog Refiniment.
Tutti gli elementi presenti nel Product Backlog devono aggiungere valore all’utente del nostro prodotto. E tutto ciò che verrà fatto per l’utente di quel prodotto deve necessariamente passare per il Product Backlog. È fondamentale avere sempre tutto chiaro, dai task, alle risorse fino al tempo impiegato dal team.
Il Product Backlog deve rispecchiare la verità. Come? Il Product Owner deve dedicare cura e tempo al Product Backlog mantenendolo sempre in ordine, assicurandosi che gli elementi siano prioritizzati e arricchiti di tutti i dettagli necessari per poi passare al Delivery (in Kanban) o Sprint Backlog (in Scrum).
Questa attività di controllo e ordine del Product Backlog viene chiamato Backlog Refiniment e può essere fatta o solo dal Product Owner, o insieme a tutto o una sola parte del team. Quali sono le cose più comuni che vengono fatte durante un Backlog Refiniment?
Tutti gli elementi vengono riordinati e prioritizzati, rimuovendo le user story non più rilevanti.
In base ai bisogni emersi, saranno create nuove user story.
Tutte le user story, sia le neo che quelle già presenti nel Product Backlog, saranno stimate: cosa significa? Verranno assegnate delle story point ovvero si assegna un punteggio alla storia in base alla sua complessità. Lo story point può essere rivisto in fase di Backlog Refiniment.
Le user story più grandi sono chiamate Epics e vengono scomposte in user story più piccole per essere portate in sviluppo.
Sprint Backlog e Task in Scrum.
Lo Sprint Backlog è una parte di Product Backlog, quella che contiene tutte le story da portare in Sprint per raggiungere l’obiettivo. All’inizio di ogni Sprint avviene lo Sprint Planning: il team si riunisce in un meeting, si individuano gli item da portare in sprint, si creano e assegnano i task, si lavora.
Product Backlog, come organizzare il template.
La comunicazione all’interno del team è fondamentale pertanto il Product Backlog deve essere organizzato e mantenuto ordinato nel tempo. Come organizzare il documento? Componi la tua griglia e inserisci nelle tue colonne:
ID: il numero che identifica l’item a cui è correlato.
ITEM: elemento da portare in sviluppo.
CATEGORIA: in base alla tipologia dell’iter si può parlare di Epic, User Story o Tech Task ad esempio.
AREA o TEAM: a chi è assegnato item.
STORY POINT: che peso ha la storia.
PRIORITÀ: assegnare priorità all’item per pianificare il lavoro e svilupparlo in base alla sua priorità.
DEPENDENCIES: identificare le correlazioni e le dipendenze tra gli item è importante per capire cosa è necessario sviluppare prima.
ACCEPTANCE CRITERIA: criteri che il prodotto deve presentare per essere accettato.
STATUS: fatto o da fare.