In base a come descrivi il tuo flusso di lavoro da una storia, con un backlog di prodotto, uno sprint backlog e altri bucket (presumo che assomiglino a qualcosa come "in corso / in sviluppo", "pronto per il controllo qualità" , "finito"), sembra che tu stia aggiungendo alcuni elementi di Kanban a Scrum - una combinazione non rara chiamata a volte Scrumban . La nozione di Kanban aggiunge limiti alle dimensioni di ciascun bucket per impedire ai tuoi sviluppatori di avere troppe storie in corso o ai tuoi tester di testare troppo. È simile alla velocità per lo spostamento degli elementi dal backlog del prodotto nel backlog dello sprint, ma all'interno di uno sprint.
Affronterei il problema facendo in modo che i tuoi compiti fossero le storie degli utenti, con le storie degli utenti che passano dal backlog del prodotto allo sprint backlog al bucket in progress fino al bucket QA pronto per il bucket finito. Dopo che lo sviluppatore ha terminato la storia (in base alla tua definizione di finito), l'avrebbe spostato nel secchio "pronto per il QA", in cui la persona successiva lo avrebbe estratto e lavorato su di esso. In caso di problemi, nel sistema di tracciamento verrà inserito un difetto e il racconto dell'utente verrà spostato nel bucket finito poiché è stato implementato e testato. Se non ci sono problemi, passa direttamente al bucket finito.
Quando il difetto arriva dallo sprint, non c'è problema nel rimetterlo nello sprint backlog (o forse in una sorta di bucket "in progress"). Una storia con difetti noti viene solitamente considerata incompleta. Se è determinato che non c'è abbastanza tempo per terminare la storia o che i difetti sono attribuiti a non comprendere la storia, un'opzione potrebbe essere quella di descriverlo dallo sprint fino a quando non potrai capire meglio la necessità - in questo caso, ti consiglio di non inclusa l'implementazione difettosa nel prodotto rilasciato.
Se, a causa del tuo difetto, la storia non finisce nello sprint, questo verrà fuori nei tuoi calcoli di velocità per gli sprint futuri. Le storie non finite (storie difettose) non ti procurano punti storia, quindi pianifichi degli sprint più piccoli. Meno storie complesse porteranno a più tempo nei test e incoraggeranno a spendere di più per trovare i difetti in anticipo - prevenire i difetti non è solo più economico, ma richiede meno tempo della somma del tempo speso per identificare l'esistenza di un problema, trovare il problema nella progettazione o implementazione, risolvere il problema e ripetere il test per garantire che il problema sia stato risolto senza altri impatti negativi sul sistema. Poiché il timebox è la chiave, la capacità di prevenire i difetti porta a sprint più produttivi in futuro.
Indipendentemente da ciò che fai, dovresti coinvolgere il Product Owner (che si spera sia un cliente / utente rappresentante) quando si tratta di decidere come dare la priorità ai difetti. Alcuni difetti potrebbero essere accettabili per essere messi in un rilascio se ci sono soluzioni alternative o sono rari, il che significa che il difetto si presenterebbe come una storia in uno sprint futuro. Altri difetti potrebbero essere urgenti e "showstoppers": questi devono essere risolti immediatamente e un prodotto non può essere utilizzato se esiste.