va bene che il team di sviluppo crei attività di refactoring nel backlog del prodotto?

Nell'ambito di Scrum, ogni stakeholder qualsiasi può introdurre nuovi elementi di backlog in qualsiasi momento. Poiché il team è anche uno stakeholder, possono anche inserire elementi arretrati.

Il principale rischio con gli elementi del backlog del team di sviluppo è che, nella mia esperienza, tendono ad usare un linguaggio piuttosto tecnico. Questo può rendere difficile per il proprietario del prodotto vedere il valore commerciale di tali storie e far sì che a loro venga data una bassa priorità.
Se il team vuole inserire un articolo arretrato, dovrebbe sforzarsi di scriverlo in termini comprensibili per l'ordine di acquisto e preferibilmente anche per il cliente e indicare il vantaggio che il cliente otterrebbe al termine del lavoro proposto. Ciò aumenta la possibilità che il valore aggiunto venga riconosciuto correttamente.

A volte vale la pena ricordare che le regole dello sviluppo basato sulla mischia non sono scolpite nella pietra accanto a un cespuglio fiammeggiante.

Sono una struttura per determinati tipi di sviluppo del software che si sono rivelati utili. Sono davvero utili per inquadrare le interazioni tra le parti interessate nel processo del software.

A volte, però, non sono abbastanza adeguati per quello di cui hai bisogno. Una volta accettato, il problema, più o meno, si risolve da solo.

Nel tuo caso, il mio suggerimento sarebbe questo. Scrivi un articolo sul perché vuoi refactoring e uno schema per quello che vuoi fare.

Una cosa fondamentale è fare il caso. Hai delineato alcuni elementi nella tua domanda: consegna lenta di funzionalità, manutenibilità. Questo genere di cose. Questi sono affari che riguardano problemi. Nel mio mondo, mi sarei aspettato metriche qui, ad es. Conteggio errori o andamento delle consegne. YMMV.

Avrei anche incluso uno schema del refactoring coinvolto e qualche idea del costo complessivo e di come si desidera avvicinarsi al refactoring, ad es. attività esplicite, estensioni per funzioni o combinazione di entrambi.

Con questo in mano, ti siedi con le parti interessate e spieghi il problema e la soluzione proposta. O il caso è fatto e tu includi il refactoring o non lo è e tu no. Il requisito fondamentale è che la comunicazione sia trasparente con tutte le parti interessate.

Consiglio vivamente di includere le consegne effettive come parte del normale processo di sprint. Ciò potrebbe significare dover pensare in modo abbastanza creativo a come si riducono le modifiche al codice. Fondamentalmente, scrum funziona perché normalizza la comunicazione, quindi si desidera tornare ai processi ben compresi al più presto. Non è sempre possibile, ma più fai fuori le cose più rischiose e più hai bisogno di cure.

Scrum si concentra sul raggiungimento dei compiti del backlog. Non importa chi li scrive finché l'ordine di priorità li assegna.

Tuttavia. In pratica, se metti solo nuove funzionalità nel backlog, il tuo codice diventerà più "hacky" nel tempo. Come scrum, giustamente, si concentra sul raggiungimento dell'obiettivo il più rapidamente possibile.

Se, il refactoring mentre procedi e il rallentamento delle nuove funzionalità paga rispetto al crescente aumento dei costi associati all'aggiunta di funzionalità mentre il sistema diventa più complesso è una domanda difficile.

Ma ancora più importante è una domanda di lavoro. Devi essere sicuro che chi paga i salari degli sviluppatori sia felice che sia stato raggiunto il giusto equilibrio.

Calcola quanto tempo ci si aspetta che il prodotto sia in servizio e prova a farti un'idea della portata totale delle funzionalità che alla fine avranno. Questo guiderà te e gli sviluppatori nel decidere cosa dovrebbe e non dovrebbe essere sottoposto a refactoring