Il team sta valutando i punti della storia, gli affari vogliono tempo reale

Sono sicuro che questo non è un tema insolito. Abbiamo due team di scrum che stanno facendo un buon lavoro di stima delle storie degli utenti usando i punti della storia (le costellazioni del team attuale hanno solo circa 8 mesi, anche se i membri del team hanno diversi anni di esperienza di scrum). Ma è difficile per la parte aziendale dell'azienda relazionarsi con le storie degli utenti; vogliono unità di tempo effettive (o "una formula per convertire i punti della storia in ore") in modo che possano fare un piano per quando le cose saranno pronte ( "dobbiamo sapere quando possiamo dire ai clienti che la Funzione X sarà in produzione " ).

Io e i miei predecessori della mischia abbiamo ovviamente spiegato che "non esiste una relazione definita tra i punti della storia e il tempo reale" e che "i punti della storia vengono utilizzati per determinare quanto la squadra può adattarsi a uno sprint", e sono sicuro di poter indovinare quanto fossero soddisfatti di quella risposta. Vogliono ancora sapere, in tempo di calendario, quando arriveremo alla 27esima storia utente sul backlog.

In ogni caso, ho compilato alcune statistiche e le nostre stime SP si traducono in risultati di tempo reale molto diversi (misurati dal nostro software Scrum Board, che tiene traccia di quanto tempo trascorrono i biglietti nella colonna "lavorando su" ). Per le storie degli utenti 1-SP, c'è ovviamente un forte pregiudizio verso intervalli di tempo molto brevi (con l'occasionale esplosione), ma soprattutto per le storie 2-SP, sono ovunque: c'è un fattore 20 tra i completamenti "più veloci" e "più lenti". Per le storie 3, 5 e 8-SP, la diffusione è anche più di un fattore 2.

Ciò indica che (a) il team deve essere molto più coerente nella stima delle storie degli utenti di (che cosa dovrebbe essere) simile complessità, e (b) il team deve migliorare la propria accuratezza nei rapporti temporali (vale a dire ricordare di spostare i biglietti da "lavorando" quando sono in riunione, a pranzo o giocano a biliardino).

Ho in programma di migliorare sia (a) che (b) ma penso che non sia abbastanza, che il business si aspetti "maggiore concretezza" rispetto a ciò che queste iniziative produrranno.

Quali sono alcune buone strategie per placare il lato aziendale , in modo che non interferiscano troppo nel nostro modo di lavorare (ad es. Imponendo l'uso di un monitoraggio del tempo separato, che IMHO sarebbe stupido perché sarebbe comunque meno accurato di l'attuale tracciamento "automatico"), ma allo stesso tempo consentire loro di ottenere una certa concretezza per quando saranno fatte le storie?

(Storicamente, durante la pianificazione abbiamo suddiviso le storie degli utenti in elementi di lavoro che sono stati quindi stimati individualmente nel tempo di lavoro effettivo , ma ciò di cui sto parlando qui sono le storie degli utenti nel registro posteriore che non avranno quel livello di dettaglio o interruzione -giù.)

Aggiornamento: Il mio manager aveva la sensazione che ci fosse una sorta di distribuzione della curva a campana delle ore trascorse per ogni punto della storia, ma i dati che ho raccolto e i grafici che ha creato lo hanno completamente disabitato di questa nozione. :-)

Hai ragione, non esiste una formula per convertire i punti della storia in ore. Puoi ottenere una conversione senza perdite di metri in piedi e viceversa, ma non puoi dire che una storia in 3 punti richiederà X ore, quindi una storia in 5 punti richiederà Y ore (risolvi per Y).

HorusKol ha toccato questa parte successiva. La tua velocità di sprint come squadra può aiutarti con i risultati a lungo termine. Supponiamo che la tua squadra abbia 50 punti per sprint e che ogni sprint sia di 2 settimane. Quindi 50 punti per sprint moltiplicati per 50 settimane in un anno (supponendo che le persone prendano 2 settimane di ferie per le vacanze), la tua squadra attuale può fare un massimo di 2.500 punti in 12 mesi.

Quindi il business ti arriva con 170 punti di storie ed epopee. Dividilo per la velocità storica della squadra di 50 punti (una media di ogni sprint finora) e ottieni 3,4 sprint. Dal momento che stiamo facendo una stima, arrotondiamo fino a 4 sprint: 8 settimane. Due mesi, praticamente. Mi piace anche prendere gli ultimi 3-4 sprint e fare un'altra stima. Diciamo che la tua squadra negli ultimi 3 sprint ha fatto rispettivamente 53, 67 e 55 punti. Ciò equivale a 58 punti ish, che a quel ritmo è di 2,9 sprint, quindi sostanzialmente 3 sprint. Sembra che la tua sequenza temporale per quei 170 punti sia tra le 6 e le 8 settimane.

Dillo al business 2 mesi. Non dirglielo per 6-8 settimane, perché sentiranno solo "6 settimane". Non dirgli nemmeno 8 settimane, perché la maggior parte dei mesi ha circa 4,5 settimane e quando le persone sentono "4 settimane" pensano immediatamente "1 mese". Una volta che una stima raggiunge circa 4 settimane, diventa 1 mese. Quindi lavora tra mesi. Se colpisci un anno o più, allora onestamente non stimare quel lavoro. È inutile. Troppe cose possono cambiare in un anno.

Ho trovato che questo è un modo abbastanza preciso per convertire i punti della storia in ore ... beh, comunque.

Otterrai una variazione nel tempo necessario per completare le singole storie. Alcuni sviluppatori lavorano più velocemente di altri. Mettere tutti i punti della storia in una ciotola e accendere il frullatore per lavorare con le medie aiuta ad alleviare quelle incoerenze.

Oh, e non dimenticare la parte più importante:

Arrotondare. Sempre.

Probabilmente hai già una conversione intrinseca da punti della storia a stime del tempo - come decidi di aver scelto abbastanza lavoro per il tuo sprint? Probabilmente hai detto qualcosa del tipo "la squadra può gestire 20 (o 40 o qualunque cosa) punti a settimana". Dopo alcuni sprint, dovresti essere in grado di rivederlo in base al completamento - quindi ora sono 15 o 25 (o 35 o 50 o ...) punti uno sprint - questa è la velocità della tua squadra .

Per le storie degli utenti 1-SP, c'è ovviamente un forte pregiudizio verso intervalli di tempo molto brevi (con l'occasionale esplosione), ma soprattutto per le storie 2-SP, sono ovunque: c'è un fattore 20 tra i completamenti "più veloci" e "più lenti". Per le storie 3, 5 e 8-SP, la diffusione è anche più di un fattore 2.

Qualche variazione nel tempo per completare storie specifiche va bene nei valori dei punti - la velocità si occupa di quell'incertezza essendo una media rispetto alla storia recente.

Tuttavia, potrebbe essere necessario dare una lunga occhiata al modo in cui si assegnano i punti, in particolare quei 2 puntatori se si ottiene una fluttuazione così grande. Le attività con i punti più alti dovrebbero essere incerte (e dovrebbero essere suddivise) - ma le attività piccole come un 2 puntatore dovrebbero essere abbastanza coerenti.

Poiché tutte le attività assegnate allo stesso valore in punti dovrebbero richiedere uno sforzo simile, non ha senso che ci sia un intervallo di tempo tale da completare.

Quindi, guarda il puntatore 2 che ha impiegato più tempo nella tua retrospettiva. Perché qualcosa che probabilmente avrebbe dovuto prendere una mattinata si è trasformato in uno slog di 10 giorni? Potrebbe essere stato segnalato qualcosa quella prima mattina per dire "questo deve diventare ed epico e spezzato in compiti più piccoli"? Non appena ciò accade, ovviamente, il lavoro extra necessario dovrebbe essere inserito nel backlog e non interferire con il resto dello sprint.

Inoltre, prova a vedere come il team ha sottovalutato quell'elemento: potresti fare di meglio su articoli futuri che lo hanno esaminato?

Sì, la data di consegna verrà spostata di conseguenza o l'elenco delle funzionalità per un aggiornamento potrebbe essere modificato in modo da non compromettere la consegna. Ma l'obiettivo è migliorare le stime dei punti futuri e anche ottenere una sequenza temporale più accurata.

È come le previsioni del tempo: più lontano, meno affidabile. Questa è un'analogia che tutti capiranno. Si sommano errori nelle stime.

Le vendite devono imparare a parlare in termini Scrum ai clienti. Scrum non ha senso in modo isolato, dovrebbe essere applicato verticalmente in tutta l'azienda e preferibilmente si estende nel regno del cliente.

In qualità di team di sviluppo, dovresti essere sicuro di questo. Puoi dare loro aspettative e ipotesi, ma non lasciare che siano impegni che prolungano un singolo sprint.

Faccio alcune cose quando ricevo domande come questa.

In primo luogo, rispondo alle domande sul futuro descrivendo il passato. Direi qualcosa del tipo che superiamo circa due di queste storie a settimana. Quindi, se non cambia nulla, prevediamo di finire con la storia 27 tra circa 14 settimane.

In secondo luogo, desidero che il cliente che affronta le persone si assuma la responsabilità del programma di trading rispetto al rischio. Direi qualcosa come Remember, il team di ingegneri lavora sulla base di stime 50/50. Se non cambia nulla, esiste una probabilità del 50/50 che la funzione 27 sia pronta in 14 settimane. Presumibilmente non vuoi segnalare a un cliente qualcosa con quel livello di rischio. Vuoi che elabori una stima di cui abbiamo, diciamo, il 90% di fiducia? Dovresti quindi rivedere le tue prove storiche e dire qualcosa del tipo: C'è una probabilità del 90% che la storia 27 venga realizzata in 25 settimane .

Infine, ricorda al tuo collega che, una volta assunto un impegno esterno, la società viene bloccata. Fare promesse esterne sulla storia numero 27 toglie tutta l'agilità dell'azienda. Saresti quindi impegnato in una determinata linea di azione. Ogni volta che qualcuno viene da te con una richiesta di modifica, ora devi rispondere. Ci siamo impegnati a finire la storia 27 prima di x date. Posso apportare questa modifica solo se contatti il ​​cliente e dici che il nostro impegno non è più valido. Fondamentalmente, assumere impegni specifici per lavorare più di un mese circa nel futuro comporta molti problemi.

Hai già una conversione (molto grezza): gli
sprint Scrum sono (usualmente) due settimane.
Sai che puoi finire, diciamo, circa 20 punti storia di funzioni in quelle due settimane (o in quale altro modo determini quali e quante funzioni vengono impacchettate in un singolo sprint?) E i tuoi sprint precedenti confermano tale stima (diciamo hai terminato 18, 21, 23, 19 e 20 punti storia con caratteristiche negli ultimi cinque sprint).

Diciamo che la caratteristica X (e tutte le sue dipendenze) è stata stimata come 47 punti trama.
Quindi puoi stimare che se metti in atto la massima priorità, dovresti prendere circa 3 sprint, cioè 6 settimane (ma assicurati che le tue stime tengano conto di chi può fare cosa - se 35 di quei punti sono DB funzionano e hai solo su DB guy devi rivedere la tua velocità stimata per tenerne conto).

Detto questo - comunicare fermamente che si tratta di stime grezze - c'è una ragione per cui gli sprint sono due settimane e non sei. Maggiore è il numero di aspetti che deve prevedere la copertura, maggiore è l'incertezza e l'errore. Inoltre, comunica con fermezza il costo, vale a dire che ciò significherebbe assegnare l'attività alla massima priorità, il che significa che nessun altro compito viene svolto. Altrimenti potresti imbatterti nello scenario di:

"Quando verrà eseguita la funzione Y ?"
"Se ci concentriamo su di esso la prossima ... 12 settimane"
" 12 settimane?!? Hai detto che ci vorrebbe 4."
"Sì, ma ci hai detto di dare la priorità alla funzione X , che ti abbiamo detto che avrebbe legato tutte le nostre risorse e avrebbe impiegato 8 settimane."
"Non puoi lavorare sulla funzione X e sulla funzione Y contemporaneamente?"
" gemito "

Lo sprint è definito tempo, diciamo 2 settimane. Non puoi prevedere che una storia verrà eseguita oltre 2 sprint, come se avessi lo sprint corrente e quello successivo. Presumo che tu abbia preparato storie che vengono discusse con il team per il prossimo sprint e che hanno ricevuto la priorità dal mondo degli affari. Quindi il meglio che puoi dire con certezza sono le prossime 4 settimane di lavoro.

Tutto ciò che va oltre le 4 settimane è soggetto a modifiche e le aziende possono elaborare una tabella di marcia che non è impostata in ore. Questo dovrebbe essere pianificato per sprint, diciamo un po 'di epic1 (epico come nel gruppo di storie raggruppate di jira) ed epic2 dovrebbe essere fatto nello sprint 47 e 48 e epic3 dovrebbe essere fatto nello sprint 49. Epics Stimo approssimativamente in ore da solo a vedere se uno o due si adatteranno a uno sprint, la sequenza temporale scivolerà comunque. Se le funzionalità non funzionano, le aziende devono ridurre la portata o accettare soluzioni non perfette che possono essere migliorate in seguito, se necessario (che dovrebbe essere agile, abbracciare la realtà invece di seguire il piano).

Puoi creare un bel diagramma di Gantt (è quello che piace agli affari) con sprint futuri e argomenti / epopee principali per quelli.

Mi piace rilasciare ogni sprint e poi preparo il rilascio con ciò che è stato completato nello sprint (o cose che sono state firmate per il rilascio dal business anche se non era perfetto), le cose non finite vanno allo sprint successivo. In questo modo ho una consegna prevedibile in circa 2-3 settimane (una settimana per eventuali correzioni sul rilascio del candidato).

Questa è la mia esperienza con un piccolo team, una piccola quantità di dipendenze esterne e ciò che ritengo ragionevole. Il tuo chilometraggio può variare.

Per le nuove funzionalità è quasi impossibile stimare il tempo richiesto.

L'esperienza con lo sviluppo del software mostra che nella maggior parte dei casi ci sono dettagli che non si possono vedere prima di iniziare davvero lo sviluppo. Nel migliore dei casi, questi dettagli potrebbero richiedere del tempo aggiuntivo, ma nel peggiore dei casi anche il progetto potrebbe fallire. La ragione di ciò è la complessità dello sviluppo del software stesso.

Questo è il motivo per cui SCRUM stima solo la complessità del problema (punti della trama), ma non il tempo. L'unica possibilità che hai è quella di dividere le funzioni con elevata complessità in quelle più piccole. In questo modo è possibile ridurre al minimo il rischio.

Poiché una stima del tempo è quasi impossibile, non esiste una formula per convertire i punti della storia in stime del tempo. La velocità può essere solo una stima molto grezza, non di più.

In SCRUM, il proprietario del prodotto può modificare le priorità degli articoli arretrati prima di ogni sprint. Pertanto, il master SCRUM non può fornire stime per più di uno sprint. Non sa quale articolo arretrato potrebbe diventare importante nel prossimo sprint.

SCRUM non è un metodo per fare cose impossibili (pianificare l'imprevedibile) o accelerare lo sviluppo. È un sistema di allerta precoce se lo sviluppo si sta esaurendo. Permette di reagire rapidamente ai nuovi requisiti.

Al post iniziale:

Sei già molto bravo se riesci a dividere la maggior parte delle attività in storie da 1 SP a 5 SP. Le stime della velocità potrebbero migliorare se le attività sono simili e il team diventa più esperto. Ma se ci sono sempre parti nuove e inedite in nuovi oggetti, devi vivere con l'imprecisione.

Dato che i tuoi sviluppatori normalmente trascorrono del tempo con lavori non di sviluppo (ad es. Riunioni), non dovresti pianificare con 8 ore di sviluppo per ogni giorno, ma meno, ad esempio 6 ore. Quindi ricevi una riserva per altre attività o per gli oggetti di lavoro che richiedono più tempo.

Se i tuoi colleghi di lavoro vogliono avere stime accurate (che è una contraddizione in sé), spiega loro i problemi inerenti allo sviluppo del software. Quindi mostra loro i vantaggi dei metodi agili.