Simyl
simylflow
Lezione 3 di 3
17 min

Backlog e Storie del Team

Come il lavoro fluisce dalle feature alle storie e come i team gestiscono i loro backlog nel contesto dell'ART.

1Dalle Feature alle Storie

In SAFe, il lavoro fluisce attraverso una gerarchia:

EpicFeatureStoria

  • Le Epic sono iniziative di grandi dimensioni che si estendono su più PI. Risiedono nel Portfolio Kanban e richiedono Lean Business Case.
  • Le Feature sono incrementi di funzionalità che forniscono valore all'utente. Risiedono nel Program Backlog e sono dimensionate per rientrare in un singolo PI. Il Product Management è responsabile della priorità delle feature.
  • Le Storie sono piccoli pezzi di lavoro implementabili che un team può completare all'interno di un'iterazione. Risiedono nel Team Backlog. Il Product Owner è responsabile della priorità delle storie.

Il flusso di decomposizione: il Product Management suddivide le epic in feature durante il PI Planning. I Product Owner suddividono le feature in storie durante la pianificazione dell'iterazione (e le sessioni di refinement).

Le buone storie seguono i criteri INVEST:

  • Indipendenti — Possono essere sviluppate senza dipendere da altre storie
  • Negoziabili — I dettagli vengono discussi, non imposti
  • Valuable (di valore) — Forniscono un chiaro valore all'utente o al sistema
  • Estimabili — Il team può stimare lo sforzo
  • Small (piccole) — Rientrano in una singola iterazione
  • Testabili — Criteri di accettazione chiari

2Enabler

Non tutto il lavoro fornisce valore diretto all'utente. Gli Enabler sono storie (o feature, o epic) che costruiscono le fondamenta tecniche per capacità future.

SAFe definisce quattro tipi di enabler:

Enabler architetturali: Costruiscono la runway architetturale—servizi condivisi, API, infrastruttura di cui le feature future avranno bisogno. Esempio: configurare un sistema di code di messaggi prima di costruire feature event-driven.

Enabler infrastrutturali: Configurano l'infrastruttura di sviluppo, test e deployment. Esempio: creare una pipeline CI/CD, configurare il monitoraggio, fornire ambienti.

Enabler esplorativi: Investigano opzioni e riducono l'incertezza. Esempio: prototipare due approcci diversi per vedere quale performa meglio, spike story.

Enabler di conformità: Soddisfano requisiti normativi o di policy. Esempio: implementare audit logging, crittografia dei dati o standard di accessibilità.

Gestire gli enabler nel backlog:

Gli enabler competono per la capacità con le storie di feature. Un team in salute dedica approssimativamente:

  • 70-80% alle storie di feature (consegna di valore diretto)
  • 20-30% agli enabler (runway architetturale, debito tecnico, infrastruttura)

Questo rapporto non è rigido—dipende dalla maturità del sistema. I nuovi prodotti necessitano di più lavoro enabler; i prodotti maturi possono orientarsi verso le feature. La chiave è rendere visibile il lavoro enabler piuttosto che nasconderlo.

Rendi Visibili gli Enabler

Non nascondere mai il lavoro enabler all'interno delle storie di feature. Quando l'investimento tecnico è invisibile, è la prima cosa che viene tagliata sotto pressione. Storie enabler separate forzano conversazioni esplicite sull'equilibrio tra presente e futuro.

3Pianificazione della Capacità e Commitment

Durante la pianificazione dell'iterazione, i team determinano quanto lavoro possono impegnarsi a completare:

Capacità = membri del team disponibili × ore al giorno × giorni nell'iterazione, meno riunioni e interruzioni note. I team apprendono la loro capacità effettiva attraverso l'esperienza—è una misura empirica, non un calcolo.

Gli Story point stimano la complessità relativa. I team si calibrano nel tempo. La metrica chiave è la velocity—la media degli story point completati per iterazione. La velocity si stabilizza dopo 3-4 iterazioni e diventa uno strumento di pianificazione affidabile.

Commitment nel contesto SAFe:

I commitment del team in un'iterazione si allineano con i PI Objective stabiliti durante il PI Planning. L'obiettivo dell'iterazione dovrebbe mappare il progresso su uno o più PI objective. Questo crea un allineamento tracciabile dal lavoro del team al valore del programma.

Quando i team scoprono a metà iterazione di non poter rispettare un commitment:

  1. Comunicare immediatamente (trasparenza)
  2. Lavorare con il PO per adattare lo scope (negoziazione)
  3. Escalare all'RTE se impatta altri team (coordinamento)
  4. Non sacrificare mai la qualità per rispettare una data (qualità integrata)

La misura di prevedibilità: SAFe traccia quanto bene i team consegnano i loro PI objective. Non si tratta di punire i mancati obiettivi—si tratta di migliorare l'accuratezza di stima e pianificazione nel tempo. Un team che consegna in modo affidabile l'80% degli obiettivi è più prezioso di uno che promette il 100% e consegna in modo imprevedibile.

Punti Chiave
  • Il lavoro fluisce da Epic → Feature → Storie, con ogni livello gestito da ruoli diversi
  • Gli enabler (architetturali, infrastrutturali, esplorativi, di conformità) costruiscono la runway tecnica
  • I team in salute allocano il 20-30% della capacità al lavoro enabler
  • La prevedibilità conta più dell'overcommitment eroico