Don’t dirty my Backlog: an implementation with Azure DevOps & Office 365

Nei due precedenti post sull’argomento (post1, post2) si è parlato dell’opportunità di avere un Basketche consenta di raccogliere in modo “informale” le diverse richieste provenienti dagli stakeholder. 

Lo scopo ultimo è quello avere un Healthy Product Backlog, ovvero un Product Backlog in salute. 

In questo ultimo post dedicato all’argomento si farà riferimento ad una possibile implementazione del tutto tramite tool digitali, nello specifico: Azure DevOps (ex TFS) e la suite Office 365

Con Azure DevOps è possibile supportare l’intero ciclo di sviluppo di un prodotto, e in particolare il Product Backlog che rappresenta l’elemento di riferimento per gestire cosa realizzare in funzione del Valore del prodotto specifico.

basket azure 1

Azure DevOps Product Backlog

Quello che però interessa nello specifico è, ovviamente, come implementare fattivamente il Basket. Se si decide di utilizzare esclusivamente Azure DevOps, è possibile sfruttare il concetto di Area Pathper crearne una nuova specifica che rappresenti proprio il nostro Basket. 

basket azure 2

Creare una nuova Area Path

In tal modo, i Basket Item(che possono essere creati sfruttando gli item generici già forniti dallo specifico template oppure creandone di personalizzati) sono gestiti all’interno della stessa piattaforma a cui si è affidiato il Product Backlog, e dopo il necessario refinement possono essere spostati con un semplice ricollocamento nella specifica area di riferimento. 

basket azure 2b

 Spostamento degli Item

Questa scelta, però, porta con sé alcune limitazioni, tra cui quella più evidente è la difficolta nel raccogliere informazioni non strutturate, spesso quelle primarie con cui ci si confronta quando si comincia a parlare con gli stakeholder delle nuove funzionalità. A questa si lega anche un possibile side-effect metodologico: si rischia di non gestire correttamente la fase di promotion (si veda qui) da Basket Item a Product Backlog Item, spostando frettolosamente un basket item nel Product Backlog solo perché “è facile farlo”.

Una possibile alternativa è quella di utilizzare per il Basket una serie di strumenti di Office 365OneNote/Teams/Planner, per effettuare il gathering delle informazioni(OneNote), discuterne e arricchirle costantementedi dettagli al fine di renderle consistenti (Teams) e avere un primo raggruppamento con annessa priorità(Planner).

basket azure 3

 

OneNote

basket azure 4

 Teams

basket azure 5

Planner

Solo a questo punto il Basket Item, convalidata la Definiton of Ready(DoR), può essere effettivamente promosso a Backlog Item in Azure DevOps, con la creazione (manuale o, eventualmente, automatizzata attraverso un tool custom) del relativo PBI, generalmente EpicFeature.

Ovviamente, in questo caso è necessario interagire con strumenti diversi, creando eventualmente connettori per trasferire informazioni tra di loro per evitare di duplicarne l’inserimento.

Si conclude qui questa miniserie di post in cui si è dato uno sguardo all’opportunità di avere un Basket per gestire in modo proficuo le decine di richieste che possono costantemente provenire dagli stakeholder, dedicando loro la dovuta attenzione ma preservando la “salute” del Product Backlog.

 

Stay tuned J

Comments are closed.