Una de las principales labores a realizar cuando gestionamos desarrollos usando Scrum es la gestión del backlog. En este post veremos cómo se usa Jira para este propósito.
Que es un Backlog
Según la definición de scrum.org
Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product (Product Backlog – scrum.org)
Es una lista ordenada de todas las cosas que podría necesitarse en el producto y la única fuente de requerimientos para cualquier cambio a ser realizado al producto
En la práctica un Backlog contiene todo lo que puede o podría ser necesario para desarrollar un producto y además tareas que de una manera u otra impacta al equipo de desarrollo. Aunque el backlog debe ser mantenido y priorizado por el Product Owner (PO), no necesariamente es el único involucrado en la entrada de items, el equipo de desarrollo puede realizar entradas para reflejar necesidades detectadas, incidencias a resolver en otros sprints, etc. El ordenamiento y priorización de los Items es realizado de manera constante por el PO y los elementos superiores del mismo son los candidatos a incluir en el siguiente sprint y deben estar más refinados que el resto.
En el backlog podemos encontrar:
- Épicas: Peticiones sobre el producto de alta complejidad que suelen ser descompuestas en Historias de usuario. Por ejemplo, el desarrollo de un módulo X con más de una funcionalidad.
- Historias de Usuario: Petición sobre el producto cuyo desarrollo puede encajarse en un sprint. Si no puede hacerse en un sprint debe descomponerse.
- Tareas: Tareas asociadas al producto que no necesariamente son historias de usuario, pero que requieren ser realizadas dentro del marco del desarrollo del producto. Por ejemplo, instalación de un software, documentación, despliegues, nuevas instalaciones, etc.
- Incidencias: Incidencias detectadas en el producto que deben ser priorizadas para su resolución dentro de un ciclo de vida de producto.
TIP: Es importante hacer mantenimiento al backlog cada cierto tiempo debido a que pueden generarse items duplicados, obsoletos por tiempo o por descarte de negocio, tareas no priorizadas adecuadamente, etc.
Vista de Backlog y Épicas en Jira.
La siguiente imagen muestra un ejemplo de backlog en Jira donde se hace uso de Epicas, historias, tareas e incidencias.
Vista de Backlog en Jira
Al entrar en el modo de visualización “Trabajo Pendiente” se puede ver el sprint activo y el backlog. Seleccionando la opción “Épicas”, podemos desplegar la lista de las mismas, editarlas o ver el resumen de la épica desglosada como se muestra en la figura. Una épica como cualquier tarea en Jira tiene asignado un número.
El modo de visualización de épicas es de gran ayuda a la hora de gestionar el backlog dado que permite crear y editar las historias de las mismas. Al asociar una historia a una épica, se añade una “etiqueta” con el nombre de la épica como puede verse con la historia “unificar librería” y las tareas 5 y 10. En esta vista también podemos asignar versiones a las historias o tareas como puede verse en la tarea “111” que está asignada a la versión 3.4.8.
Se puede observar también tres tipos de items (ver números en la figura)
- Historia de usuario.
- Tarea
- Incidencia
En Jira, se pueden asignar puntos de historia a las Historias de Usuario y a las Tareas.
TIP: Para una mejor organización y visualización de las historias es aconsejable asignar diferentes colores a las épicas
Edición de una épica
Para editar la épica, haga click en el color de la misma, como muestra la siguiente figura. Puede cambiar el nombre (El que se muestra en la columna de épicas), ver la tarea en Jira para documentarla o ver estado de la misma o cerrarla con la opción “Marcar como Listo”
Opciones de épica
Las épicas deben ser cerradas tan pronto sean implementadas las historias de usuarios o tareas asociadas. Es aconsejable disminuir el número de épicas abiertas y procurar cerrar las que llevan mucho tiempo.
TIP: Hay que hacer revisión del estado de las épicas y cerrarlas cuando estén completadas.
En mi caso, si el equipo de desarrollo además lleva incidencias, problemas y evolutivos he optado por tener dos épicas activas. Aunque no son épicas en si misma, nos ayudan a filtrar de una manera más rápida las tareas en la pizarra de Scrum que si usáramos
- Mejora Continua: Para tareas, historias o épicas técnicas (no solicitadas por el product owner) que pueden mejorar el producto en si mismo
- O&M (Operación & Mantenimiento): Para tareas que pueden estar asociadas a problemas, peticiones de servicio y demás.
Cómo clasificar un Item como Épica, Historia y Tarea
Este punto puede ser controversial, yo voy a dar mi opinión de como clasificarlas y en que situaciones. El criterio final dependerá del Scrum Master, el equipo y la forma como se gestione el ciclo de vida producto.
Épica
- Petición de negocio de alta complejidad que no puede desarrollarse en un sprint del equipo y debe ser descompuesta en historias. (Ejm, un módulo para gestión de usuarios)
- Petición de servicio de alta complejidad que no puede encajarse en un sprint del equipo y debe ser descompuesta en historias. (Ejm, Instalar, configurar y desplegar un nuevo site con nuestro producto)
- Necesidad de IT compleja que no puede ser resuelta en un sprint (Ejm. Módulo de monitorización de servicios del producto, Refactorización por cambio de arquitectura).
Historias.
- Una petición del PO y añade valor al producto.
- Una necesidad de IT que ha sido “negociada” con el PO y añade valor al producto desde el punto de vista de IT. (Ejm, optimización).
- Una petición de servicio estandar de mediana complejidad que tiene que ser descompuesta en tareas para su gestión.
Tareas
- Si es una petición de negocio, que no añade valor al producto y que debe hacer alguien del equipo, pero se debe hacer para otro propósito (Ejm, sacar un informe, analizar comportamientos)
- Si es una tarea pura de IT que involucra a miembros del equipo y que no añade valor al producto de manera directa. (Ejm. Generar, probar y desplegar una release, generar documentación)
- Si es una petición de negocio de un tamaño tan pequeño que no puede descomponerse en subtareas o no merece la pena. (Ejm, Cambiar un enlace de un menú).
- Si es una petición de servicio estandar de corta duración que atiende el equipo. (Ejm, Cambiar la maquetación de unos mails)
Como regla general, principalmente en las “Historias de Usuario” cuidamos el formato de escritura usando la estructura “Como <cliente> quiero/necesito <algo> para <lograr algo>”, con su respectiva descripción y criterios de aceptación.
Conclusión.
Jira da soporte a la gestión de Épicas, Historias y Tareas en el backlog y en los sprint backlog, de su uso adecuado depende en gran medida la eficacia en la gestión y la organización del equipo. En un post futuro hablaré sobre la gestión del sprint backlog en Jira.
