Se parli di un singolo prodotto / progetto e un singolo pool di sviluppatori, vorrei strongmente consigliare di avere solo un backlog del prodotto con tutti gli elementi che hai menzionato inclusi. Avere due arretrati sarà un incubo dell'amministratore, e immagino che tu e il proprietario del prodotto combatterete per far funzionare le risorse sui vostri rispettivi backlog.
Se le tue storie utente sono espresse in termini di valore commerciale, non dovresti avere problemi a farle pianificare in sprint. Attualmente sono scrum master su un progetto con user story come:
- Come sviluppatore, voglio rinominare tabelle e colonne per riflettere un recente cambiamento nella terminologia aziendale in modo che sia facile per i nuovi sviluppatori capire il sistema.
- Come sviluppatore, voglio implementare una registrazione degli errori migliorata in modo da poter diagnosticare più facilmente i problemi segnalati.
- Come amministratore di sistema voglio che gli errori spuri che riempiono i log del sistema vengano eliminati in modo che il rumore del registro non mi impedisca di identificare i problemi.
Se il proprietario del tuo prodotto si rifiuta ancora di includere uno di questi in uno sprint anche se espresso in linguaggio non tecnico e in termini di vantaggi aziendali, allora forse hai il proprietario del prodotto sbagliato.
Se ti trovi in quella posizione infelice ma non sei in grado di cambiare il proprietario del prodotto potrebbe essere utile ricordare loro che ogni sistema ha bisogno di manutenzione. Ho anche trovato la descrizione del concetto di debito tecnico , e di come debba sempre essere ripagato ad un certo punto, un utile analogia.
Infine, potresti scoprire che alcuni di questi punti tecnici più fini che non sono attualmente in fase di esecuzione dovrebbero in realtà essere parte dell'implementazione delle funzionalità richieste dal proprietario del tuo prodotto. Basandomi su alcuni dei tuoi esempi sopra, direi che la user story per implementare l'animazione di avvio non è stata completata correttamente se ha "stranezze", sia visibili che non. Allo stesso modo, se si dispone di standard per le metriche di analisi del codice statico, una storia utente dovrebbe essere considerata eseguita solo se lo sviluppatore ha utilizzato Lint per misurare tali parametri e ha dimostrato che il codice soddisfa i propri standard. Se questi sono standard generici dovrebbero essere nella definizione di fatto . Se sono punti specifici della storia dell'utente, possono essere condizioni di accettazione nella trama dell'utente.