Jira Agile y Scrum, cómo combinarlos de manera correcta (4/4): Incidencias y artefactos Scrum

Enlaces a los demás posts de la serie: 
https://www.javiergarzas.com/2014/07/jira-agile-scrum-1.html
https://www.javiergarzas.com/2014/07/jira-agile-scrum-2.html
https://www.javiergarzas.com/2014/07/jira-agile-scrum-3.html
Una vez aclarado el concepto de incidencia de JIRA en el anterior post “Jira y la agilidad, cómo combinarlos de manera correcta (3/4): Profundizando en incidencias”, nos centraremos las incidencias de JIRA Agile y los artefactos de Scrum, a la hora de explicar conceptos de JIRA Agile iremos de mayor a menor nivel de abstracción.

Epopeyas en JIRA Agile

Las epopeyas se utilizan para representar una historia de usuario más grande, que debe desglosarse, sigue el mismo formato que una historia de usuario pero su alcance es mayor. Las epopeyas nos podrían llevar más de un Sprint, por lo que son para una visión a largo plazo.
Cuando creamos una incidencia en JIRA Agile de tipo epopeya no aparece en el Backlog como una incidencia más, sino que aparece en el margen izquierdo.
A la hora de asignar incidencias a una epopeya, en la creación de la incidencia según vimos en el post anterior, nos encontramos con un campo que nos permite indicar a que epopeya pertenece.
Las incidencias que pertenecen a una epopeya, sí que aparece en el Backlog principal con las demás. Os dejamos una imagen en la que podemos ver que la incidencia de tipo historia con identificador SI-12 pertenece a la epopeya de Adaptación y aparece en el Backlog.
Backlog y epopeya
Para no tener dudas respecto a las epopeyas  hay que tener en cuenta que pueden tener otro tipo de incidencias, no solo incidencias de tipo historia. Es importante tener en cuenta que las epopeyas no pueden tener vinculadas otras epopeyas.

Historias de usuario en JIRA Agile

Se debe destacar que solo las incidencias de tipo historia representan historias de usuario.
Como se describe en  “Gestión de proyectos ágil”, éstas tienen un papel muy importante en la metodología Scrum, ya que evolucionan según avanza el proyecto. Son peticiones concretas y pequeñas y sobre todo porque contienen información imprescindible.
El anterior libro indica que las historias de usuario deben ser pequeñas, memorizables y que puedan ser desarrolladas por un par de programadores en una semana.
Según se explica en el libro “User Stories Applied: For Agile Software Development”, las historias de usuario son una descripción breve de la funcionalidad software, tal y como la percibe el usuario.
Una de las características principales de las historias de usuario es la parte de la conversación, la cual también diferencia las historias de usuario de una especificación de requisitos.
A la hora de crear incidencias de tipo historia en JIRA Agile, debemos tener presente que en las empresas que no se utiliza ninguna herramienta para la gestión de incidencias, las historias de usuario se representan normalmente en pósit. Tienen tres partes:
– La creación de la tarjeta, que en JIRA Agile se representa con el resumen de la incidencia de tipo historia.
– La conversación que en los pósit se representa en la parte de atrás. En JIRA Agile se representa en la descripción de la incidencia.
– La confirmación que en JIRA Agile tiene lugar en la descripción señalando las pruebas necesarias para comprobar que se ha realizado correctamente.
Si usamos otro tipo de incidencias en el proyecto Scrum de JIRA Agile, se debe mantener la trazabilidad con las historias de usuario.
Para ello desde las opciones de administrador de JIRA Agile, se debe crear un nuevo campo que sea un cuadro de texto que aparezca a la hora de crear incidencias, recibiendo la URL de la historia de usuario con la que está relacionada esta incidencia.
Con las siguientes imágenes mostramos un sencillo ejemplo.
Dependencias (2)
Dependencia-1
En esta última imagen se puede ver como la incidencia de tipo historia depende de la historia con clave SI-12. Aunque en este ejemplo se utilice dependencia entre historias de usuario, también en JIRA Agile podemos indicar la dependencia de otro tipo de incidencias.

Historias Técnica en JIRA Agile

Como se describe en el libro “Gestión de proyectos ágil” son un tipo de historias de usuario pero carecen de interés para el cliente.
En JIRA Agile las historias técnicas son las otras incidencias, que no son de tipo historia, ni las subtareas de tipo tareas técnicas.

Tareas en JIRA Agile

Una cuestión que no está clara como vemos en algunos foros, es sobre las tareas de Scrum.
Aunque otros tipos de incidencia también pueden contener subtareas, solamente las subtareas de tipo tarea técnica de una incidencia de tipo historia representan las tareas de Scrum.
Una subtarea que es parte de una historia, es una parte realizable que representa los elementos de trabajo necesarios para implementar la historia, lo que en agilidad son las tareas que conforman el Sprint Backlog.
Cuando todas las tareas de una historia terminen, se podrá cambiar el estado de la historia.
Se debe tener especial cuidado, ya que lo que llamamos Sprint en JIRA no es el Sprint Backlog de Scrum, porque no almacena las tareas de las incidencias, sino que en su interior están las incidencias que se realizarán en esa iteración.
Las tareas describen como el equipo va a implementar las historias de usuario del Product Backlog. Son cosas muy concretas a realizar durante una iteración, con el objetivo de completar una historia de usuario.
Como ya mencionamos en los primeros post de esta serie, en JIRA Agile, si creamos una subtarea que desciende de una historia de usuario, no se verá en la planificación de la pizarra, sino que se verá dentro de los detalles de la historia de usuario. Desde ese mismo lugar también se pueden crean las subtareas.
Subtareas
 
Volvemos a señalar que la manera de gestionar una tarea en JIRA de forma adecuada, es que para representar las tareas de Scrum se utilicen las subtareas de tipo tarea técnica, y las incidencias que no son de tipo historia también pueden tener subtareas,  pero serán del tipo subtareas.
Sin embargo a la hora de trabajar con las incidencias, es decir, de poner en marcha el tablero Scrum, aparecerán las tareas que componen las historias de usuario y no éstas como tal. Vemos una imagen sobre esto.
Tablero con tareas

Confusiones frecuentes en JIRA Agile

– Las incidencias de tipo tarea dentro de JIRA Agile, no son tareas de Scrum porque éstas tienen que componer una historia de usuario y una incidencia de tipo tarea no compondría ninguna historia de usuario. No nos permitiría gestionar las historias de usuario a través de las tareas, por eso las tareas de Scrum, en Jira Agile, son las incidencias de tipo subtareas que descienden de una incidencia de tipo historia de usuario.
– Poner las tareas como descripción dentro de una historia de usuario. Esta práctica no es correcta ya que las tareas Scrum componen las historias de usuario, es decir, en JIRA Agile tienen que ser otro tipo de incidencias que desciendan de una incidencia de tipo Historia. Tienen que ser subtareas de tipo tarea técnica.
Si se pone las tareas como descripción de una incidencia de tipo Historia, éstas no se podrán gestionar en JIRA Agile, no se podrán mover en el tablero y tratar como incidencias separadas, que es como deben tratarse aunque formen parte de una incidencia mayor de tipo Historia, tienen que poder tratarse como una incidencia ya que representan trabajo a realizar.
Se debe dejar la descripción para apuntar la trazabilidad entre las incidencias, y pequeños apuntes sobre la incidencia.
Hasta aquí la primera entrega de estos 4 posts sobre cómo aplicar Scrum en JIRA Agile con los elementos más básicos y sus buenas prácticas.

Javier Garzás

12 comentarios en “Jira Agile y Scrum, cómo combinarlos de manera correcta (4/4): Incidencias y artefactos Scrum”

  1. Excelente! Muchas gracias.
    Tengo una duda, que sucede con las estimaciones en las subtareas, queremos agregar las horas que demorará aproximadamente, pero al parecer no es posible.
    Saludos.

  2. Fantástico post. Pero tengo una duda: la versión de Jira que estoy usando (v7.0.9) aparentemente no dispone del tipo «tarea técnica» entre los tipos de subtareas; únicamente dispongo del tipo «subtarea». Y por otra parte el icono de las incidencias de tipo Historia es distinto al mostrado en las pantallas del post. ¿puede ser que ésto haya cambiado desde la versión cuando se hizo el post? ¿corresponden quizás ahora las subtareas de tipo subtarea con las tareas de scrum, al no existir el tipo «tarea técnica»? Gracias de antemano.

  3. Hola javier.
    Muy bueno tu post, tengo una consulta, si una Historia de Usuario comprende muchas tareas, las cuales tienen una valoracion especifica.
    Como debo de valorar la Historia de Usuario propiamente dicha.
    Agradecere tus comentarios.

    1. Hola Belinda,

      si no quieres «duplicar» el valor de puntos del sprint, tendrás que omitir la estimación de la historia propiamente dicha.

      Un saludo
      Jorge.

  4. Estupendo post, muy útil!
    Tengo una duda sobre la gestión épicas o epopeyas. Cuando marcas una épica como «listo» en la pizarra scrum, esta desaparece de trabajo pendiente. Si en algún momento es necesario añadir una nueva historia/tarea a la épica, hay alguna forma de revertir el estado «listo» para poder visualizar de nuevo la épica?
    Muchas gracias

  5. Hola Consulta en que momento debo dejar las incidencias en ready? antes de inicial el sprint? o iniciado el sprint a medida que se van tomando colocarlas en ready? o inicio el sprint y las paso todas a ready?
    Gracias

  6. Hola Javier
    Muchas gracias por el post. Aclara muchas dudas.
    Sin embargo, discrepo en una cosa. Jira Agile no tiene en cuenta a las subtareas para formar el Burndown Chart y las desprecia porque «no aportan funcionalidad al usuario final». Sin embargo, para dar visibilidad al trabajo del equipo y ser más acorde a la realidad, me interesa reflejar los avances en el Burndown Chart y no puedo esperar a completar la historia de usuario completa. Además, de esta forma se monta una gráfica demasiado escalonada y yo busco algo más lineal y realista. La solución por la que opto es «subir» el nivel de las subtareas a Tasks y las igualo al nivel de Historia (aunque conceptualmente no sea correcto). De esta forma a medida que se van completando tareas se va reflejando en el Burndown.
    No quiero decir que mi forma sea la correcta ni más correcta que la que indicas, simplemente es la opción que he tomado para resolver el problema del Burndown.
    Acepto sugerencias 🙂
    Un saludo
    Jorge.

    1. Daniel Mazzitelli

      Hola Javier:

      Este es un tema delicado y como todo en Agile va a depender de la autogestión del equipo y de cómo se vaya sintiendo más cómodo. De todos modos, hay pautas que debemos respetar dentro del marco de trabajo para que la metodología esté aplicada de manera más precisa y no se aleje de las buenas prácticas. Dicho esto, te cuento que nosotros utilizamos el tablero en nuestras dailys y nos resulta muy cómodo que las subtareas «cuelguen» de la historia de usuario ya que las tenemos a todas colapsadas y llegado el momento de ir siguiendo la reunión vamos descolapsando y enfocando de a una. El peso de las subtareas en JIRA no se duplican con el de la historia, por lo que estimamos «TODO». La gráfica que nos gusta ver al final del Sprint, es una gráfica que haya ido entregando valor en el medio del Sprint y cerca del final. Eso le dá al equipo de QA la posibilidad de trabajar desde la mitad de la iteración y que no se acumule todo el riesgo de una entrega voluminosa al final.

      Espero haberte aportado.
      Saludos,
      Daniel

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba