Come devono essere gestite le attività di formazione in Agile / Scrum

Penso che tu stia pensando troppo. Trattalo come qualsiasi altra cosa che non sia direttamente legata allo sviluppo del prodotto (mangiare, prendere una pausa, partecipare a una presentazione, una settimana lavorativa breve a causa di una vacanza, ...)

Vale a dire, tenetene conto durante la pianificazione dello sprint e regolate il numero di storie che tirate per tenere conto del tempo perso. Se sai che alla squadra mancherà un giorno o due a causa dell'allenamento, attendi circa un giorno o due punti in meno.

L'unico vero obiettivo da una prospettiva di mischia è di essere trasparenti al riguardo. Fai sapere agli stakeholder che farai meno punti in uno sprint e spiegherai perché.

Tutto ciò detto, se il tuo team ritiene utile a fini di pianificazione considerarlo come una storia o come un picco o un compito, vai avanti e fallo.

TL; DR. Non fare nulla che pensi di supposto fare, fare ciò che effettivamente aiuta la tua squadra ad andare avanti.

Nel contesto di Scrum, vedo alcune possibilità diverse:

1. La formazione è sotto forma di un corso ufficiale con presenze richieste / previste in date specifiche. In questo caso, tratterei le date del corso come giorni di vacanza pianificati fino al la pianificazione dello sprint va. Ciò significa che le persone che partecipano al corso non sono disponibili per una parte dello sprint e la velocità prevista deve essere regolata per questo.

2. La formazione è direttamente correlata a una o più storie sul backlog, ma non è altrimenti legata a date specifiche. In questo caso, puoi creare un picco (una storia tecnica con una durata fissa / timebox, solitamente usata per investigare le cose) per fare la formazione. Se è uno studio più lungo con moduli chiaramente identificabili, allora potresti anche creare un picco separato per ciascun modulo.

3. La formazione non è legata al progetto e non è legata a date specifiche. Si tratta in genere di un tipo di allenamento di "sviluppo personale". Poiché non aggiunge valore al progetto (anche se non indirettamente), ma richiede tempo a qualcuno, la soluzione più equa qui sembra essere quella di tenere conto dell'addestramento nel fattore di disponibilità o di messa a fuoco di chi sta seguendo la formazione. Questo non deve significare che sono completamente de-allocati.

Sebbene non sia qualcosa che è descritto nella Guida di Scrum , il concetto di Spike è abbastanza noto ( Wikipedia , Software per capre di montagna , SAFe ).

Un picco è un'attività specifica.

Pianificazione del picco. Sebbene alcune persone dicano di non inserirli nel Product Backlog, lo trovo utile ai fini della pianificazione, soprattutto se si identifica la necessità durante l'esecuzione di un perfezionamento del backlog per gli elementi che sono non è previsto che accada per uno sprint o due: potresti decidere di posticipare il picco fino allo sprint prima che sia necessario. Ovviamente, ciò infrange la definizione della Scrum Guide di cosa sia un Product Backlog, ma penso che sia importante fare ciò che funziona per il team.

Stima del picco. Solitamente non stimoli i picchi. Timebox a Spike. Potrebbero attraversare i confini di Sprint, anche. Invece di stimarli, definisci un obiettivo o un ambito e fallo completare entro una data specifica. Tuttavia, qualcosa che può funzionare sta mettendo un limite superiore di sforzo sullo Spike in termini di unità di stima (ore, punti, qualsiasi cosa). Ad esempio, se usi i Story Points, puoi inserire un numero di Story Points nello Sprint. Chiunque stia lavorando su quel Spike passa quel livello di impegno sullo Spike. Se finisce per essere più complesso, puoi andare in una ripianificazione per decidere come riordinare lo Sprint ei Backlog del prodotto in base a questo lavoro extra. Personalmente, trovo di non stimarli e di completarli entro i limiti di uno Sprint (per abilitare il lavoro su un altro Product Backlog Item nel prossimo Sprint) o prima della successiva sessione di Backlog Refinement (per consentire di stimare il Product Backlog Item) come il più utile.

Pianificazione del picco. Se segui una guida tradizionale e non stimoli un picco, devi considerare l'impatto sulla velocità se uno o più membri del team di sviluppo stanno lavorando su un oggetto . Poiché è un lavoro che non ha punti o tempi stimati, ma deve ancora essere fatto (usando sforzo e tempo), ti impedirà di fare altro lavoro.

I picchi sono utili solo per la formazione specificamente legata al prodotto e al progetto a portata di mano. Alcuni corsi di formazione - conformità o addestramento normativo e sviluppo professionale, ad esempio - non sono necessariamente legati al lavoro svolto su un progetto specifico.

Questi tipi di formazione dovrebbero essere presi in considerazione in termini di capacità. Se le persone hanno una formazione stimata in un giorno, dovresti ridurre la velocità in modo appropriato (assumere un giorno extra di lavoro per i membri della squadra che stanno facendo l'allenamento).

Questi tipi di cose non dovrebbero essere presenti nel Product Backlog o in uno Sprint Backlog e non dovrebbero essere stimati dal team di progetto. Esse sono al di fuori della metodologia di gestione del progetto, ma influiscono sul modo in cui il lavoro viene svolto.