¿Algún tipo de requisito de desarrollo, como "Registrar un nombre de dominio", podría estar en el Backlog del producto?

Sí, los elementos técnicos son elementos perfectamente válidos para el backlog del producto. Generalmente, defino un elemento como un elemento técnico cuando el valor directo no es para el usuario, sino para el equipo de desarrollo. El truco para mí, como Propietario del Producto, es determinar la prioridad de esos elementos. Para una historia de usuario, el valor es visible para el usuario, por lo que puedo usar mi comprensión del usuario (o puedo hablar con los usuarios) para medir el valor. Para elementos técnicos, como refactorizar código o desarrollar pruebas automatizadas, a menudo necesito ayuda del equipo técnico para determinar el valor de ese elemento en relación con otro trabajo.

Una estrategia muy buena para dar a los elementos técnicos lo que se merecen es reservar una pequeña capacidad para elementos técnicos en cada sprint, digamos alrededor del 10%. Esto significa que cuando el equipo comienza a acercarse al final de su capacidad en la Planificación del Sprint, les pido que se detengan un momento, analicen los elementos del backlog técnico y nominen los que les gustaría incluir debido a su valor técnico para los esfuerzos de desarrollo. Esto también ayuda a reducir la deuda técnica con el tiempo. Si haces un poco de trabajo técnico en cada sprint, ayuda a evitar la situación en la que la deuda técnica se vuelve tan abrumadora que ralentiza el equipo hasta detenerlo.

¿Qué piensas? ¿Tiene sentido?

Sí, el backlog es donde reside cualquier cosa que necesite reflexión, pero no durante el sprint actual. Puede contener cualquier cosa que no esté completamente definida o no sea tan importante como las historias/tareas actuales descritas por la gestión de productos o el propietario del producto.

Yo definiría esto como una épica. Para algunos, es un bloque de trabajo que necesita ser considerado, así como desglosado en tareas individuales y todas las tareas están asociadas con algún tipo de historia descrita a partir de la lluvia de ideas de la épica. ¿Tiene sentido? jaja Las primeras oraciones son las mejores.

Aunque, hay directrices para un backlog. No hay realmente nada grabado en piedra que diga no puedes o sí puedes. Es solo una forma de almacenar cosas y no olvidarse de ellas cuando surge la necesidad y/o la carga de trabajo es menor y se pueden hacer cambios o correcciones menores.

Espero que esto te ayude.

@mattaw Gracias por tu respuesta. Además, en uno de los videos mencionaste que cada elemento del Backlog tiene condiciones de aceptación. ¿Está relacionado con el objetivo del Sprint o con el producto final? ¿Podrías dar un ejemplo de esos? Gracias de nuevo.

Supongo que es un arte organizar el proceso :)

Sí, se necesita práctica para mantener el trabajo pendiente y refinar las historias de usuario. ¡Vas por buen camino!

Sí, se necesita práctica para mantener el trabajo pendiente y refinar las historias de usuario. ¡Vas por buen camino!