Scrum: gli eventi irregolari dovrebbero essere stimati?

Considera gli estremi: se la tua squadra impiega 4 settimane per creare una demo di 30 minuti, qualcosa è chiaramente sbagliato. Allo stesso modo, se trascorrono 12 ore in quella riunione, vorrete sapere cosa sta succedendo.

Questi non sono numeri ragionevoli che ho fornito. Naturalmente sono necessari numeri più ragionevoli. Questo esempio esiste semplicemente per dimostrare che una riga esiste , quindi può essere significativo stimare dove si trova.

Tuttavia, la prossima domanda diventa quali sono le conseguenze della mancanza della scadenza. In fase di sviluppo, può essere una prima indicazione di un problema codebase (hrd da mantenere) o uno sviluppatore problematico (o che non sta facendo il proprio lavoro, o sta lottando con il proprio lavoro).

Ma la stessa metrica non si applica a una panoramica / demo a nuovi utenti (formazione) e potenziali clienti (vendite / marketing).

Un allenamento che richiede più tempo potrebbe non essere un'indicazione di studenti cattivi (o cattivi insegnanti). Un pitch di vendita che richiede più tempo non è indicativo di un problema se aumenta effettivamente le possibilità di vendere il prodotto.

Le stime sono utilizzate come un modo per giustificare ciò che i tuoi sviluppatori dedicano alla gestione non tecnica? Quindi dovresti mettere un limite ragionevole al preventivo. Qualsiasi deviazione dalla stima può essere giustificata sottolineando la natura imprevedibile dell'evento.

Questo non è diverso dalle attività di bughunting. Alcuni bug sono stati risolti in pochi minuti. Altri impiegano giorni o settimane. Non puoi sempre sapere quanto tempo ci vorrà per risolvere un problema. Il punto della stima non deve essere corretto, ma per tracciare una linea di ragionevolezza , quindi non è necessario intervenire con le attività a meno che qualcuno non alzi una bandiera rossa o superi la stima e ancora non ha consegnato.

In my opinion, the bigger issue is that our team members are responsible for coordinating and in a way participating in these events.

Se vuoi dire che i tuoi sviluppatori non dovrebbero fare questo lavoro e qualcun altro dovrebbe farlo, non sono del tutto d'accordo.

Se intendi che il tempo speso dai tuoi sviluppatori per questo non deve essere considerato come tempo di sviluppo, è corretto.

Come esempio semplificato, diciamo che uno dei tuoi sviluppatori è anche un genio contabile, e il reparto contabilità ha un disperato bisogno di un paio di mani in più. Il reparto contabilità non può dirti quanto tempo hanno bisogno di lui, tutto quello che dicono è "fino a quando i libri non sono corretti".

Non ha senso che tu metta una stima sulle attività contabili, dal momento che non sei un contabile. In secondo luogo, la metrica del successo di un contabile non è misurata nella capacità di prevedere i risultati, ma piuttosto nella precisione del risultato effettivo.

In questi tipi di casi, è necessario considerare queste dimostrazioni / presentazioni come "assenze dello sviluppo", ovvero il impiegato (non lo sviluppatore) sta facendo qualcosa per l'azienda ma non sta svolgendo attività di sviluppo.

Ma la conseguenza logica incombe:

If I need to plan the next sprint, I need to know how long they'll be absent, and therefore I need to have an expectation of how long their absence will be.

Si stima la loro assenza, ma non si alza una bandiera rossa se tale stima fosse negativa. Questa è una questione di prioritizzazione. Se la società afferma che le demo / presentazioni hanno la precedenza sullo sviluppo, qualsiasi assenza giustificata a causa di demo / presentazione sta per rovinare la pianificazione dello sprint.

Non puoi evitarlo. Ma la compagnia non può nemmeno biasimarti per uno sprint impreciso dato che loro stessi hanno concordato che la demo / presentazione ha la precedenza.

Questo non è in effetti diverso dall'assenza di uno sviluppatore a causa di assenze per malattia, o il tuo dipartimento non rispetta la scadenza a causa di un incendio in ufficio. La realtà ha la precedenza su quello che pensavi che sarebbe successo. Non puoi evitarlo. Per definizione semantica, non puoi aspettarti l'inatteso .

Gli incontri probabilmente non dovrebbero essere stimati, ma dovrebbe essere il lavoro svolto per prepararli e condurli. Progettare una demo per i nuovi utenti è un compito che non rende esattamente il software migliore, ma ha un output significativo: il design demo. La preparazione alla riunione può anche avere artefatti come la documentazione. Alcuni di essi sono probabilmente overhead, ma il lavoro che deve essere fatto per il business è il lavoro.

Consiglio di parlarne con il team alla prossima retrospettiva, provarlo per uno o due e poi rivalutare. Se funziona, funziona! In caso contrario, sia tu che il team dovresti capire meglio perché è una cattiva idea.

Non penso che questo sia qualcosa che può essere previsto, ma forse scoperto.

Innanzitutto, ottieni una velocità media per gli sprint che non includevano la preparazione per le presentazioni. Questa è la tua linea di base. Successivamente trova gli sprint in cui è stato svolto questo lavoro di preparazione e registra quella velocità media. Sottragga i due e ciò ti dà un'idea approssimativa del valore del story point di questo lavoro.

Dai uno sguardo più granuloso a ogni singolo sprint in cui le persone hanno fatto questo lavoro di preparazione e registra la differenza rispetto alla velocità normale. Spero che tu possa identificare la demo esatta che è stata preparata. La differenza di velocità per lo sprint può essere "preparata" preparando per quella demo.

Alcuni numeri concreti.

Tre sprint senza lavoro di preparazione e il tuo team ha avuto una media di 68 punti. Altri tre sprint in cui il lavoro di preparazione è stato completato hanno raggiunto una media di 62 punti. Sta cominciando a sembrare che questo lavoro di preparazione riguardi 6 punti di forza per la squadra, quindi lo porterei a livelli standard di 8 punti.

Diamo un'occhiata a uno sprint specifico. Diciamo che 1 sviluppatore stava preparando una demo per un nuovo cliente. Lo sprint ha permesso al team di realizzare 58 punti, una differenza di 10 punti rispetto alla velocità normale. Vai avanti e arrotondare fino a 13 punti.

Ciò significa che se hai bisogno di dimostrare l'applicazione a un nuovo client in uno sprint, hai qualcosa a cui confrontarlo. Quindi è solo questione di fare 1 dei seguenti:

1. Aggiungi una storia di 13 punti per la demo
2. Impegnati a fornire 13 punti in meno

Scegli l'opzione che ti impedisce la gestione dei progetti.