Nella vita di tutti giorni, come “Scrum master”, mi trovo a lavorare con tre team diversi, ognuno con caratteristiche, composizione, difficoltà e complessità da affrontare diverse, composti in totale da una ventina di persone.
Il nostro lavorare in team prevede una filosofia “Agile” orma da un pò di anni e “Scrum” è il framework che, al momento, troviamo più conforme alle nostre esigenze.
Una delle difficoltà trasversale a tutti i team che seguo e che ho visto durante il mio percorso, è il lavoro sul Product Backlog (PBI) e nello specifico scomporre gli elementi del PBI in storie più piccole.
A volte è molto difficile far capire alle persone e a volte, agli sviluppatori stessi, che lo sviluppo del software è intrinsecamente imprevedibile .
Quindi, se il lavoro per uno sprint contiene solo pochi elementi di grandi dimensioni, l’impatto di sottovalutare il lavoro anche su un singolo elemento avrà un impatto profondo sullo sprint. E poiché gli elementi più grandi tendono ad essere più difficili da stimare e comprendere, il potenziale per uno sprint fallito aumenta ulteriormente.
Sprint Backlog con molti elementi piccoli (funzionali) invece di pochi grandi, migliorano il flusso e riducono il rischio di fallire lo sprint, diminuiscono gli imprevisti e generano nel breve tempo valore per il cliente.
Christiaan Verwijs
Gli Scrum Team esperti impiegano tempo e sforzi per scomporre grandi PBI in storie più piccole. Ma questo viene fatto in un modo “just-in-time”. Questo processo di scomposizione del lavoro migliora la comprensione condivisa, aumenta l’accuratezza della stima e facilita il Product Owner nella definizione delle priorità del lavoro.
Ma non è facile farlo bene e richiede pratica per farlo “al volo”.
Fatta questa premessa per capire l’importanza di questo processo, ho trovato illuminante e utile l’articolo di The Liberetors che descrive 14 tecniche da mettere in atto per scomporre “al volo” grandi PBI in storie più piccole.
Le tecniche che descrivono sono:
- Fasi del flusso di lavoro
Quali passaggi esegue un utente? Tutti i passaggi sono necessari adesso? I passaggi possono essere semplificati per ora? - Regole aziendali
Quali regole si applicano a questa storia? Sono necessarie tutte le regole aziendali adesso? Possono bastare regole più semplici? - Flusso felice / infelice
Che aspetto ha il flusso felice / infelice? Tutti i flussi infelici sono necessari (adesso)? I flussi infelici possono essere semplificati (per ora)? - Opzioni di input
Quali piattaforme sono supportate? Sono necessarie tutte le piattaforme (adesso)? Alcune piattaforme sono più difficili da implementare rispetto ad altre? - Tipi di dati e parametri
Quali tipi di dati sono supportati e pertinenti? Quali sono le viste parametrizzate? Tutti i parametri sono rilevanti al momento? - Operazioni
Quali operazioni comporta la storia? Sono necessarie tutte le operazioni in questo momento? - Casi di test
Quali scenari di test vengono utilizzati per verificare questa storia? Tutti gli scenari di test sono rilevanti al momento? - Ruoli
Quali ruoli sono coinvolti in questa storia? Cosa possono fare i ruoli? Tutti i ruoli sono necessari adesso? - Compatibilità del browser
Quali browser devono essere supportati? Tutti i browser sono importanti a questo punto? - Ottimizza ora vs ottimizza in seguito
Quali ottimizzazioni possiamo pensare a (UX / UI)? Sono necessarie tutte le ottimizzazioni adesso? - Criteri di accettazione identificati
Il modo più semplice e naturale per scomporre una storia. - Parti difficili da implementare e alle parti più facili
Potrebbe essere difficile impostare una parte di funzionalità in un’interfaccia utente pesantemente progettata, ma farlo funzionare con una semplice interfaccia utente può essere facile e sufficiente per ora. Ancora una volta, si tratta di essere pragmatici e fornire valore aziendale; - Dipendenze esterne
A volte la funzionalità dipende da fattori esterni, come l’implementazione di un consumatore per un servizio web remoto. Questo può essere difficile, ma potrebbe non avere la massima priorità. - Requisiti di usabilità
Ciò include la funzionalità per sfogliare un elenco di record, rendere un sito Web leggibile per non vedenti o persone daltoniche o implementare breadcrumb; - Requisiti SEO
Come l’impostazione di pagine di destinazione dedicate per parole chiave specifiche, l’impostazione di obiettivi per Google Analytics o l’impostazione di sitemap XML;
Fino a che punto dividere?
Sarebbe utilissimo avere una regola matematica o la soluzione di questa domanda. Ma la risposta esatta non esiste. Ogni team deve trovare la sua dimensione.
L’esperienza di questi anni che ho accumulato e per il contesto dei team in cui lavoro, una storia stimata in Story Point sopra i 10 è ancora da dividere.
Preoccupazioni dei Team
Questa sono alcune delle resistenze che incontrato e incontro più spesso da parte dei team quando spiego l’importanza della divisone in item più piccoli.
- Ridotto valore aziendale degli articoli più piccoli
Ovviamente, gli item più piccoli avranno un valore aziendale ridotto rispetto a item più grandi. Ma lo scopo principale della scomposizione delle funzionalità è ridurre il rischio, aumentare il flusso e aumentare la quantità di funzionalità operative che possono essere riviste alla fine di ogni sprint. - Scomposizione delle funzionalità si traduce in più lavoro
Per un team, è spesso più facile e veloce continuare a lavorare su una parte di funzionalità finché non è completamente terminata. Scomporre in piccoli pezzi durante lo sviluppo di uno sprint sembra uno spreco. A volte tecnicamente è così, ma questo permette di isolare le fasi di una lavorazione, di testarla meglio e in ottica agile di testare continuamente il nostro lavoro e adattarlo in base al feedback che riceviamo e quindi evitare di sprecare tempo in funzionalità che verranno modificate più avanti (in base al feedback degli utenti, delle parti interessate, ecc.). - L’item non è divisibile
Molti team non “capiscono” immediatamente come scomporre le funzionalità. Di conseguenza non è raro incontrare una certa resistenza. Questo è comprensibile; provare cose nuove è difficile perché fa sentire le persone vulnerabili. Il modo migliore per affrontare questo problema è persistere e allenare delicatamente la squadra aiutandola a rompere i loro PBI.
