Il Product Backlog è un elenco ordinato e evolutivo di tutto il lavoro ritenuto necessario dal Product Owner per creare, pubblicare, mantenere e migliorare un prodotto.
Ogni prodotto ha un solo Product Backlog, è in continua evoluzione grazie al feedback constante degli stakeholder e alle Sprint Review, gestito da un solo Product Owner.
Per rendere trasparente il Product Backlog, il Product Owner garantirà, tra le altre cose:
- Un ordine e una priorità nel contenuto: in modo tale da rispecchiare la sua visione
- Accessibilità al contenuto a tutto lo Scrum Team (e alle persone che lo richiedono in azienda)
- La comprensione condivisa del suo contenuto. Spesso, ad esempio, ogni elemento del Product Backlog avrà le seguenti informazioni: un titolo, una descrizione, criteri di accettazione, un valore aziendale, una stima della complessità.
commitment: PRODUCT GOAL
Il Product Goal descrive uno stato futuro del prodotto che può servire come destinazione per lo Scrum Team durante la pianificazione. Il Product Goal è visibile nel Product Backlog, è un obiettivo a lungo termine dello Scrum Team. Esiste un solo Product Goal in Scrum. Una volta raggiunto questo obiettivo ne verrà creato uno nuovo.
ADATTAMENTO DEL PRODUCT BACKLOG
Questo è fondamentale per massimizzare il valore del prodotto, ma cos’è esattamente questo adattamento?
- Ridare un ordine e una priorità ai contenuti, a seguito del feedback degli stakeholder in Sprint Review e di continuo
- Aggiunta di nuove idee
- Rimozione di idee obsolete che non si adattano più al Product Goal (e quindi non hanno più valore)
- Qualsiasi altra azione che renda il Product Backlog ordinato correttamente
IL VALORE È L’UNICO CRITERIO PER ORDINARE IL BACKLOG DEL PRODOTTO?
No. In effetti, il valore è un concetto soggettivo. Il Product Owner ordina il Product Backlog interagendo con gli Stakeholder. Altri parametri da considerare per ordinare il Product Backlog sono:
- Valore aziendale: il problema più urgente per gli utenti, un vincolo normativo, una funzionalità che nessun concorrente possiede, ecc.
- Il rischio: in Scrum il rischio non viene gestito, viene trattato per primo. Ciò ha un impatto sulla pianificazione
- La dimensione degli elementi del Product Backlog: gli elementi importanti e di valore superiore avranno una dimensione giudicata dai Developers realizzabile in uno Sprint
In nessun caso l’ordine è dettato dalla difficoltà di realizzazione. Il Product Owner tiene conto dell’opinione dei Developers, senza concentrarsi prima sul “facile da fare”, perché questo non corrisponde a massimizzare il valore.
QUALE LIVELLO DI DETTAGLIO DOVREBBE AVERE UN ELEMENTO DEL Product BACKLOG
Un livello sufficiente per consentire a tutti di comprendere e ricordare l’argomento da discutere, quando sarà il momento.
Ricorda uno dei quattro principi del Manifesto Agile: “gli individui e le interazioni più che i processi e gli strumenti”. Un elemento del Product Backlog, inizialmente, serve per contrassegnare l’idea non appena arriva e poi svilupparla quando diventa una “priorità”.
Non c’è bisogno di passare ore a scrivere specifiche dettagliate, in quanto si tratterebbe di una perdita di tempo ed energia che potrebbe essere dedicata ad argomenti di immediato valore per gli utenti.
L’attenzione si concentrerà sulla cooperazione di tutte le persone pertinenti sull’argomento al momento opportuno.
Vuoi andare oltre nella stima e nella pianificazione Agile? Il libro di Mike Cohn “Agile Estimating and Planning” è un buon inizio.
Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!
Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide. Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.
Tradotto dal francese da Denise Monreale, grazie!
