xebir logo mvp orizzontale psm1 small  cdacda consortium  safe sixsigma yellow belt mini  mcpd shortless cert agileiot logo  ac2 logo

Don’t dirty my Backlog: flow/no-flow

Si è cominciato a parlare (si veda qui) dell’importanza di preservare la consistenza del proprio Product Backlog, facendo si che esso rispecchi le effettive esigenze di prodotto onde evitare che diventi un “accumulo” di decine e decine di richieste che poi si perdono al suo interno.

Il Basket, proposto come contenitore di “draft item”, è al centro di una precisa strategia:

  • Vengono raccolte le informazioni da ogni fonte disponibile e meritevole di attenzione
  • Viene eseguito il refinement delle informazioni per ottenere degli Item consistenti
  • Vengono spostati gli item nel Product Backlog

3phases

 

La raccolta delle informazionida parte dei diversi stakeholder è un’attività continua che trova nel Product Owner il riferimento operativo e che si può realizzare sfruttando gli strumenti più disparati: dalla comunicazione diretta a soluzioni di change request management

La cosa fondamentale è la capacità di aggregarele richieste guardando oltre la specifica singolarità, in modo da creare featureche portino ad un mutuo beneficio tra le parti, sottoponendole continuamente ad un refinement che consenta di ottenere item lavorabiliche non siano dei banali placeholder. 

Qui nasce la necessità di definire con chiarezza che cosa significhi “item lavorabili”, per il contesto specifico, per l’iniziativa e per il team, stabilendo una specifica Definiton of Ready(DoR) per abilitare il flow/no-flowfunnel che porta un Basket Item ad essere promosso a Product Backlog Item.

flow noflow

Come sempre bisogna fare molta attenzione alla DoR: una sua specifica troppo estremapuò portare ad allungare in modo irragionevole i tempi, perdendo di vista l’importanza applicativa del Cono di Incertezzae provando a rendere “perfetto” qualcosa che “by definition” non può esserlo nei sistemi complessi. Dualmente, una DoR troppo superficialeporta ad avere item che sono tutt’altro che pronti ad entrare nel Product Backlog e che porterebbero solo ad “aumentarne il peso” senza dare un contributo apprezzabile al valore complessivo.

Quando un Basket Item soddisfa la DoR e viene promossoin un Product Backlog Item, entra di diritto nella “lista delle cose da fare”, anche se questo, come è ben noto, non da certezza che verrà realizzato, ma solo che è “meritevole” dell’attenzione dell’intero team. 

Guai a pensarla diversamente: si ricadrebbe nel “tranello” di effettuare una elicitazione completa dei requisiti, perdendo la capacità di operare dinamicamente rispetto ai cambiamenti e di adattarsi alle evidenze piuttosto che seguire un piano.

Stay tuned J