Avere una grande quantità di riporto tra gli sprint è un segno che le storie non sono state appropriatamente corrette, e ciò richiede molto lavoro con il proprietario del prodotto per chiarire i requisiti e creare una definizione precisa di fatto. Alcuni di questi possono essere il modo in cui pianifichi i tuoi sprint, dovrebbero essere grandi quanto la quantità di punti che hai effettivamente consegnato in passato, non solo tutto ciò che un cliente vuole ora. Se hai un proprietario di un prodotto che desidera di più in uno sprint di quanto tu possa realizzare, devi tornare indietro e ottenere la serie di storie correttamente assegnate alle priorità che si adattano alle dimensioni dello sprint e non prendere più di quello. In una metodologia mischia / agile è responsabilità del team di sviluppo assicurarsi che gestiscano le dimensioni di uno sprint solo per quanto possono.
Sembra che tu abbia anche la convinzione che Agile significhi essere più veloce o che i tuoi clienti abbiano questa convinzione. Questo non è vero nel senso che molte persone credono che sia. Quando le persone agili dichiarano di fornire software di lavoro più veloce, stanno costringendo il software di lavoro a essere solo ciò che era nello sprint o in precedenti sprint. Puoi consegnare un sito che ha un sistema di pagamento funzionante più veloce, ma non avrà ricerca, recensioni, gallerie fotografiche, liste dei desideri, ecc. Agile garantisce il funzionamento del software più velocemente, non necessariamente il software completo più veloce (anche se ciò può accadere con un squadra matura).
Il processo agile non è eccezionale per spiegare come vengono gestite scadenze difficili, in genere è più implicito. È gestito prendendo i punti stimati della storia della funzione e usando Velocity per lavorare all'indietro per ottenere l'ultimo sprint in cui questi elementi potrebbero andare in tempo. Se le funzionalità non sono sufficientemente elevate per il backlog per arrivare agli sprint prima che possano essere completate in tempo, devono essere portate all'attenzione del proprietario del prodotto in modo che possano stabilire le priorità di conseguenza. Garantire che il backlog possa visualizzare in modo visibile le scadenze per gli articoli o avere un tracker separato per le scadenze che vengono riviste periodicamente durante il grooming sono buoni modi per tenere testa a queste cose. Il proprietario del tuo prodotto lavorerà con te per dare priorità al lavoro per rispettare le scadenze che sono veramente importanti, a volte potresti aver bisogno di perdere una scadenza che hai detto che avresti capito che puoi adattarti così tanto a uno sprint (non lo sono sostenendo di farlo apposta, ma a volte le persone hanno bisogno di una sveglia o le squadre sono eccessivamente drammatiche riguardo le scadenze).
Per quanto riguarda la gestione del debito tecnico, l'unico vero modo che funzionerà è quello di far rispettare la regola del boy scout di migliorare il codice mentre si procede e di fare un calcolo approssimativo. È possibile creare storie di debito puramente tecnologiche, ma è estremamente raro che abbiano mai raggiunto una priorità sufficientemente alta su cui lavorare. Altre opzioni come gli sprint occasionali di manutenzione o l'impostazione di X ore a settimana come ripulitura / tempo libero / allenamento tendono a non funzionare altrettanto bene, poiché ci sarà la pressione per usare quel tempo per lavorare su priorità più alte.