Il team sta valutando i punti storia, l'azienda vuole il tempo reale

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

HorusKol ha toccato questa prossima parte. La tua velocità di sprint in squadra può aiutarti con i risultati a lungo termine. Supponi 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), quindi la tua squadra attuale può fare un massimo di 2.500 punti in 12 mesi.

Quindi il business ti arriva con 170 punti vale la pena di storie ed epopee. Dividi questo per la velocità storica della squadra di 50 punti (una media di ogni sprint finora) e ottieni 3,4 sprint. Dato che stiamo facendo una stima, arrotondiamo fino a 4 sprint: 8 settimane. Due mesi, fondamentalmente. Mi piace anche prendere gli ultimi 3-4 sprint e prendere un'altra stima. Diciamo che la tua squadra negli ultimi 3 sprint ha fatto rispettivamente 53, 67 e 55 punti. Funziona a 58 punti ish, che a quel ritmo sono 2.9 sprint, quindi sostanzialmente 3 sprint. Sembra che il tuo calendario per quei 170 punti abbia un aspetto da 6 a 8 settimane.

Dì all'azienda 2 mesi. Non dirgli 6-8 settimane, perché sentiranno solo "6 settimane". Non dirlo nemmeno a 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 solo in mesi. Se colpisci un anno o più, onestamente, non valuti quel lavoro. È inutile. Troppo può cambiare in un anno.

Ho trovato questo modo abbastanza accurato 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:

Riassunto. Sempre.

Probabilmente hai già una conversione intrinseca dai punti della storia alle stime temporali - come decidi di aver selezionato abbastanza lavoro per lo sprint? Probabilmente hai detto qualcosa del tipo: "la squadra può gestire 20 (o 40 o qualunque) punti alla settimana". Dopo alcuni sprint, dovresti essere in grado di rivedere quello basato sul completamento - quindi ora è 15 o 25 (o 35 o 50 o ...) punti uno sprint - questa è la velocità della tua squadra

For 1-SP user stories, there is of course a heavy bias towards very short time spans (with the occasional blow-up), but especially for 2-SP stories, they're all over the place: there is a factor of 20 between the "fastest" and the "slowest" completions. For 3, 5, and 8-SP stories, the spread is also more than a factor of 2.

Qualche variazione sul tempo per completare storie specifiche va bene entro i valori dei punti - la velocità guarda dopo quell'incertezza essendo una media sulla storia recente.

Tuttavia, potrebbe essere necessario dare una lunga occhiata a come si assegnano i punti, in particolare quelli a 2 punti se si ottiene una fluttuazione così ampia. Dovrebbero essere incerti (e dovrebbero essere scomposti) compiti di punto più alto, ma compiti piccoli come un puntatore a 2 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 tale intervallo di tempo da completare.

Quindi, guarda il 2-pointer che ha richiesto più tempo nella tua retrospettiva. Perché una cosa che probabilmente avrebbe dovuto prendere una svolta mattutina in uno slogan di 10 giorni? Qualcosa potrebbe essere stato contrassegnato in quella prima mattina per dire "questo deve diventare ed epico e suddiviso in compiti più piccoli"? Non appena ciò accadrà, 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 meglio sugli articoli futuri dopo averlo esaminato?

Sì, la data di consegna verrà applicata di conseguenza, oppure l'elenco delle funzionalità per un aggiornamento potrebbe essere rivisto in modo che la consegna non venga modificata. Ma l'obiettivo è migliorare le stime future dei punti e anche ottenere una tempistica più accurata.

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

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

Tu come team di sviluppo dovresti essere risoluto in questo. Puoi dare loro aspettative e supposizioni ma non lasciare che siano impegni che estendono un singolo sprint.

Faccio alcune cose quando ricevo domande del genere.

In primo luogo, rispondo alle domande sul futuro descrivendo il passato. Direi qualcosa di simile a Abbiamo ottenuto circa due di queste storie a settimana. Quindi, se non cambia nulla, ci aspettiamo di finire con la storia 27 in circa 14 settimane.

In secondo luogo, desidero che il cliente affronti le persone ad assumersi la responsabilità del piano di negoziazione rispetto al rischio. Vorrei dire qualcosa come Ricorda, il team di ingegneri lavora sulla base di stime 50/50. Se non cambia nulla, c'è una possibilità del 50/50 che la funzione 27 sia pronta in 14 settimane. Presumibilmente non vuoi segnalare qualcosa con quel livello di rischio per un cliente. Vuoi che elabori una stima su cui abbiamo, ad esempio, una fiducia del 90%? Dovresti quindi rivedere le prove storiche e dire qualcosa come: C'è una probabilità del 90% che la storia 27 sarà fatto in 25 settimane .

Infine, ricorda al tuo collega che una volta assunto un impegno esterno, la società è bloccata. Fare promesse esterne sulla storia numero 27 porta via tutta l'agilità della compagnia. Saresti quindi impegnato in una particolare linea d'azione. Ogni volta che qualcuno viene da te con una richiesta di modifica, ora devi rispondere Ci siamo impegnati a completare la storia 27 prima della data di x. Posso apportare questa modifica solo se contattate il cliente e diciamo che il nostro impegno non è più valido. In sostanza, prendere impegni specifici per il lavoro più di un mese circa nel futuro comporta molti problemi.

Hai già una conversione (molto approssimativa):
Gli sprint di Scrum sono (di solito) due settimane.
Sai che puoi finire, diciamo, circa 20 story point degni di funzionalità in queste due settimane (o in che altro modo determini quali e quante funzioni saranno impacchettate in un singolo sprint?) E i tuoi precedenti sprint confermano tale stima dì che hai terminato 18, 21, 23, 19 e 20 punti storia di valore negli ultimi cinque sprint).

Diciamo che la feature X (e tutte le sue dipendenze) sono state stimate come 47 story point.
Quindi puoi stimare che se applichi quella implementazione alla massima priorità devi 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 hai bisogno di rivedere la tua velocità stimata per tenerne conto.

Detto questo - comunicare con fermezza che si tratta di stime approssimative - c'è una ragione per cui gli sprint sono due settimane e non sei. Maggiore è il numero di cose che il tuo forcast deve coprire, maggiore è l'incertezza e l'errore. Inoltre comunica con fermezza il costo, ovvero ciò significa mettere l'attività in primo piano, il che significa che non ci sono altre attività su cui lavorare. Altrimenti potresti imbatterti nello scenario di:

"Quando verrà eseguito Y ?"
"Se ci concentriamo su di esso ... 12 settimane" " 12 settimane?!? Hai detto che ci sarebbero voluti 4."
"Sì, ma ci hai detto di mettere in primo piano la funzione X , che ti abbiamo detto di impegnare tutte le nostre risorse e impiegare 8 settimane.

"Non puoi lavorare sulla funzione X e presentare Y allo stesso tempo?"
" gemito "

Lo sprint è il tempo definito, diciamo 2 settimane. Non puoi prevedere che alcune storie verranno fatte oltre 2 sprint, come se avessi il tuo sprint attuale e il prossimo sprint. Presumo che tu abbia preparato storie discusse con il team per il prossimo sprint e che avessero la priorità per le imprese. Quindi, il meglio che puoi dire sono le prossime 4 settimane di lavoro.

Ogni cosa oltre le 4 settimane è soggetta a modifiche e gli affari possono fare una tabella di marcia che non è impostata in ore. Questo dovrebbe essere pianificato per sprint, diciamo un po 'epico1 (epico come nel mazzo di storie raggruppate in jira) ed epic2 dovrebbe essere fatto nello sprint 47 e 48 e epic3 dovrebbe essere fatto nello sprint 49. Epics I stima approssimativamente in ore da solo a vedere se uno o due si inseriranno in uno sprint, la cronologia scivolerà comunque. Se le funzionalità non funzionano, le aziende devono tagliare la portata o accettare soluzioni non perfette che possono essere migliorate successivamente, se necessario (che dovrebbe essere agile, abbracciare la realtà anziché seguire il piano).

Puoi creare un buon diagramma di Gantt (che è come fare affari) con sprint futuri e argomenti / epiche principali per questi.

Mi piace rilasciare ogni sprint e poi preparo il rilascio con ciò che è stato terminato in sprint (o roba che è stata firmata per il rilascio da parte del business anche se non era perfetta), le cose non finite vanno al prossimo sprint. In questo modo ho una distribuzione prevedibile in una timeline di circa 2-3 settimane (una settimana per eventuali correzioni sul candidato al rilascio).

Questa è la mia esperienza con un piccolo team, una piccola quantità di dipendenze esterne e ciò che ritengo ragionevole. La tua milizia 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 puoi vedere prima di iniziare veramente lo sviluppo. Nel migliore dei casi questi deteils potrebbero richiedere un po 'di tempo in più, 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 caratteristiche con alta complessità in quelle più piccole. In questo modo puoi ridurre al minimo il rischio.

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

In SCRUM, il proprietario del prodotto può modificare le priorità degli elementi del backlog prima di ogni sprint. Pertanto, il master SCRUM non può fornire stime per più di uno sprint. Non sa quale oggetto del backlog possa diventare importante nel prossimo sprint.

SCRUM non è un metodo per fare cose impossibili (pianificare l'inappellabile) o rendere più veloce lo sviluppo. È un sistema di allarme rapido se lo sviluppo sta per scadere. Permette di reagire rapidamente ai nuovi requisiti.

Al post iniziale:

Sei già molto bravo se riesci a suddividere la maggior parte delle tue attività in 1 SP a 5 storie SP. Le stime di velocità potrebbero migliorare se le attività sono simili e il tuo team ha più esperienza. Ma se ci sono sempre parti nuove e non riconosciute in nuovi elementi, devi convivere con l'inaccuratezza.

Dato che normalmente i tuoi sviluppatori trascorrono del tempo con il lavoro non di sviluppo (ad esempio le riunioni), non devi pianificare con 8 ore di sviluppo per ogni giorno, ma meno, ad es. 6 ore. Quindi ottieni 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 sono di per sé una contraddizione), spiega loro i problemi inerenti allo sviluppo del software. Quindi mostra loro i vantaggi dei metodi agili.