Come gestisco un articolo utente che completo, ma con compromessi e necessità di rivisitare?

Se hai implementato la User story secondo gli standard definiti nella definizione di done, allora queste User story sono finite e non dovrebbero essere rimesse nel backlog del prodotto.

In situazioni simili ho sollevato una nuova user story, ma ho descritto l'esigenza di apportare un cambiamento tecnico in termini di vantaggi per il business, piuttosto che avere qualcosa di puramente tecnico nel backlog del prodotto. Che ne dici di:

"Come sviluppatore, desidero che il prodotto utilizzi il componente di posta elettronica standard dell'azienda per semplificare il supporto e la manutenzione."

Come sviluppatore, anche tu sei un attore e potresti avere dei requisiti che il sistema si comporta in un modo particolare quando lo usi (supportalo / cambia). Dovrebbe essere sempre possibile articolarli in termini di vantaggi per il business e dare la priorità al proprietario del prodotto insieme all'implementazione di nuove funzionalità.

Se la definizione di done per la user story è fullfiled (fullfilled, ciò che ogni utente desidera chiamare fatto) allora il tuo user store è completo e non dovresti reinserirlo nel backlog.

Tuttavia hai assunto il debito tecnico per completarlo e in seguito devi dedicare altro tempo a risolverlo. Quindi mi sembra che tu abbia bisogno di un tipo di compito per il lavoro interno come i refactories.

Quindi aggiungi un nuovo problema nel backlog.

Il debito tecnico è solo un'altra storia

Se una storia è fatta significa che ha superato il controllo di qualità ed è stata accettata dal proprietario del prodotto.

Qualsiasi lavoro che potrebbe essere necessario per "ripulire" o "migliorare" l'implementazione è considerato Debito tecnico e dovrebbe semplicemente essere una nuova storia.

In questo modo verrà monitorato e definito come prioritario dal Product Owner esattamente come tutto il resto.

La cosa più semplice che funzioni ragionevolmente

In a commento correlato , l'OP dice:

My 'workaround' is a quality solution, but the originally envisaged implementation will be an improvement on the workaround, so maybe I can create a new story to improve the email function?

Se è così, la domanda originale è discutibile. Il principio YAGNI richiede che una soluzione non sia sovra-ingegnerizzata in previsione di requisiti futuri.

Se una soluzione soddisfa gli attuali obiettivi di sprint, funzioni come progettate e soddisfa la "definizione di fatto" del team, allora è fatto. Non è un mezzo fatto, una sorta di fatto, o "fatto in attesa di un refactoring pianificato".

Contrassegnalo e prosegui.

Minota avvertenza

Se ritieni sinceramente che ci sia un'altra storia lì, o una sorta di debito tecnico che non impedisce la storia originale, allora dovresti creare un'altra storia per il Product Backlog .

Il nuovo lavoro deve sempre essere inserito nel Product Backlog per aumentare la visibilità - nessun lavoro invisibile, mai! In definitiva, è compito del Product Owner decidere se il miglioramento proposto si allinea al prodotto obiettivi, e per dare priorità alla tua nuova user story all'interno del Product Backlog se sceglie di aggiungere la storia.

Secondo la tua domanda e i commenti aggiuntivi alla risposta di @ Klee, penso che il problema sia un po 'diverso.

Hai completato una storia. Significa che hai passato tutte le definizioni di fatto, altrimenti la user story non può essere considerata completata. Ma se hai completato la storia e passato tutte le definizioni di fatto dovrebbe significare che la tua soluzione attuale è soddisfacente. In caso contrario, il proprietario del cliente / prodotto deve aumentare il motivo per cui non è soddisfacente (non tu) e rifiutare il completamento o definire un'altra storia utente estendendola con una nuova definizione di completamento che non è soddisfatta dalla soluzione corrente.

Il debito tecnico viene generato solo quando la tua soluzione corrente non soddisfa alcuni requisiti o vincoli. C'è qualche vincolo che hai violato usando una soluzione alternativa? Se sì, non dovresti contrassegnare la tua user story come completata in primo luogo.

C'è qualche duplicazione di codice o un'altra cattiva pratica introdotta dalla tua soluzione alternativa? Quindi hai creato un debito tecnico e dovresti risolverlo il prima possibile. Puoi essere equo con il proprietario del prodotto e dirgli semplicemente che durante il prossimo sprint devi passare lo stesso tempo a risolvere i tuoi problemi tecnici che si tradurranno in storie utente meno pianificate. O se la tua relazione con il proprietario del prodotto non è molto buona, pianifica meno storie utente a causa di "nuove" scoperte complessità in ognuna di esse e correggi il tuo debito tecnico.

Se non vi è alcuna duplicazione di codice o una vera ragione per cui il tuo codice dovrebbe essere migliorato, semplicemente non toccarlo. Per il vero motivo, intendo nessun vincolo definito dal cliente / proprietario del prodotto (ad esempio politica aziendale, prestazioni, tempo predefinito per la creazione di un nuovo modello di posta elettronica che non può essere raggiunto con la soluzione corrente, ecc.). Non c'è debito tecnico nel tuo codice. Quello che stai cercando di fare è chiamato golden plating - fornire funzionalità che non erano necessarie = sprecare risorse per i clienti.

Se la tua soluzione non soddisferà alcuna storia utente futura, sposta semplicemente il tuo refactoring e il codice in miglioramento in quella user story. Non deve essere risolto ora perché ha superato la definizione corrente di fatto. Affrontare i miglioramenti quando devono essere fatti per passare la definizione di fatto per le storie appena implementate e per evitare le cattive pratiche.