I grafici di burndown o burnup mostrano quanto lavoro è stato completato e quanto lavoro rimane mentre l'iterazione procede.
I grafici Burndown e Burnup presentano gli stessi dati in modo diverso. Le squadre scelgono come vogliono vedere i loro dati.
Alcuni team combinano i grafici di burndown e burnup in un unico grafico. Il grafico mostra gli story point effettivi rimanenti così come gli story point cumulativi completati.
Planned versus Actual Velocity è uno strumento di previsione basato sulla performance osservata ed effettiva. Il team può dire al cliente se finirà il backlog delle user stories entro il numero previsto di iterazioni o no.
Planned vs. actual velocity è uno strumento predittivo basato su osservazioni e prestazioni effettive. Permette al team di dire al cliente se completerà il backlog delle user stories prima del numero pianificato di iterazioni.
Il velocità pianificata è l'aspettativa del team sui punti della storia da consegnare in ogni iterazione. Velocità effettiva si riferisce alla somma effettiva dei punti storia che hanno consegnato in ogni iterazione.
Il diagramma del parcheggio rappresenta il progresso di un team nel completare i punti della storia per un rilascio.
L'informazione visiva del parcheggio è utile per la localizzazione e la diagnosi.
La legge di Little afferma che la dimensione di una coda (il numero di articoli in stato WIP) è proporzionale alla durata del tempo nella coda. Pertanto, l'obiettivo di Lean e Agile è di ridurre i tempi di ciclo al minimo.
I limiti WIP impediscono al team di prendere troppo lavoro e rivelano i colli di bottiglia. Le squadre ottengono il loro lavoro più velocemente limitando la quantità di Work-in-Progress.
La relazione tra WIP e tempo di ciclo è espressa dalla seguente equazione
Work-in-progress (WIP) = Lead Time * Throughput
Il Lead time di un processo è uguale al numero di lavori da eseguire diviso per il tempo medio di esecuzione di ogni lavoro
Le schede Kanban sono schede di segnalazione. Kanban (giapponese - "carte che puoi vedere") è un sistema pull in cui le risorse impediscono al lavoro di accumularsi in un processo limitato in modo che il tempo di consegna del valore al business non sia compromesso. Il lavoro nella lavagna Kanban si muove da sinistra a destra e solo un numero limitato di elementi può essere in ogni fase del progetto. I team sono disciplinati e impegnati a lavorare entro i loro limiti di Work-in-Progress (WIP) specificati per assicurare un flusso ottimale nel sistema.
Il lead time indica quanto tempo ci vuole perché un elemento di lavoro passi attraverso l'intero processo. Il tempo di ciclo è un sottoinsieme del lead time. Il tempo di ciclo è il tempo necessario ad un elemento di lavoro per passare attraverso una parte del processo (ad esempio, lo stato In Progress to Done, dalla fase di codifica alla fase di test, completare un compito).
Ci sono diverse strategie per i problemi di lead time e cycle time, come aumentare l'efficienza del sistema, aumentare la capacità (crash), e smettere di prendere i requisiti (non sempre possibile).
Il Diagramma di flusso cumulativo (CFD) è uno strumento per tracciare le prestazioni del flusso di lavoro. CFD visualizza la relazione tra il Work-in-Progress (WIP) e il lead time. I team possono usare il CFD per identificare facilmente i colli di bottiglia.
Il throughput è il numero di articoli che un sistema può consegnare in un dato lasso di tempo. Ci si aspetta che un sistema con un alto rendimento sia più reattivo alle esigenze dei clienti.
Il rendimento è uguale al WIP diviso per il tempo di ciclo.
Il takt time è definito come la velocità alla quale un team dovrebbe mettere il software in produzione per soddisfare i requisiti del cliente.
Il takt time (tedesco - Taktzeit) permette di misurare la produttività attuale del processo di consegna in relazione alla domanda del cliente.
Takt time = tempo disponibile per la produzione / unità richieste (domanda del cliente)
Il tempo di Tackt può essere paragonato al tempo di ciclo, permettendo al team di identificare le attività non a valore aggiunto e raggiungere un flusso continuo di valore per il cliente.
I test di accettazione sono scritti prima dello sviluppo di nuovi prodotti (sul retro delle story card). Assicurano che il codice soddisfi i requisiti. Per il software, i test iniziali falliranno perché il codice non è ancora completamente sviluppato. Se il codice è scritto correttamente, passerà i test.
Più alto è il tasso di successo nei test, maggiore è la probabilità che non ci sia un fallimento nella produzione.
I difetti sfuggiti sono i difetti che sono sfuggiti al team di test. Il tasso di difettosità misura quanto spesso i difetti vengono trovati. I difetti sfuggiti sono i più costosi da correggere. Un aumento dei difetti sfuggiti segnala che un processo è difettoso.
La velocità è una misura di quanto lavoro (somma dei punti delle storie fatte) una squadra può fare per iterazione.
La velocità è utile per prevedere quanto lavoro può essere fatto nelle iterazioni future. La velocità cambia e dovrebbe essere misurata alla fine di ogni iterazione. Vale la pena notare che la velocità dei team non può essere paragonata poiché il dimensionamento e la stima in ogni team varia dagli altri.
Il calcolo della velocità iniziale affronta il problema della "partenza a freddo", e può essere fatto come segue: - basandosi su dati storici di precedenti progetti simili, - eseguendo alcune iterazioni e poi calcolando la velocità, - o basandosi sul giudizio degli esperti.
Agile Metrics e KPI'ss hanno un livello fondamentale di comprensione dell'integrazione delle pratiche di marketing in SMART Agile.
La certificazione "SMART Product Owner" dimostra un livello distinto di comprensione di come possedere una visione, gestire un Product Backlog e impegnarsi con le parti interessate e i clienti per consegnare prodotti di valore usando Scrum in impostazioni di scala.
I generalisti SMART Agile certificati hanno conoscenza e comprensione del ruolo di Development Team Member in Agile.
Agile Metrics and KPI'ss sa come usare SMART e le sue metriche per ispezionare, adattare e ottimizzare in modo efficiente lo scaling agile per un uso ottimale delle risorse e una rapida consegna del valore.
L'imprenditore certificato SMART sa come usare SMART Agile per migliorare la creazione di valore e la consegna su scala.
