Dei punti storia più alti rappresentano esponenzialmente uno sforzo maggiore perché sono allocati in modo lineare?

I've always been told that the complexity of story points should go up roughly exponentially.

Sì, questo è in genere il motivo per cui i punti della storia sono Fibonacci (1,2,3,5,8,13,21) - un 8 non è due volte più duro di un 5, è un po 'più difficile. Ma invece di un 6, supponiamo che un lavoro più grande sia più rischioso . È più probabile che si trasformi in qualcosa che richiede molto più tempo / impegno, quindi è un 8 a giustificare il rischio di stima.

Essentially a task pointed at 5 should be more then 5 times as complex as a task pointed at 1.

No. Un 5 dovrebbe in media richiedere il massimo sforzo di 5 1. Di nuovo, dico in media, perché una buona porzione di punti per le grandi storie è rischio . A volte un 5 richiede meno sforzo perché tutto è andato bene. A volte un 5 richiederà uno sforzo maggiore perché le incognite si trasformano in problemi. Questo è in parte il motivo per cui la velocità ha senso solo nel tempo.

Ma ancora più importante, la complessità del software non è correlata linearmente allo sforzo. Se raddoppi la complessità del software, lo sforzo sarà peggio del doppio.

What is the 'proper' approach for handling story points from a management perspective?

I punti della storia sono nella migliore delle ipotesi una stima approssimativa. Come manager, se vedi il tuo team di mischia impegnarsi a raddoppiare i loro soliti punti storia, forse non dovresti aspettarti che lo sprint abbia successo. Se vedi che la loro velocità scivola verso il basso per 6 mesi, potresti considerare alcuni problemi di morale o il debito tecnico accumulato (o altra resistenza organizzativa).

Can work assigned to a developer be measured by total points assigned in a meaningful manner?

No. Perché i punti non sono il lavoro. Diversi sviluppatori hanno diversi punti di forza e di debolezza. Diversi sviluppatori sono in diversi punti della loro carriera. Diversi sviluppatori lavorano a ritmi diversi. Bollire tutto in un unico numero uniforme e provare a gestire per foglio di calcolo è l'inettitudine (ampiamente praticata).

Tutte le stime, indipendentemente da come le crei, includeranno automaticamente tutti e tre i componenti:

• effort (solo lavoro)
• rischio (che si romperà qualcosa) e
• incertezza (incerto su quanto dobbiamo imparare)

I numeri più grandi tendono a indicare che gli ultimi due sono fattori maggiori rispetto al primo. A volte un cambiamento di una riga è super incerto e rischioso. A volte una modifica di 100 righe è banale.

Penso a una storia a un punto come se ne valesse la pena di lavorare - dove il punto sul dado è un certo periodo di tempo (forse 90 minuti, forse 25, forse 1/2 giorno).

Una trama a due punti ha uno spread di due dadi: tra 2 e 12 periodi di tempo.

Una storia di cinque punti ha uno spread di cinque dadi, molto probabilmente tra 5 periodi e 30 periodi.

L'analogia è di aiutarci a pensare alla variabilità. Una storia di 21 punti ha variabilità assurdamente alta, e forse non dovremmo farlo affatto se la prevedibilità è importante per noi. Abbiamo bisogno di scomporlo in picchi e piccole storie che hanno una variabilità inferiore.

Questo è il motivo per cui molte organizzazioni hanno superato i punti della storia e, al contrario, suddividono tutte le storie in una bassa variabilità; in questo modo sono più prevedibili e possono fornire più continuamente.

È la base di molte nuove tendenze nello sviluppo del software.

Puoi fare le tue misurazioni e vedere la variabilità per punti della storia. Sembra che tu abbia già raggiunto la stessa conclusione intuitivamente. Quindi, forse la regolazione della scala del punto storia non è la migliore risposta.

Pace, Tim

What is the 'proper' approach for handling story points from a management perspective?

I manager non dovrebbero conoscere i punti e i punti non dovrebbero mai essere usati per misurare le prestazioni di un individuo.

I punti sono uno strumento per lo sviluppo team e i team di sviluppo non hanno manager. Un Product Owner conoscerà i punti, ma dovrebbero comunicare con i manager in qualcosa di ancora meno preciso dei punti (in genere, nel numero di sprint prima che il lavoro sia pronto).

Il valore numerico del punto è privo di significato e esiste solo perché gli esseri umani sono utilizzati per quantificare le cose con i numeri.

La ragione per i punti della storia è fornire una stima approssimativa relativa , niente di più. Il valore effettivo è irrilevante. Il fatto che il numero 3 sia tre volte più grande del numero 1 non ha rilevanza nei punti della storia. Un tre significa semplicemente che è più complesso di un 1 e ha una maggiore quantità di incertezza. È tre volte tanto? Due volte? 5 volte? Non importa. Tutto ciò che conta è che sappiamo che è più sforzo, con più incertezza.

Una delle migliori spiegazioni che ho sentito è che i valori puntuali sono semplicemente dei secchi. Se hai un secchiello da pinta e un secchio da gallone e un secchio da gallone, dove metti qualcosa che è leggermente più di un quarto? Lo metti nel gallone, non perché è quattro volte più di un quarto, ma perché è semplicemente più grande di un quarto.

Can work assigned to a developer be measured by total points assigned in a meaningful manner?

No. Per uno, la mischia non ha il concetto di assegnare lavoro. I punti non dovrebbero essere usati come misura delle prestazioni di un individuo.

How does one avoid penalizing developers who take more complex tickets?

Evita ciò non basando la revisione delle prestazioni sui punti. Periodo.

I punti sono strettamente uno strumento di misurazione per una squadra nel suo complesso, non un individuo.