¿Cómo manejo una historia de usuario que completo, pero con compromiso y necesidad de volver a visitarla?

Acabo de cumplir (¿es un buen término?) Dos historias de usuarios de un nuevo trabajo atrasado del proyecto que acabo de construir. Estos son el registro de usuario y el restablecimiento de contraseña, ambos requieren correo. Necesito implementar un componente de correo sustituto porque mi elección inicial, y normalmente confiable, no estaba funcionando. Como estaba enfocado en entregar las historias de los usuarios, no en depurar el componente de correo, lo cambié para entregar el código de trabajo al final del sprint. ¿Ahora registro un nuevo problema de soporte para el remitente o "vuelvo a insertar" estas historias en la cartera? Si hago esto último, ¿no estoy introduciendo demasiados detalles tecnológicos en las historias de los usuarios?

Si implementó la historia de usuario con los estándares definidos en la definición de hecho, esas historias de usuario están terminadas y no deberían volver a colocarse en la cartera de productos.

En situaciones similares, he planteado una nueva historia de usuario, pero describí el requisito de realizar un cambio técnico en términos de su beneficio comercial, en lugar de tener algo puramente técnico en la cartera de pedidos del producto. Qué tal si:

"Como desarrollador, quiero que el producto utilice el componente de correo electrónico estándar de la compañía para simplificar el soporte y el mantenimiento".

Como desarrollador, también eres actor y es posible que tengas requisitos para que el sistema se comporte de una manera particular cuando lo uses (soporte / cambio). Siempre debería ser posible articularlos en términos de sus beneficios comerciales y priorizarlos con el propietario de su producto junto con la implementación de una nueva funcionalidad.

Si la definición de hecho para la historia de usuario está completa (completa, lo que desea llamar hecho), entonces su tienda de usuario está completa y no debería volver a ponerla en la lista de pedidos pendientes.

Sin embargo, ha asumido una deuda técnica para completar eso y luego necesita dedicar otro tiempo a solucionarlo. Entonces me parece que necesita un tipo de tarea para el trabajo interno, como los refactores.

Por lo tanto, agregue un nuevo problema a la cartera de pedidos.

La deuda técnica es solo otra historia

Si se hace una historia, eso significa que ha pasado el control de calidad y ha sido aceptada por el propietario del producto.

Cualquier trabajo que deba hacerse para "limpiar" o "mejorar" la implementación se considera Deuda Técnica y simplemente debería ser una nueva Historia.

De esa manera, el Propietario del producto lo rastreará y priorizará como todo lo demás.

La cosa más simple que funcionará razonablemente

En un comentario relacionado , el OP dice:

Mi 'solución' es una solución de calidad, pero la implementación originalmente prevista sería una mejora en la solución, entonces ¿tal vez pueda crear una nueva historia para mejorar la función de correo electrónico?

Si ese es el caso, la pregunta original es discutible. El principio YAGNI requiere que una solución no sea diseñada en exceso en previsión de requisitos futuros.

Si una solución cumple con los objetivos actuales del sprint, funciona según lo diseñado y cumple con la "definición de hecho" del equipo, entonces está listo. No está a medio hacer, más o menos, o "hecho a la espera de una refactorización planificada".

Márquelo hecho y siga adelante.

Advertencia menor

Si realmente cree que hay otra historia allí, o algún tipo de deuda técnica que no impide que se haga la historia original, entonces debe plantear otra historia para la cartera de pedidos del producto .

Siempre se debe colocar un nuevo trabajo en el Backlog del Producto para aumentar la visibilidad , ¡nunca hay trabajo invisible! En última instancia, el trabajo del propietario del producto es decidir si la mejora propuesta se alinea con los objetivos del producto y priorizar su nueva historia de usuario dentro del Backlog del producto si decide agregar la historia.

De acuerdo con su pregunta y comentarios adicionales a la respuesta de @ Klee, creo que el problema es un poco diferente.

Has completado una historia. Debe significar que pasó todas las definiciones de hecho; de lo contrario, la historia del usuario no puede considerarse como completada. Pero si completó la historia y aprobó todas las definiciones de hecho, significa que su solución actual es satisfactoria. De lo contrario, el cliente / propietario del producto debe plantear la razón por la cual no es satisfactorio (no usted) y rechazar su finalización o definir otra historia de usuario que amplíe esta con una nueva definición de hecho que su solución actual no satisfaga.

La deuda técnica se genera solo cuando su solución actual no satisface algún requisito o restricción. ¿Hay alguna restricción que haya violado al usar una solución alternativa? En caso afirmativo, no debe marcar su historia de usuario como completada en primer lugar.

¿Hay alguna duplicación de código u otra mala práctica introducida por su solución? Luego ha creado una deuda técnica y debe resolverla lo antes posible. Puede ser justo con el propietario del producto y simplemente decirle que durante el próximo sprint debe dedicar el mismo tiempo a solucionar sus problemas técnicos, lo que dará como resultado historias de usuarios menos planificadas. O si su relación con el propietario del producto no es muy buena, simplemente planifique menos historias de usuarios debido a las complejidades "recientemente" descubiertas en cualquiera de ellos y arregle su deuda técnica.

Si no hay duplicación de código o alguna razón real por la cual su código debería mejorarse, simplemente no lo toque. Por la razón real me refiero a ninguna restricción definida por el cliente / propietario del producto (por ejemplo, la política de la empresa, el rendimiento, el tiempo predefinido para crear una nueva plantilla de correo electrónico que no se puede lograr con su solución actual, etc.). No hay deudas técnicas en su código. Lo que está tratando de hacer se llama chapado en oro: ofrecer características que no eran necesarias = malgastar los recursos de los clientes.

Si su solución no satisface ninguna historia de usuario futura, simplemente mueva su refactorización y código mejorando a esa historia de usuario. No tiene que resolverse ahora porque pasó la definición actual de hecho. Trate las mejoras cuando tengan que hacerse para pasar la definición de hecho para las historias recién implementadas y para evitar malas prácticas.