Dovremmo creare una storia per le vacanze?

No.

Prima di tutto, la vacanza non è un problema, è una realtà. Il grafico di burn-down dovrebbe riflettere la realtà dei progressi del progetto, e se il progetto ha progredito meno durante uno sprint rispetto a un altro a causa delle vacanze, un grafico di sprint corretto lo rifletterà.

In secondo luogo, le vacanze (insieme ad altre funzioni amministrative) dovrebbero verificarsi nel corso di un progetto. L'impatto che tali interruzioni hanno sulla velocità di sprint media del progetto sarà uniforme nel tempo. La velocità media risultante sarà un indicatore più realistico dello sforzo di sviluppo disponibile per sprint rispetto ad alcuni calcoli come #OfDevelopers * SomeStandard#OfHours per Sprint .

Se corrompi la tua velocità di sprint aggiungendo storie che non sono realmente storie, non otterrai mai questa visione realistica dei progressi del tuo progetto.

Non penso sia una buona idea.

Una storia del genere non fornirebbe alcun valore commerciale al proprietario del prodotto. È solo un trucco per far funzionare il tuo grafico di burndown.

Non ci piacciono gli hack:)

Perché non aggiustare semplicemente la data di completamento prevista del grafico di burndown regolando la velocità prevista?

Il tuo grafico di burndown è lì per aiutare il team, incluso il proprietario del prodotto, a determinare se sei sulla buona strada o meno a prendere gli impegni per lo sprint. Dovresti fare tutto il necessario per renderlo utile a tale scopo. Se riesci a guardarlo e a spiegare rapidamente eventuali deviazioni, ed essere ancora in grado di dire se sei sulla buona strada, allora non c'è bisogno di cose come storie di vacanza.

D'altra parte, ho avuto tratti in cui a causa del modo in cui usavamo lo strumento, il grafico di burndown era completamente inutile, così la gente ha smesso di guardarlo e di prendersene cura. Se questa è la tua situazione frequente, allora qualcosa come una storia di vacanza può essere molto utile.

Personalmente preferirei che lo strumento potesse cambiare la linea ideale per essere qualcosa di diverso da una progressione lineare, ma poiché la maggior parte non può, quindi usare una trama per regolare il burndown per dare una progressione lineare è certamente ok, purché conservi il grafico come fedele rappresentazione dei tuoi progressi effettivi. Se lo stai manipolando per rendere il tuo burndown bello anche quando le persone ancora in ufficio non stanno facendo progressi reali, allora stai sbagliando.

Nota che vuoi che una storia del genere influisca solo sul tuo burndown, non sulla tua velocità, per i motivi che hanno indicato altre risposte. Ciò significa che non assegnerei punti storia a una storia di vacanza, solo ore.

Non è un approccio standard, no.

Ma il tuo team ha un problema con il monitoraggio / registrazione / identificazione delle ore da quando il Product Owner ha richiesto di apportare una modifica. Quindi potrebbe avere senso nel tuo caso.

Generalmente, i membri del team fanno offerte per progetti in base al numero di punti che credono di avere in tale sprint. Ciò significa che ogni membro del team deve essere consapevole di qualsiasi impegno che impedisca loro di ottenere un punteggio di sprint completo.

Potresti anche aver bisogno di considerare altri tipi di storie "coperte" per riunioni ad-hoc, assistenza clienti, amministrazione, ecc ... se il proprietario del prodotto non ha l'impressione che stia vedendo tutto il tempo che dovrebbe riflettersi entro uno sprint.

Supponendo che la vacanza sia pianificata, devi solo adeguare la quantità di tempo assegnata allo sviluppatore di conseguenza. In tal caso, il burn-down potrebbe non essere buono all'inizio, ma dovrebbe raggiungere il livello corretto alla fine.

Tuttavia, se non è pianificato, puoi aggiungerlo come Impegno di Sprint. Che deve essere notato. In tal caso, se si verificano eventi non pianificati, è possibile che si discuta sulla retrospettiva per adattare forse l'allocazione standard o semplicemente ignorarla (che è valida) perché potrebbe trattarsi di un incidente occasionale.

Questo è come imbrogliare a te stesso; è una pessima idea.

Un burndown mostra i tuoi reali progressi e ovviamente le vacanze di qualcuno non sono progressi sul tuo prodotto.

Se il tuo PO insiste, ho una proposta: tutte le storie degli utenti sono vacanze per le persone! La gente è felice e anche il burndown è felice! E mai, mai c'è una deviazione nelle tue preziose classifiche di burndown! (è uno scherzo)

Sono in ritardo per la festa, ma è importante dare la contro-argomentazione alle risposte puriste.

Due grandi motivi per i grafici Velocity e Burndown sono di migliorare la prevedibilità per il team PM e di fornire chiari indicatori visivi durante le retrovie per aiutare identificare gli impedimenti .

Puoi dimostrare che la contabilizzazione di quei punti ferie in questo sprint ti darà una media più accurata di tre rotazioni medie quando prevede la capacità per il prossimo sprint (questa vacanza non influisce sulla velocità del prossimo sprint); aiutare un team a pianificare in modo più accurato.

Inoltre, se puoi normalizzare la varianza causata da influenze controllabili (come le vacanze), allora sarà più ovvio dare un'occhiata ai grafici quando la variazione reale potrebbe essere dovuta a impedimenti reali e così dovrebbe essere discusso in retros sorgere.

D'altra parte, le vacanze non sono realmente pubblicate, quindi un purista direbbe che la vacanza costa effettivamente la velocità della squadra e questo dovrebbe riflettersi nei numeri.

Quindi, come squadra, puoi trattare le vacanze come si tratterebbe di un punto temporale (come suggerisce l'interrogante), oppure si può fare un po 'di matematica extra e accettare un po' di fumo in più nelle carte quando si cercano le tendenze. Si tratta di personalizzare il framework mischia per il team attuale e amp; esigenze organizzative .

In che modo risponde alla domanda " quanti punti dovremmo pianificare nel prossimo sprint " il migliore per la tua squadra?