Come scomporre uno sprint in mischia?

Uno Sprint è semplicemente un ciclo di rilascio. È un piano a breve termine (e, sebbene la guida Scrum non usi più questa parola, io preferisco: impegno) fornire un insieme definito di cose che aggiungono valore al cliente e agli utenti. Epics e Stories rappresentano caratteristiche / funzionalità e attributi di qualità del sistema.

Inizierei a utilizzare l'idea di Spikes per gestire attività di indagine in cui l'obiettivo è prendere una decisione o apprendere alcune informazioni prima di fornire una funzionalità a valore aggiunto. Le punte sono timeboxed in ore o giorni. Alcuni team tentano di inserirli in Sprint mentre altri li fanno vivere al di fuori dello Sprint, non allineati con le date di inizio e fine di Sprint. Indipendentemente da ciò che fai, ti rendi conto che la capacità del tuo team di fornire funzionalità sarà ridotta se uno Spike è in corso. Puoi scegliere di inserire gli Spikes nel Product Backlog e / o Sprint Backlog, e assegnare loro la priorità e avere Epics e Stories in base al loro completamento.

Per quanto riguarda lo Sprint Goal, non sono completamente convinto della sua utilità. Come stai vedendo, il tuo Sprint potrebbe essere una combinazione di funzionalità di consegna (creazione di software, hardware in piedi, ecc.) Nella forma di completare Epics and Stories e imparare qualcosa di nuovo (compromessi architettonici, regolamenti, lingue o strutture, ecc. .) sotto forma di completamento di Spikes. In base alle priorità, lo Sprint Backlog potrebbe intersecare molti aspetti di un sistema software, rendendo difficile la scrittura di un obiettivo sintetico. A mio avviso, tutti gli Sprint hanno un obiettivo: offrire valore al cliente e agli utenti soddisfacendo la Definizione di Fatto per ogni Storia completata. Quel valore può essere nella funzionalità o in un aumento della conoscenza della squadra per prendere decisioni migliori in futuro.

In base a ciò che hai detto, penso semplicemente che Scrum non è adatto a te. Stai provando a massaggiare gli sprint come compiti e non sono pensati per questo: sono caselle di tempo per garantire che le persone dimostrino i progressi regolarmente. Sfortunatamente, sono particolarmente brutti quando i progressi non possono essere misurati in periodi di tempo più lunghi della mischia, o quando un compito richiede più tempo per completare rispetto allo sprint (che avverrà con consulenti esterni).

Un approccio migliore per te sarebbe un Kanban modificato, in cui le attività vengono comunque eseguite in parallelo. Se si assume che un'attività può essere "parcheggiata" quando viene inviata a un consulente per consentire più del numero prescritto di attività in corso, l'attività parcheggiata non viene considerata come in corso, quindi penso che si avrà un processo più gestibile (e ovviamente comprensibile).

Ci sono molti altri processi Agile là fuori, prenderei seriamente in considerazione ognuno di loro rispetto a Scrum. Ti consiglierei almeno di esaminare le alternative.

Grazie per i buoni pensieri, li ho presi in considerazione. Quello che vedo è che l'opzione migliore è attenersi a SCRUM anche se non è ottimale quando si lavora con i consulenti.

@Thomas Owens La mia esperienza di scrum master mi ha dimostrato che quando uno sprint contiene varie caratteristiche che non sono realmente correlate tra di loro, è difficile avere delle belle riunioni retrospettive dopo. Tendono ad essere vaghi è la mia esperienza.