Come gestire il backlog del prodotto / le storie degli utenti

Non ho familiarità con TFS (si tratta di uno strumento software?), ma posso darti delle risposte basate su Schwarber.

1. Contenitori della storia

Ci sono solo due contenitori di storie a cui dovresti mai pensare, il backlog del prodotto e lo sprint backlog. Gli strumenti software per il tracciamento scrum possono consentire di conservare vecchi backlog di sprint per analisi storiche e va bene, ma è necessario chiudere un vecchio backlog di sprint (ovvero assicurarsi che tutto sia finito o spostato) prima di eseguire qualsiasi lavoro sul prossimo sprint backlog.

A volte c'è la tendenza a creare il backlog del prossimo sprint in uno strumento software mentre si è ancora nello sprint corrente. Non farlo. Se quel futuro sprint arretrato è lì, le persone cercheranno di mettere storie in esso. Ciò interrompe il corretto processo di pianificazione, aumenta le tensioni e confonde i problemi di pianificazione.

Se non riesci a mantenere i corretti confini tra i tuoi sprint, allora sei, in pratica, in esecuzione sprint multipli e similanimali. Sei multitasking. Per lo meno il sovraccarico del cambio di attività rallenta; la ricerca indica che un cambio di contesto completo nell'uomo, dal puzzle A al puzzle B, richiede 15 minuti. La mia esperienza suggerisce che questa resistenza può rappresentare il 50% o più della vostra produttività.

2. Epics

Mantieni i tuoi epici in giro. Qualcuno ha chiesto questa funzione, probabilmente torneranno e vogliono sapere lo stato dell'epica. Quella persona, dipartimento o cliente penserà alla "storia" che hanno presentato, ora promossa in epico. Non penseranno alle storie minori coinvolte e potrebbero non riconoscere nemmeno la storia che Foo è legata alla loro richiesta. L'epica è una comoda maniglia per la comunicazione tra lo sviluppo e il cliente.

Dal momento che gli epici in realtà non si riescono a lavorare su se stessi, solo le storie associate, gli epici passano direttamente dal backlog del prodotto al mucchio finito.

3. Dove vanno le storie?

Una storia dovrebbe essere in un solo contenitore alla volta. Dovrebbe iniziare nel backlog del prodotto, passare a uno sprint backlog e quindi essere finito. Se qualcuno viene a cercare la propria storia nel backlog del prodotto e non la trova, ciò significa che è in corso o completata.

4. Considerazioni finali sulla gestione di un backlog di prodotto approfondito

L'ordine in base alla forza diventa piuttosto privo di significato quando si hanno centinaia di elementi nel backlog del prodotto. Certo, il modo in cui organizzi gli articoli 20-70 potrebbe essere abbastanza significativo, ma a chi importa davvero se # 300 è prima o dopo # 301?

Una possibile soluzione a questo è di avere più backlog di sottocomponenti che si inseriscono in un backlog di prodotto principale. Ad esempio, potresti avere UI, DB, Backend, API, Infrastruttura e Debito tecnico come sottocomponenti. Ogni backlog di componenti può essere delegato a una persona diversa per la gestione. Un incontro periodico dovrebbe decidere quali storie spostare sul prodotto principale arretrato. Al fine di mantenere un corretto equilibrio di storie nel portafoglio di prodotti, è meglio decidere a priori una linea guida (non una regola) per le proporzioni di storie che vengono promosse al backlog principale. Una storia di API per ogni due storie dell'interfaccia utente? Quante storie puoi trarre dal debito tecnico rispetto al numero di storie di backend che devi prendere?

Questo sistema aggiunge notevole complessità e richiede un sacco di ulteriore coordinamento. Dovrebbe essere intrapreso solo quando il backlog del prodotto diventa così grande che il Product Owner non può pensare a tutte le storie contemporaneamente.

L'iterazione in Agile non è tanto un contenitore per le storie degli utenti, quanto una versione ridotta del software che segue l'SDLC per un periodo di tempo breve e facilmente gestibile.

Il Backlog non è un'iterazione, è essenzialmente un contenitore per user story, epics e attività che al momento non hanno il tempo di indirizzarsi nello sprint corrente. Nel pianificare in anticipo per il prossimo sprint, è necessario rivalutare le priorità correnti degli elementi nel backlog, rispetto al livello di sforzo per fornire ciascuno nel determinare ciò che appartiene o non appartiene alla successiva iterazione.

Non pianificare più di una iterazione in anticipo

Questo non è Agile e sconfigge l'intero scopo dello sviluppo iterativo nella sua interezza. Le esigenze e i requisiti aziendali sono in genere troppo volatili per elaborare piani a lungo termine su rigidi requisiti software, motivo per cui manteniamo i nostri obiettivi incentrati solo sull'iterazione corrente e su cui lavoreremo non appena forniremo questa iterazione.

Se la direzione desidera stime a lungo termine (basate sull'attuale arretrato come esiste al momento), allora si può considerare la dimensione degli elementi del backlog corrente per fornire una stima della data di completamento.

La tua domanda su quale iterazione inserire le storie del backlog mi dice che probabilmente stai tentando di pianificare le tue iterazioni troppo avanti.

When breaking an epic down into smaller USs, would I simply close the original epic, as it's no longer required? Or should I create the new USs as children of the epic? (it's then someone's responsibility to close the epic once all child USs have been completed).

Un'epica dovrebbe essere accettata quando raggiunge in modo soddisfacente il suo obiettivo aziendale dichiarato. Questo è essenzialmente quando tutte le storie degli utenti dei suoi figli sono state completate e accettate.