Tengo una pregunta de novato. Supongamos que para una acumulación de sprint elegimos una historia de usuario de la acumulación de productos: "Como adicto a la fotografía, quiero poder hacer una colección de fotos favoritas".
Y luego queremos agregar algunas tareas más detalladas, por ejemplo, "hacer una maqueta" para los diseñadores de UX, "hacer cambios en el modelo" para los desarrolladores de back-end y hacer la implementación de ideas de diseño en el front-end.
Entonces, ¿cuál es la mejor práctica para eso? ¿Agregamos estas subtareas a la acumulación de sprint, o creamos una acumulación de "tareas detalladas" por separado? ¿Agregamos puntos de historia a cada subtarea?
Con los puntos de historias es un problema especialmente interesante, porque si agregamos subtareas al backlog del sprint, estamos contando tareas dos veces: primero para la historia de usuario en general y segundo para sus partes en forma de subtareas.
Para capturar el trabajo técnico que se necesita para completar una historia, se crean tareas que están debajo o son parte de la historia.
Si su herramienta no admite la creación de subtareas para una historia, puede escribir esas tareas como una lista con viñetas en la descripción de la historia.
En cualquier caso, estas tareas técnicas no son elementos del backlog y, por lo tanto, no se agregan ni al producto ni al backlog del sprint. Cuando se agrega una historia a un sprint, las tareas de esa historia vienen automáticamente con ella.
En cuanto a la estimación, algunos equipos hacen una estimación en horas de las tareas de las historias que se añadieron al sprint durante la planificación para comprobar que ninguna disciplina dentro del equipo se sobrecarga de trabajo. Este tipo de estimación es completamente opcional y es independiente de las estimaciones de puntos de la historia de las historias en sí.
El Sprint Backlog es el conjunto de elementos del Product Backlog seleccionados para el Sprint, más un plan para entregar el Incremento del producto y alcanzar el Sprint Goal.
Las historias de usuario son una técnica posible, no un requisito, para expresar los elementos de la cartera de productos (PBI). Si usa puntos de historia, generalmente no se adjuntan a nada por debajo del PBI. Los PBI seleccionados son pronosticados (no prometidos ni comprometidos) por el Equipo de Desarrollo y el plan solo necesita ser tan granular como lo necesite el Equipo de Desarrollo.
El trabajo planificado para los primeros días del Sprint por el Equipo de Desarrollo se descompone al final de esta reunión. (Planificación de Sprint)
El Equipo de Desarrollo modifica el Sprint Backlog a lo largo del Sprint, y el Sprint Backlog emerge durante el Sprint.
El Sprint Backlog... pertenece únicamente al Equipo de Desarrollo.
La respuesta a cómo se divide el trabajo es algo que debe determinar el Equipo de Desarrollo: la autoorganización. La creación de tareas es una técnica posible, no un requisito, para descomponer el trabajo. No todos los PBI seleccionados deben descomponerse en Sprint Planning, solo los primeros días de trabajo: responder al cambio sobre seguir un plan ( Manifiesto para el desarrollo ágil de software ).
Scrum no reconoce títulos para los miembros del Equipo de Desarrollo que no sean Desarrollador, independientemente del trabajo que realice la persona; No hay excepciones para esta regla.
Pensar y ejecutar en términos de desarrollador front-end, desarrollador back-end, probador, escritor técnico, etc. es un indicador de una oportunidad de mejora. ( Gente de goteo de pintura )
Puede utilizar los criterios INVEST para decidir qué constituye una historia de usuario.
Los ejemplos que dio, "hacer una maqueta" y "hacer cambios en el modelo" no brindan valor al usuario final. Entonces, no son historias.
Si tiene dificultades para dividir una historia, puede usar las técnicas SPIDR de Mike Cohn .
El detalle adicional (y las tareas asociadas con él) debe dilucidarse antes de la planificación de Sprint, durante las sesiones regulares de preparación de tareas pendientes.
Si espera hasta la planificación del Sprint o más tarde para definir lo que realmente hará para entregar una historia, ya estará a la defensiva. ¿Qué pasa si se da cuenta después de haber comenzado el Sprint de que es demasiado trabajo para completarlo o que hay es un bloqueador significativo para el progreso?
Su equipo solo debe trabajar a partir de un trabajo pendiente; de lo contrario, la priorización se convierte en un problema.
Puede capturar puntos de la historia en el nivel más amplio de la historia o en el nivel de "subtarea" más pequeña. Evitaría agregar puntos de historia en el nivel de subtarea si ya se han asignado a una tarea principal, simplemente por el riesgo de contar dos veces. Si su historia principal es grande, el equipo (y la empresa en su conjunto) no parecerá estar progresando hasta el final; los resultados más pequeños hacen que sea más fácil mostrar el progreso.
También encontrará que el software que utiliza para administrar las historias influirá en la forma en que las estructura, ya que existen ciertos enfoques que se adaptarán mejor al software.
RibaldEddie