È una funzionalità.

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

È definito, pianificato e monitorato come qualsiasi altra funzionalità.

Se l'implementazione di questa funzione non è sufficientemente valida (per il cliente o per te) affinché possa essere pianificata, questo è un problema diverso.

(Rimborsare) il debito tecnico è imho non una caratteristica , perché il cliente non è qualificato per prendere decisioni al riguardo . La cosa più importante è che il cliente non può decidere quando è finito, e inoltre il cliente è totalmente dipendente da te per spiegare i benefici. È tuo giudizio che ci sia un debito tecnico, e spetta a te decidere come aggiustarlo e quando hai finito. Il debito tecnico sta influenzando la tua (futura) velocità, non la percezione del software da parte dei clienti. Se non ci fosse debito, saresti più produttivo. E la velocità che hai misurato finora è errata, poiché avresti dovuto impiegare più tempo per mantenere il codice in forma.

Penso che dovresti comunicarlo al tuo cliente, ma non è qualcosa nel loro controllo. Potresti dire qualcosa del tipo: 'Abbiamo preso alcune scorciatoie finora, che dovremo risolvere. Ciò significa che la nostra velocità diminuirà un po 'nelle prossime iterazioni, ma questo è per assicurarsi che abbiamo software gestibile a lungo termine. "

Il lavoro continuo sulla funzione del cliente contribuirà anche a mantenere l'attenzione sul miglioramento del software per il cliente, invece di diventare una sorta di esercizio accademico per trovare il design perfetto (questo è qualcosa con cui talvolta mi trovo a disagio)

IMHO un compito per eliminare il debito tecnico non è sicuramente una caratteristica. Potrebbe essere spinto nel reparto "bug", ma allungherebbe la definizione dei termini, poiché di nuovo non comporterebbe cambiamenti del comportamento osservabili dagli utenti.

Lo chiamerei semplicemente un compito di manutenzione. In qualsiasi progetto di sviluppo ci sono molte attività come l'impostazione di ambiente di sviluppo / test, l'assemblaggio di dati di test, la fusione di rami in SCM, ecc. Nessuno di questi è osservabile direttamente dagli utenti, ma il mancato svolgimento regolare comporta un aumento dello sviluppo costi e frequenza dei bug a lungo termine.

Potrebbe non essere necessario però gestirli come attività separate (a meno che non siano enormi, e / o non sei sotto pressione per implementare nuove funzionalità in questo momento). Di solito, potrebbe essere meglio identificare semplicemente quando una nuova funzione richiede il refactoring / scrittura di unit test, ecc. E gestirli come parte dello sviluppo della nuova funzionalità. Questo potrebbe essere più facile da spiegare sia al management che agli utenti finali (se vogliono sapere su che cosa passi il tuo tempo). Aggiornamento: Inoltre, aiuta gli sviluppatori a concentrarsi anche sul valore del refactoring. È facile farsi trascinare nel refactoring per il refactoring, quindi concentrarsi sul valore aggiunto che un refactoring specifico offre dal punto di vista del cliente è IMHO utile.

Lo chiamerei improvement .

Non un bug perché nulla è rotto.

Né una funzionalità perché il refactoring non sarà una richiesta del tuo cliente. (perché funziona!).

La maggior parte dei sistemi di tracciamento supporta un tipo di problema improvement per impostazione predefinita, altrimenti è possibile modificare i tipi in ogni caso.