Molti avranno sentito parlare degli “Spike” aggiunti al backlog come user story. Si tratta di una pratica derivata dall’Extreme Programming (XP) nella quale si individua una attività che necessita di ulteriori approfondimenti rispetto a quanto preventivato. Questo può quindi portare ad una revisione dei lavori in corso d’opera. Grazie all’uso degli Spike è possibile mantenere sotto controllo anche queste revisioni volanti. Ma quando e dove è corretto usarli?
Se leggiamo la documentazione di Scrum non troviamo alcun riferimento agli Spike, eppure molti Scrum Master e Product Owner ne fanno largo uso. Se, invece, andiamo a vedere le specifiche SAFe allora troviamo un’intera pagina dedicata all’elemento all’interno della sezione “Advanced Topics” (Spike in SAFe) nella quale notiamo due diverse tipologie di Spike: Functional e Technical (rimando alla documentazione per averne tutti i dettagli).
Ma allora questi Spike devono essere utilizzati o no? La risposta, come sempre, è: dipende!
Personalmente, se utilizzo Scrum preferisco evitare gli Spike all’interno del Product Backlog e ne giustifico la presenza solo negli Sprint Backlog a fronte di una effettiva necessità del team di aggiungere una attività di sperimentazione, test o approfondimento che non era stato possibile identificare a priori con una classica User Story.
Inoltre, anche quando il framework lo consente, cerco sempre di guidare il team in una fase di analisi degli item del Product Backlog preventiva che tenga conto di tutte quelle attività di “ispezione” necessarie alla corretta sperimentazione. In questo modo il team è in grado di identificare e pesare, con l’aiuto del Product Owner, quelle User Story di ispezione che vanno inserite nello Sprint Backlog, siano esse funzionali sia tecnologiche, senza bisogno di ricorrere agli Spike.
Evito del tutto l’utilizzo degli Spike come intermezzi tra gli Sprint. Anche se time-boxed generano un profondo disallineamento, soprattutto se stiamo lavorando con diversi team agili che seguono la medesima finestra di Sprint.
Generalmente uno Spike si differenzia da una User Story poiché non genera direttamente reale valore per l’utilizzatore finale. Ecco dunque che sembra ricadere nella classica definizione di “requisito”. Prestiamo dunque molta attenzione nell’utilizzo indiscriminato degli Spike, se ce ne sono troppi vuol dire che non stiamo producendo reale valore!
In ogni caso, ecco il suggerimento conclusivo: definite con il team all’inizio del vostro progetto se e come volete utilizzare gli Spike. Cercate poi di rimanere aderenti alla vostra scelta e se vorrete modificarla prestate molta attenzione nel mantenere sempre la produzione di valore e il contenimento degli sprechi le vostre priorità.
Buona produzione di reale valore a tutti!
--- post 1/52/20 ---
Agile in azione, anche nella vita reale! 