Como definir un responsable de una User Story si existen varias sub-tareas con muchos responsables?

[Gonzalo D_Amato]

Estimados. Tengo el siguiente problema: he creado varias historias de usuario y en su interior cree todas las subtareas necesarias para llevar a cabo dicha historias. Por ej:

User Story ---> Login

Sub-task ----> 

1) Maquetado

2) Endpoints login + registro

3) Conexión endpoint con maquetado

4) Diseño casos prueba

5) Ejecución casos prueba

Cada una de estas sub-task tiene a los responsables asignados.

Mi consulta es, quien es el responsable de la HU si son mas de una persona las encargadas de resolverla? Ademas, quien es el encargado de actualizar el estado de la User Story.

Muchas gracias!!

[Guilherme Bragatte]

Hola @Gonzalo D_Amato 

Si me permite compartir la manera de como hacemos acá. Tenemos el mismo cenario, una historia com varias subtareas. Por una definicion del equipo, mantenemos el campo responsable de la HU vacio e hacemos el control solo por el responsible de las subtareas. Utilizamos también algunas automaciones para que la HU "padre" sea movimentada automaticamente por el flujo a depender de los status de las subtareas. Alguns papeles clave, como el PO, actuam solamente en el nivel de HU, y es el responsable por cerrarla, por ejemplo.

Suerte en su proyecto!

[Gonzalo D_Amato]

Hola @Guilherme Bragatte . Muchísimas gracias por la respuesta. La forma en la que abordan el problema me parece correcto, voy a proponerlo. 

Por otro lado, me podrias indicar un poco de informacion sobre las automatizaciones para que la HU padre se mueva automáticamente? 

Además, las estimaciones las manejan a nivel HU o a nivel sub-task (en nuestro caso es a nivel sub-task)

[Guilherme Bragatte]

Hola Gonzalo, 

Por supuesto! Aca usamos algunos tipos de distintos de subissues (como "Dev"y "QA"). Entonces, cada vez que una subtask del tipo "Dev" es cerrada, la automatización haz um check se hay otros subtareas dese tipo que no estan cerradas. Si no hay, el mueve la HU para el status seguiente (Qalidad en nuestro flujo). Muy parecido se pasa com ela tareas de QA.  Mira que hay una "branch" especifica que manipula el item padre, así se puede hacer acciones a partir de los issues "hijos"

Acerca de las estimaciones, nosotros manejamos al nivel de HU. Las subtareas son solamente para una organizacion interno del squad.

[Jorge Martinez]

Hola @Gonzalo D_Amato me parece que esa es mas una pregunta sobre el marco que de Jira en sí.  Idealmente una historia de usuario debería ser: Individual, Negociable, Valiosa, Estimable, Pequeña y Comprobable (Modelo INVEST) y el responsable debería ser la persona encargada de llevar la historia de usuario de Ready a Done. 

Si necesitas tener multiples responsables mapeados en la US dentro de Jira podrias hacerlo creando campos custom, actualizando screens o flujos de trabajo y apalancandote de diferentes roles pero la forma en la que se resuelva al final depende del objetivo que estes buscando o de la informacion que quieras obtener de cada historia. 

[Gonzalo D_Amato]

Hola @Jorge Martinez , gracias por la respuesta. 

En el primer punto estoy en desacuerdo sobre que el responsable de una Historia de Usuario debe ser una unica persona. De por si me parece un tanto inviable conseguir una unica persona que se encargue de diseño, desarrollo, testing e implementaciones.

Entiendo que la la letra I del modelo INVEST se refiere a la independencia de la historia de usuario con respecto a otras. 

Por otro lado me parece una buena idea utilizar campos custom para mapear mas de un responsable por HU.

Saludos! 

[Jorge Martinez]

Claro @Gonzalo D_Amato  y gracias por el feedback.

Creo que en el ciclo de vida de cada historia intervienen muchas personas incluido el equipo de diseño de producto en la definición y el equipo de operaciones en el mantenimiento de producción o release management. Sin embargo es importante que los acuerdos de equipo sean claros sobre el ready y el done para evitar cuellos de botella una vez que se toma una historia de usuario y pueda fluir independiente por el pipeline.

Dependerá de cada contexto, capacidades y tamaño del equipo. Al final lo bueno de la agilidad es poderla adaptar a nuestro entorno y contexto. Espero que con las configuraciones adecuadas logres adaptar la herramienta a tus necesidades y las de tu equipo. 

Un abrazo!