En Scrum, ¿debería dividir el trabajo atrasado en un trabajo atrasado funcional y un trabajo atrasado técnico o no?

En nuestros equipos Scrum utilizamos una cartera de pedidos, que en su mayoría contiene temas funcionales, pero también a veces contiene temas técnicos. La ventaja de tener 1 retraso es que es fácil elegir los temas para el próximo sprint, pero tengo algunas preguntas:

• Primero, a mí me parece más lógico tener una acumulación técnica separada, donde los propios desarrolladores pueden agregar elementos técnicos puros, como: podríamos mejorar el rendimiento en este método, esta clase carece de documentación técnica, ... Al tener una acumulación, todos los desarrolladores siempre tienen que pasar por el propietario del producto para que sus temas se agreguen al trabajo atrasado, lo que parece un trabajo adicional e innecesario para el propietario del producto.
• En segundo lugar, si tiene un propietario del producto que solo se enfoca en los elementos puramente funcionales, los elementos puramente técnicos (como la documentación técnica faltante, el código que se erosiona y debe ser refactorizado, clases que siempre dan problemas durante la depuración porque no tienen una base estable y debe ser refactorizada, ...) siempre termina al final de la lista porque "no sirven al cliente directamente". Al tener una cartera técnica separada y un tiempo reservado en cada sprint para estos elementos técnicos puros, podemos mejorar funcionalmente las aplicaciones, pero también mantenerlas saludables por dentro.

¿Cuál es el mejor enfoque? ¿Uno o dos atrasados?

No soy un experto, pero diría que solo puede tener una acumulación por equipo. El equipo debe decidir qué problemas son urgentes y cuáles pueden posponerse. Si separa los problemas en tipos separados de pilas, va en contra de la idea central que está en el corazón del scrum, que es que hay un grupo de problemas y cada sprint en el que trabaja el equipo más urgente. Si usted (sub) divide los equipos, podría dividir los tipos de tareas que son relevantes para ellos, pero básicamente estaría creando equipos que trabajan en paralelo. La urgencia / necesidad es la decisión número uno a la hora de planificar el próximo sprint. Puede clasificar las tareas, pero esto no debería interferir en su proceso de decisión.

Me gustaría agregar mi voz a aquellos que recomiendan una acumulación por producto. Crear otra cartera de pedidos es una respuesta racional, pero en realidad solo está evitando el problema central: ¿por qué el propietario del producto no prioriza los elementos técnicos sobre los elementos de características? Debes concentrarte en resolver esto en lugar de solucionarlo. Podrías usar la técnica 5 Whys , por ejemplo, para tratar de llegar al fondo de las cosas.

Podría haber muchas razones por las cuales el PO no prioriza los problemas técnicos. Por ejemplo, tal vez el equipo técnico no está explicando el costo a largo plazo (en $$$) de no abordar la deuda técnica. Tal vez es algo completamente diferente. Existe una buena posibilidad de que se deba a un problema de comunicación, y la solución a largo plazo es trabajar en ello y resolverlo, eliminar el impedimento.

Además, tengo otra pregunta para que piense: ¿Por qué surgió la deuda técnica en primer lugar? Idealmente, el trabajo como la refactorización, etc., debe realizarse dentro de las historias funcionales y completarse dentro del sprint. No deberían ser historias adicionales por derecho propio, de lo contrario, no tiene un código potencialmente enviable.

A lo que se refiere es comúnmente llamado 'deuda técnica'. A veces puede ser difícil ver cómo el trabajo de la deuda técnica encaja en el proceso scrum, de la misma manera que los defectos.

Lo que está proponiendo es similar a sugerir que también haya una 'acumulación de defectos' separada, dividiendo la acumulación en 3.

Personalmente, no recomendaría dividir la cartera de productos en absoluto. La idea del trabajo atrasado del producto es representar elementos de trabajo sobresalientes . Desde esa perspectiva, la única diferencia entre una característica y un elemento de deuda técnica es que el requisito provino del equipo de desarrollo, no del cliente. Sigue siendo un elemento de trabajo y aún debe gestionarse, incluida la priorización frente a otros elementos de trabajo. Esto es especialmente cierto si el elemento de deuda técnica requiere pruebas, en cuyo caso debe pasar exactamente por el mismo proceso de control de calidad que una característica normal.

Estoy de acuerdo con Onno en que solo debe haber una sola acumulación por proyecto. De lo contrario, el equipo básicamente está tomando en sus propias manos algunas decisiones que legítimamente pertenecen al propietario del producto.

Incluso los artículos "puramente técnicos" deben tener algún valor práctico para que los usuarios (y, por lo tanto, para el propietario del producto) sean elegibles para el retraso del sprint. Es su tarea explicar el beneficio de estos al propietario del producto y convencerlo del valor agregado que justifica el costo. Y este proceso te obliga a pensar en estos problemas y seleccionar los cambios técnicos que aportan el mayor valor al proyecto con el menor esfuerzo.

Estoy de acuerdo con todas las respuestas anteriores. En plena realidad comercial, la OP seguirá priorizando las historias funcionales sobre las técnicas. A menudo ante la frustración del equipo. El equipo debe abstenerse de historias técnicas sin ningún valor para el usuario (¿a quién le importa una optimización, si la velocidad no es un problema?) Y aprender a ver ciertas otras tareas técnicas como lo implican las historias funcionales. La "definición de hecho" también juega un papel importante. Las historias funcionales restantes van al atraso para que el PO priorice.

Por ejemplo, documentación técnica: la disponibilidad de documentación técnica (cuando corresponda) es un elemento típico que pertenece al Departamento de Defensa y, por lo tanto, la actualización se IMPLICA con cada historia funcional.

Ej. Código de refactorización: debe hacerse cuando beneficia el desarrollo del producto. No antes (el equipo no debe asumir en qué dirección evolucionará el producto) y no más tarde cuando ya se ha convertido en deuda técnica. Tener el diseño revisado también podría ser parte del Departamento de Defensa.

Estoy de acuerdo con MelR. Si hay algo que sea 'técnico', debemos analizar por qué lo estamos haciendo, ¿o incluso cuál es la causa y el efecto a corto y largo plazo (para el usuario)?

He visto muchos atrasos en los que las llamadas "tareas técnicas" se pueden escribir fácilmente en una forma de valor comercial.

Las tareas técnicas también suelen ser el resultado de grandes historias desglosadas, ya que puede ser la forma más fácil de desglosar las cosas. Pero esto puede causar iteraciones más lentas del verdadero valor agregado (u oportunidades de retroalimentación) o incluso peor, el fracaso de los sprints.

Con respecto al "código que se erosiona y debe ser refactorizado", como Patrick menciona, creo que debemos preguntarnos: ¿qué área de la funcionalidad del sistema está afectando ese código? ¿Y cuál es el efecto a largo plazo en el usuario si no lo refactorizamos ahora?

Luego está el tema de "dejar las cosas un poco mejor de cómo lo encontramos" para reducir la deuda técnica a largo plazo y ¿se puede hacer esto como parte de las pequeñas historias en cada sprint sin demasiado impacto en el proyecto más amplio?

En última instancia, no veo la necesidad de dos atrasos, esto abre la oportunidad de frenar las necesidades priorizadas adecuadamente, pero existe la necesidad de un propietario del producto que esté educado en las preocupaciones de los impactos técnicos y tenga una gran capacidad para identificar el verdadero valor. para desglosar historias verticalmente: Adobe ofrece una buena explicación sobre el corte vertical .

No, nunca debes crear historias técnicas. Este es un error común. Sus historias deben reflejar el requisito comercial. Las cosas técnicas nunca provienen realmente de requisitos comerciales. Este es el rol del scrum master y del equipo para evaluar todas las tareas técnicas que tendrán que hacer para alcanzar el objetivo o la historia.

Si su historia trata sobre la creación de una pantalla de inicio de sesión, por ejemplo, también deberá considerar la creación de la base de datos si aún no se ha creado.

No veo el problema para crear, con el PO, tareas donde el equipo de TI es el usuario. Si el PO puede entender la tarea y puede evaluarse en términos de valor comercial, entonces sí tiene una manera de crear historias técnicas. Solo usas el sistema.