Dovresti includere attività non di sviluppo nel tuo backlog Scrum?

Question

Stiamo avendo difficoltà a incorporare alcuni tipi di attività nei nostri prodotti e sprint backlog:

• incontri con i clienti
• Formazione e
• compiti amministrativi di condivisione della conoscenza

Alcuni di questi non sono direttamente collegati al progetto, quindi è facile metterli da parte e fare riferimento ad essi come overhead amministrativo (riducendo così i punti della storia fattibili in uno sprint).

Alcune attività, tuttavia (di solito le riunioni dei clienti) sono ricorrenti o molto frequenti. Come dovrebbero essere gestiti questi? Solitamente non si riferiscono direttamente a una particolare user story, ma sono di vitale importanza per il progetto.

Answer 1

A mio parere, le "attività" in realtà non appartengono al Product Backlog, gli elementi del Product Backlog (PBI) devono essere utilizzati per le cose che sono visibili agli utenti finali - o obbligatorie per ottenere tali elementi - ed espresse in un modo per dimostrare il loro valore aziendale.

Gli eventi ricorrenti come riunioni, attività amministrative, ecc. Non corrispondono realmente a questa definizione di PBI e non li includerei a livello di Product Backlog. In realtà, non vedo il punto di rintracciarli (sembra un overhead inutile, tipicamente sprecato) e quindi li includerei semplicemente nella velocità generale. Funziona e basta.

eventi

non ricorrenti, come una riunione speciale, R & D, l'esplorazione, ecc non appartengono realmente al PB né (come dovrebbe un valore PO loro e ?? priorità) e preferisco includere il loro "costo "nella stima del PBI correlato. E quando l'elemento viene prelevato, creiamo un'attività corrispondente nello Sprint Backlog, con una stima timeboxed.

E gestiamo corsi di formazione come le vacanze. Se un membro del team frequenta un corso, influisce sull'assegnazione dei membri del team (ad es. 90%) e quindi sulla capacità complessiva del team calcolata all'inizio dello Sprint. E raccogliamo meno oggetti.

Answer 2

Durante il mio ultimo progetto, abbiamo messo in atto alcune attività nella nostra mischia. Non erano nel backlog del prodotto, ma li abbiamo inventati durante il nostro gioco di pianificazione.

Il tipo di attività abbiamo incluso era laboratori clienti, attività di rilascio, ecc

Il motivo che li ha inseriti nella nostra bacheca mischia è stato quello di renderlo visibile a chiunque nel team di quello che chiunque altro stava facendo, e in alcuni casi anche per assegnare l'attività a qualcuno non nel mezzo di un'altra attività critica.

Answer 3

L'attività non è correlata al backlog del prodotto. L'attività è correlata allo sprint backlog. Le attività che hai descritto non sono attività.

Quando pianifichiamo il nostro prossimo sprint, riduciamo sempre la capacità pianificata per tutte le vacanze e gli allenamenti. Riduciamo anche la capacità per "spese generali amministrative". Nel nostro caso l'overhead amministrativo è solitamente 1MD per membro del team a settimana. Questo overhead è destinato alle riunioni e può essere di aiuto per la manutenzione su progetti già implementati.

Edit:

Credo che non si dovrebbe mai creare attività per riunioni, presentazioni, ecc nel vostro portafoglio ordini primavera. Perché?Poiché ogni attività ha una stima che influisce sullo sprint corrente. Durante lo sprint, le attività vengono completate in tempo reale e in base a tale grafico di burndown vengono mostrati i progressi del team nell'erogazione del valore del cliente. Quale valore riceverà il cliente dall'incontro? Inoltre, questo compito probabilmente non è correlato a una user story concreta, quindi quale progresso sarà visibile nel grafico di burndown del prodotto? Come decidi quante storie degli utenti dovrebbero essere prese per il prossimo sprint quando devi contare con un valore non incluso nella loro complessità (punti della trama)?

L'aggiunta di tali attività fittizie (attività senza valore aggiunto) al backlog dello sprint influirà anche sulla velocità. Sembrerà che ogni punto della storia costi più che nella realtà perché il tempo delle riunioni sarà incluso nel lavoro reale.

Che tipo di riunioni vuoi aggiungere al tuo backlog sprint? SCRUM richiede solo pochi incontri: riunioni giornaliere, riunioni di pianificazione, riunioni di revisione, riunioni retrospettive e nel più ampio progetto SCRUM di SCRUM. La riunione quotidiana è così breve che non deve essere inclusa nella pianificazione. La riunione di pianificazione, la riunione di revisione e la riunione retrospettiva non devono essere inclusi nello sprint. SCRUM di SCRUM è specifico e non influenza tutta la squadra - può essere ridotto dalla capacità pianificata dei membri presenti. Non sono necessari più incontri Il più importante: Le comunicazioni necessarie per completare l'attività fanno parte della stima delle attività.

Se sono necessarie altre riunioni, è sufficiente ridurre la capacità. Se il cliente, il management o il proprietario del prodotto si lamentano di una piccola capacità, spiegali semplicemente che ciò è dovuto a spese amministrative o burocratiche non standard.

Answer 4

I compiti ricorrenti tipici vengono assorbiti dalla stima/velocità. Cose come la riunione in piedi, le normali interazioni dello sviluppatore, le pause, ecc ...

Per gli altri eventi che non sono correlati alla costruzione del prodotto, preferisco rimuovere quel tempo dalla disponibilità dello sviluppatore per avere la capacità corretta.

Così il numero di user story che possiamo pianificare dipendono, la loro stima, la velocità di squadra e, naturalmente, la capacità di

Answer 5

La mia opinione è che se queste attività non sono direttamente legate ad una funzione, come la formazione, è non dovrebbero includerli nel backlog del prodotto, ma piuttosto regolare il tempo disponibile dagli sviluppatori e di conseguenza la velocità delle iterazioni. Non è perché hai una settimana lavorativa di 40 ore che puoi aspettarti che le persone lavorino per 40 ore ai progetti.

Answer 6

Se le riunioni o altre attività non di sviluppo sono direttamente associate al raggiungimento degli obiettivi dello sprint \ iteration \ project, non ho alcun problema a includerli nel programma di backlog/iterazione sprint. Se non altro, aiuta a garantire che le attività vengano svolte aumentando la loro visibilità.

Answer 7

Se non includi le cose che le persone devono fare nel tuo arretrato, come proponesti di gestirle?

Le iniziative non di sviluppo richiedono tempo e sono altrettanto importanti per fornire un prodotto di qualità come dev e qa funzionano.

È possibile scegliere di utilizzare un backlog separato per tali articoli o trasportarli in un piano di progetto separato, ma in tal caso si sta lavorando da due backlog funzionanti e sequenza e tempistica diventano un problema.

In genere costringo i team a creare storie per attività non di sviluppo come "come product manager, ho bisogno di produrre una roadmap, o" come product manager, ho bisogno di impostare workshop tecnici per rivedere il backlog in modo che i team di sviluppo possono capire le caratteristiche '.

in realtà dipende dalla situazione, ma se il backlog è IL luogo centrale per catturare e gestire il lavoro, perché è solo lo sviluppo e il controllo qualità che viene usato per?

Answer 8

È possibile gestire attività non di sviluppo in una scheda Trello. Questi possono essere cose come attività di ricerca o estrazione di dati da utilizzare per lo sviluppo. Questi non appartengono a JIRA o Rally in quanto non sono attività di sviluppo e non hanno una stima del punto di vista.

Answer 9

Non esiste una formula di correzione per decidere le User Story in Scrum. Nel mio progetto, selezioniamo e selezioniamo quale articolo di lavoro deve essere convertito in Storie. Per esempio. attività come il confronto di 2-3 strumenti di sviluppo IDE vanno in un Backlog perché sono direttamente correlate allo sviluppo. Ma altrimenti organizzo attività di sviluppo di 5 ore al giorno per ogni membro del team, in modo che trascorrano ore rimanenti per seguire corsi di formazione, documentazione, scambio di conoscenze, peer programming, ecc. Questo per me giustifica la velocità demo vs sprint.