14 strategie per dividere gli elementi del backlog

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 sprintdiminuiscono 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”.

Photo by Bonneval Sebastien on Unsplash

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;
Photo by Amélie Mourichon on Unsplash

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.

Photo by Nathan Dumlao on Unsplash

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.