Come il lavoro fluisce dalle feature alle storie e come i team gestiscono i loro backlog nel contesto dell'ART.
In SAFe, il lavoro fluisce attraverso una gerarchia:
Epic → Feature → Storia
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:
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:
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.
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:
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.