¿Cómo elegir una herramienta de gestión de backlog?

por diego octubre 16, 2021 octubre 17, 2021 Agile, Scrum

En este artículo se expone un opción práctica de selección de backlog basada en dos criterios: facilidad de uso y cantidad de información que aportan al proyecto durante la ejecución y después de la misma.

He escogido estos dos criterios, aunque soy consciente que pueden haber muchos otros como el coste, tamaño del equipo, ubicación de las personas, nivel de madurez del equipo u otras.

Gestión de Backlog en Agile

En las metodologías o frameworks ágiles como Scrum no se especifica cómo gestionar un backlog de producto o qué herramienta utilizar. Este aspecto queda a libre elección del equipo que debe elegir cual es la que mejor se adapta a sus necesidades y la que mayor aporta a la mejora de la calidad del producto.

Existen muchas alternativas para gestionar un backlog de producto, por ejemplo usando post-it en tableros físicos, herramientas Kanban como KanbanFlow o Trello o herramientas más complejas como Jira o Redmine. Cada una de ellas tienen un conjunto de ventajas con respecto a las otras desde el punto de vista de los criterios elegidos.

En este artículo nos enfocaremos en estos tres tipos: Post-it con tableros físicos, herramientas software tipo Kanban y herramientas de gestión de desarrollo de software con soporte para Scrum o Kanban.

Gestionar un backlog con post-it

Gestionar un backlog con post-it es muy fácil, totalmente ágil y versátil, se requiere una inversión muy pequeña y requiere poco mantenimiento.

Un tablero físico lleno de post-its aunque es fácil de usar, no permite hacer un seguimiento adecuado del histórico del proyecto y la documentación o conocimiento que se puede extraer es muy poca.

En mi opinión, debería ser usado para proyectos de software pequeños, iniciativas cortas o para coordinar iniciativas a alto nivel.

Gestionar un backlog con herramientas Kanban

Las herramientas tipo Kanban son más potentes y son muy utilizadas para gestionar los backlogs. Existen aplicaciones como Trello o KanbanFlow que ofrecen versiones gratuitas que pueden ser suficientes para gestionar un backlog y además ofrecen versiones de pago con funciones avanzadas.

Estas herramientas son bastante fáciles de utilizar y son una gran alternativa a los post-it en formato digital y desde el punto de vista de documentación permiten añadir muchísima más información como descripciones, comentarios, notas, attachments, etc a los items permitiendo enriquecer la información del proyecto.

Las herramientas de Kanban en mi opinión dificultan

Desde mi punto de vista, estas herramientas son adecuadas para proyectos medianos, con pocas personas y donde no se requiera un seguimiento importante de documentación o conocimiento generado por un proyecto.

Gestionar el backlog con una herramienta de gestión de proyectos

Herramientas como Jira o Redmine dan soporte para trabajar con un framework como Scrum o Kanban y ofrecen mayores posibilidades a la hora de gestionar los items del backlog.

Gestión de backlog con Jira — Backlog Jira

Estas herramientas tienen una curva de aprendizaje mayor, aunque al estar pensadas para gestión de desarrollo de software permiten añadir a los items una gran cantidad de información (estados, prioridades, tags, versiones, componentes, sprint, seguidores, etc), permiten colaborar entre diferentes participantes y gestionar diferentes ciclos de desarrollo aportando de esta forma mayor información del desarrollo del producto.

¿Qué herramienta de backlog escoger?

En la siguiente imagen se resume la posición de cada tipo de herramienta según los criterios de facilidad e información que puede obtenerse del backlog de producto (items nuevos y realizados)

Esta valoración está basada en mi experiencia desarrollando productos de software con equipos de diferentes tamaños y con proyectos de diferente alcance.

El criterio de facilidad uso se basa la observación de que tan fácil se adapta el equipo a la herramienta y que tan fácil es definir una metodología de uso de la misma.

El criterio de información se basa en la cantidad de datos que se puede añadir a un ítem para enriquecer su información, la capacidad de colaboración durante la ejecución y la capacidad de recuperación de información a futuro.

Desde mi punto de vista, en el desarrollo de producto, los ítems de backlog representan la historia del producto y de su información puede extraerse mucho conocimiento y a la vez servir de documentación.

En el gráfico, se puede observar que desde el punto de vista de facilidad de uso, los post-it son los más sencillos de utilizar comparado con herramientas de gestión como Jira o RedMine.

Desde el punto de vista de cantidad y calidad de información que se puede añadir y aportar en un ítem de producto se ve como un post-it por su propia característica ofrece poca capacidad de manipular información y sobre todo persistencia, en cambio, herramientas como Jira o Redmine permiten tener ítems de backlog más enriquecidos.

Las herramientas de Kanban están en un punto medio en ambos criterios.

Mi recomendación:

Para gestionar tareas personales: Usar una herramienta software kanban
Para gestionar iniciativas a alto nivel: Usar una herramienta software kanban
Para gestionar proyectos de desarrollo de software pequeños (un mes o dos): Usar Kanban.
Para productos de software de largo recorrido: Usar Jira, Redmine o similares

Como veis, no recomiendo los post-it en general para gestionar proyectos de desarrollo de software y sé que los defensores de Agile no estarán de acuerdo conmigo. O por el contrario, puedo decir, usad post-it, si no os importa que se pierdan y la información que contengan no sea valiosa en el futuro del proyecto o para sacar indicadores.

Gestiona de tareas de backlog de producto

por diego marzo 19, 2021 octubre 16, 2021 Agile, personas y equipos, Scrum

En prácticamente todos los sitios en los que he estado he encontrado un denominador común en la gestión de tareas de desarrollo a través de los sistemas de gestión como Jira, Redmine o cualquier otro. Este denominador es una falta de detalle en la gestión de las tareas al margen del framework o metodología de trabajo que utilicen ya sea Scrum, Kanban, o una muy particular..

Me voy a referir a la gestión de tareas en términos generales, aunque en el framework como Scrum estas puedan ser una historia de usuario, una épica, una Tarea, una Incidencia o una tarea Técnica y en otros equipos puedan ser una nueva funcionalidad, mejora, un Error, etc.

En este post quiero comentar algunos de los motivos que he escuchado de porqué no se gestionan correctamente las tareas y os comparto algunas de las razones por las que creo que es importante hacerlo correctamente.

¿A qué me refiero con una falta de detalle en la gestión de tareas? He aquí algunos puntos que suelo ver en una tarea mal gestionada.

Asignación incorrecta de tipología (historia, épica, tarea, incidencia)
Estados incorrectos de estado.
Falta o asignación incorrecta de propietarios.
Asignación incorrecta de prioridad.
Ausencia total de comentarios
Ausencia de criterios de aceptación.
Ausencia de imputación de tiempo.

Motivos por los que no se gestionan bien las tareas

Cuando he preguntado a los líderes de IT o a los desarrolladores, encuentro respuestas como las siguientes:

No tengo tiempo.
No hay procedimientos definidos.
No es necesario.
Es una pérdida de tiempo
No sé cómo hacerlo mejor.

No hay tiempo

Es la excusa más generalizada. Estamos perdidos en el día a día y se considera que no hay hueco para documentar una tarea. Muchos desarrolladores se limitan a cerrar la tarea sin más, si es que llegan a hacerlo, sin añadir un comentario, información de pruebas, etc.

No hay procedimientos definidos

En muchos equipos no se ha creado una cultura de gestión de tareas y es normal que los miembros del equipo no lo hagan por iniciativa propia. A veces se cree que una herramienta lo soluciona todo y no es así. Una herramienta requiere además de su funcionalidad, unas reglas de uso para poder sacar el mejor partido de la misma.

No es necesario.

Muchos desarrolladores ven las gestión de tareas como algo sin sustancia, creen que solo tienen que hacer una acción, ejecutarla y cerrarla sin llegar. El título y la descripción ya lo dicen todo y si está cerrada es porque se ha hecho, ese suele ser su planteamiento.

Es una pérdida de tiempo

Algunas personas ven el proceso de gestionar las tareas tedioso y una pérdida de tiempo total. Lo ven como algo burocrático y que no merece la pena. Sienten que necesitan dedicar el tiempo a programar, más que a documentar una tarea.

No sé cómo hacerlo mejor

Esta es otra respuesta típica. Todos sabemos que es una tarea y posiblemente hasta sabemos como escribir una historia (El titulo) y su descripción, pero poco sabemos sobre los procesos de gestión de tareas de desarrollo de software y los posibles ciclos de vida.

¿Qué gano cuando una tarea está bien documentada?

Para mi la buena gestión de tareas de desarrollo está alineado con el grado de madurez del equipo y con los procesos de mejora continua. Algunos de mis pensamientos en esta línea son.

Las tareas bien documentadas son una fuente rica de información para el presente y para el futuro
Diego Acosta

Una tarea bien documentada es una herramienta de comunicación excelente entre los peticionarios y los ejecutores.
Diego Acosta

La buena gestión de una tarea nos ayuda a documentar la historia de un producto
Diego Acosta

A continuación listo parte de la información que nos podría brindar una tarea cuando la vemos en el sprint backlog cuando la documentamos bien.

Conocer quién o quienes han ejecutado
Conocer qué prioridad tiene o tenía cuando se ejecutó.
Conocer el objeto o propósito de la tarea de forma clara
Conocer el origen, la motivación o el contexto dentro del cual fue solicitada
Saber qué decisiones se han tomado sobre la misma durante el proceso de desarrollo
Conocer el alcance y cumplimiento
Conocer cuales son los criterios de aceptación y sus variaciones si las hubiera.
Saber si hubo algún problema y su resolución
Saber si se hubo un cambio el alcance
Saber si hay alguna tarea relacionada con mas información
Conocer si forma parte de una tarea más grande
Saber si está bloqueada y porqué está bloqueada.
etc.

Una tarea bien documentada aporta conocimiento durante el desarrollo y a futuro. Es una inversión para cualquier desarrollo que tenga previsto un roadmap relevante o que forme parte de un producto.

En la gestión de incidencias y problemas es una fuente de información donde puedes encontrar que se ha hecho para solucionarlo, el análisis del problema y todos las posibles soluciones planteadas y cuáles de ellas funcionaron o no.

Por otro lado, tener un sistema de gestión de tareas bien organizado y trabajado es fuente de indicadores de gestión que pueden ayudar a la mejora continua mediante la medición de ciertos indicadores.

Por ejemplo

Número de historias que aportan valor se han terminado
Número de incidencias reportadas
Tiempo efectivo de desarrollo
Número de tareas bloqueadas.
Tiempo medio de resolución
etc.

Conclusión

Desde mi punto de vista, gestionar una tarea es una labor en la que todos los miembros del equipo deben estar involucrados, desde el Product Owner, Scrum Master y desarrolladores y debe verse como un proceso estandarizado dentro del equipo que debe incorporase mediante ciclos de mejora continua.

Si mejoráis la gestión de las tareas vais a notar un cambio en vuestro día a día y os ayudará a sacar un mejor producto.

Manteniendo el ritmo de los sprint en teletrabajo

por dacosta51 abril 5, 2020 abril 5, 2020 Agile, Scrum

En estos días donde el confinamiento por el COVID-19 nos ha “forzado” a cambiar la forma de trabajo de un modelo basado en la presencia a un modelo de teletrabajo es importante realizar ciertos ajustes a las formas de trabajo para intentar que el ritmo no pare o se vea afectado.

El primer impacto lo puede sufrir un equipo que trabaje con scrum y pizarras físicas usando post-it. Al teletrabajar no se tendrá acceso a la pizarra por todo el equipo y es necesario sustituirlo por un sistema digital ya sea usando pizarras kanban, por ejemplo usando Trello o Kanbanflow. O usando herramientas de gestión de tareas como Jira o RedMine para gestionar las tareas. Esto obliga al equipo a mejorar la gestión de las tareas para hacer un correcto seguimiento online.

Una vez se dispone del mecanismo de gestión de tareas vienen los eventos de scrum, en este ámbito es importante que se coordinen reuniones virtuales usando herramientas de conferencia online como meet , skype, etc. El equipo debe mantener la rutina habitual de hora y duración. El scrum master debería actuar como dinamizador y promover la unificación y forma de uso de la herramienta por todos los integrantes del equipo.

Al no disponer de espacios físicos para analizar las historias o desarrollarlas, se puede recurrir nuevamente a las videoconferencias para llevar a cabo sesiones de refinamiento. Es importante y debería serlo en el trabajo presencial que el Product Owner desarrolle lo mejor posible las historias para que de lugar a menos dudas de interpretación y de esta forma los análisis sean más eficientes por parte del equipo.

El equipo de desarrollo puede sustituir la comunicación diaria a través de canales virtuales de slack o whatsapp que les permitan interactuar, resolver dudas o ayudar a desbloquear situaciones. La actitud frente a la comunicación online debe ser proactiva por parte de los miembros del equipo para mantener una dinámica que de la sensación de “estoy aquí” a los demás miembros.

Otro elemento muy importante que puede ayudar a facilitar la interacción con el equipo es el trabajo colaborativo mediante herramientas como google drive. Una combinación de drive y meet puede ayudar a sustituir las pizarras físicas usando documentos como google doc o google draw. En ellos se puede escribir y hacer diagramas que nos pueden ayudar a desarrollar ideas.

Además de todos estos elementos tecnológicos y dada la situación de confinamiento creo que es importante apoyar también el estado psicológico de cada miembro del equipo usando pequeños protocolos de consulta por el bienestar de todos y promoviendo ciertas actividades o reuniones al margen de lo meramente laboral. Un café, un desayuno virtual puede ayudar a relajar la tensión que origina el no poder estar físicamente y de esta forma subir la moral del equipo.

Mucho ánimo a todos aquellos que han trasladado su trabajo a casa, vividlo con la mayor pasión posible, no dejéis que decaiga el ánimo. Cada día prepárate como si tuvieras que desplazarte, organiza tu espacio y gestiona tus tiempos. Esta situación pasará y todos habremos aprendido un poco de esta experiencia. Espero que en vuestras familias todos estén muy bien.

Scrum con Jira – Relación entre Épicas, Historias y Tareas Técnicas.

por diego diciembre 10, 2017 diciembre 11, 2017 Agile, Scrum

Como se comentó en un post anterior, Jira permite trabajar con Épicas, Historias y Tareas en el backlog. En este post se explicará la relación entre las mismas. Para entenderlo mejor, he elaborado el siguiente gráfico.

Épicas, Historias y Tareas Técnicas

Como puede verse, una Épica puede ser descompuesta en múltiples Historias de usuario y a su vez, estas historias de usuario se descomponen en tareas técnicas.

Épica

Una Épica puede ser vista como una historia de usuario de alta complejidad (petición de negocio de alto nivel y complejidad, no clara). Para elaborarla se puede requerir un esfuerzo muy grande y no puede ser cubierta en un Sprint. Una épica debido a su gran tamaño es difícil de estimar y de acometer, así que podemos aplicar aquí el principio “divide y vencerás” y descomponerla en historias. Implementar una épica suele llevar dos o más sprints.

Ejemplos de Épicas.

Como usuario quiero poder registrarme y tener una cuenta de usuario para poder acceder a mi información de usuario y de los servicios que uso.
Como usuario quiero un servicio de “lista de deseos” para poder guardar los artículos que me gustan.

Historia de Usuario

Una historia de usuario representa una necesidad de negocio que puede ser implementada en un sprint y aporta valor al producto. Al final del Sprint la historia añade una nueva funcionalidad o característica al producto y puede ser candidata para pasar a producción.

En el backlog pueden haber historias de usuario sueltas o historias de usuario asociadas a épicas, ambas deben poderse terminar en un sprint, si no pueden terminarse en un sprint, deben ser descompuestas en historias de usuario más pequeñas.

Un patrón típico de definición de historias de usuario es el siguiente (1).

“Como [un] [tipo de usuario] [quiero, puedo, necesito, etc] para [alguna razón].”

La redacción de la historia en esta forma permite identificar rápidamente para “quien” es esa funcionalidad y cual es el objetivo que se persigue o que gana ese usuario. Es un formato que facilita la comunicación del equipo entero y es fácil de entender por negocio.

Ejemplos

Como [Usuario Anónimo] quiero [poder registrarme en el portal] para [crear una cuenta.]
Como [Usuario Registrado] quiero [poder iniciar sesión en el portal] para [poder acceder a la información de mis servicios contratados]

No hay una barita mágica ni para redactar historias de usuario, ni para partir épicas en historias de usuario, ni para identificar épicas. Con el tiempo se va ganando destreza identificando épicas, dividiendo épicas en historias y redactando las historias.

Tareas Técnicas

Las tareas técnicas son la descomposición de una historia de usuarios en tareas más manejables que deben ser implementadas para poder implementar la historia durante el sprint. Lo normal es que durante la reunión de sprint planning se hayan identificado estas tareas técnicas. Las tareas técnicas deben ser generadas por el equipo de desarrollo.

Partir una historia en tareas técnicas ayuda a dimensionar mejor el esfuerzo de la historia en puntos.

Aunque no es obligatorio dividir una historia de usuario en tareas técnicas en Jira, puede ser una buena práctica si se quiere llevar un mejor control del desarrollo de la historia o si para implementar una historia se requiere la intervención de varios miembros del equipo.

Ejemplo, en la historia

Como [Usuario Anónimo] quiero [poder registrarme en el portal] para [crear una cuenta.]

Podemos identificar las siguientes tareas técnicas.

Implementar formulario básico para capturar los datos.
Implementar backend para recibir los datos e implementar la lógica de funcionamiento.
Maquetar formulario según diseño previsto.
Diseñar plan de pruebas
Ejecutar plan de pruebas.

Las tareas técnicas no se redactan como historias al estar orientadas a ejecutar acciones y al igual que en las historias o épicas no hay una fórmula para crearlas y dependerá del equipo, del grado de madurez del mismo, de la historia, y de los participantes.

Una guía que suelo usar es que dependiendo del tamaño de la historia se debe descomponer en tareas técnicas, esto ayuda no sólo al desarrollador, sino al líder de IT, al Scrum Master y al PO a ver los avances. Otro elemento que nos puede ayudar a detectar las tareas técnicas son los criterios de aceptación.

Cómo se ven las tareas técnicas en Jira?

Las relación entre tareas técnicas y épicas se ve claramente en la vista del sprint activo dentro de una pizarra de Scrum.

Historias y Tareas Técnicas

Las tareas técnicas se muestran debajo de la historia y se pueden mover a la columna correspondiente dependiendo del estado. Una vez las tareas técnicas están terminadas, Jira sugiere cerrar la historia.

Esta vista puede verse como la representación virtual de la pizarra de scrum física muy utilizada en diferentes equipos y es muy útil para ver el estado del Sprint.

Scrum con Jira – Primeros pasos

por diego noviembre 10, 2016 noviembre 19, 2017 Agile, Scrum

Actualizado, 19/11/2017

Scrum es un framework muy usado actualmente por equipos de desarrollo de software que cae dentro de las prácticas Agiles. Scrum introduce varios conceptos que ayudan a organizar la forma de trabajo, roles, artefactos, eventos y reglas.

Scrum define los lineamientos para trabajar pero no define el cómo implantarlo y es en este punto donde comienzan a surgir dudas a la hora de organizar la información. ¿Cómo hacemos y gestionamos el backlog?, ¿Cómo gestionamos los sprint con nuestra herramienta de gestión de proyectos?, usamos un excel, etc.
En este post y en otros posteriores os voy a compartir mi experiencia de uso de Jira para gestionar proyectos con Scrum, entre ellos, cómo configurar el proyecto, cómo trabajar con los sprint, cómo crear las épicas, etc. Para ello vamos asumir que nuestro proyecto ya tiene un backlog construido y que tenemos proyectados algunos sprint y vamos a iniciar el desarrollo del mismo.

Jira

Jira es una de las herram logo ientas de gestión de proyectos ágiles más usadas por equipos de desarrollo que ofrece todo el soporte para gestionar, planificar, liberar, hacer seguimiento y hacer reporting y ofrece el soporte Agile bajo dos esquemas Scrum y Kanban con su funcionalidad de “Pizarra” o Board , en el caso que nos ocupa trabajaremos con Scrum.

Objetivo del post

El objetivo es cubrir la siguiente necesidad.

Tengo un backlog, he hecho la sprint sprint planning y quiero arrancar mi primer sprint”

Los pasos que vamos a tratar en este post son son los siguientes.

Crear una pizarra Scrum
Crear las historias de usuario
Crear el primer sprint.
Asignar las historias de usuario al Sprint.
Activar el sprint

Se asume que usted ya tiene un proyecto creado en Jira

Crear la pizarra Scrum

Para crear la pizarra simplemente vaya al proyecto que quiere gestionar con Scrum y busque la opción “Pizarra” como se muestra en la figura.

Opción de menú “pizarra” en Jira

Haga clic en la opción “Pizarra”, Aparecerá un menú desplegable, seleccione la opción “Crear Pizarra” y nos mostrará un dialogo donde podemos elegir el tipo de pizarra que queremos. y seleccionaremos la opción “Crear una pizarra de Scrum”.

Crear pizarra Scrum en Jira

La pizarra puede ser creada de un proyecto existente o de un filtro existente de tareas. Para nuestro caso, seleccionaremos la opción “Pizarra de un proyecto existente”.

Selección de proyecto o filtro

Posteriormente, seleccione el proyecto y escriba el nombre de la pizarra.

Escriba el nombre de la pizarra y seleccione el proyecto

Esto nos crea una vista de pizarra Scrum donde podemos ver en la barra lateral unos íconos de arriba a abajo desde donde apunta la flecha roja que son el backlog, la vista de sprint backlog, los informes, los componentes y las incidencias. Principalmente interactuaremos con los dos primeros.

El Backlog

Menú lateral Jira

La vista de backlog (Trabajo pendiente) nos permite ver las historias de usuario del sprint activo, sprints siguientes e interactuar con las tareas del backlog. Esta vista nos permite rápidamente gestionar la creación y edición de historias de usuario, la asignación de puntos de historia, etc.

TIP!!!:Una cosa importante de cara a gestionar las tareas con Scrum en Jira es que las tareas deben ser creadas del tipo historia de usuario y deben tener previamente asignados los puntos de historia, una vez incorporados a un sprint y activado este ya no es posible cambiar el valor de los puntos de historia.

En la vista de backlog además podemos crear los sprint, organizar las tareas del backlog y asignarlas al sprint (arrastrando las tareas) lo que hace muy sencillo priorizar las historias y armar un sprint backlog. La siguiente imagen nos muestra la vista de trabajo pendiente o backlog.

Una historia puede crearse dentro de un sprint no activo o en el backlog (Create Issue), o crearse en el backlog para luego arrastrarla y soltarla en un sprint.

TIP: Puedes tener tantos sprint como quieras, aunque no es recomendable tener más de dos y uno de ellos activo.

Una vez tenga el sprint completo, puede activar o iniciar el sprint “Iniciar Sprint” donde podrás fijar la fecha de inicio y fin del mismo. También puede cambiar el nombre del sprint haciendo click sobre el nombre del mismo.

Trabajos Pendientes – Backlog

En la parte superior aparecen los filtros rápidos, los cuales pueden ser configurados dentro de la configuración de la pizarra que veremos en post posteriores.

Si tenemos los Sprint activos, hacemos click en el ícono , esta vista nos facilita ver y gestionar las historias de usuario y las tareas técnicas asociadas a las historias de usuario.

El Sprint Activo

La siguiente figura muestra la vista de un sprint activo, en ella podemos observar las columnas que representan los estados en los que se encuentran las tareas de cada historia de usuario. Para cambiar de estado simplemente se arrastran de una columna a otra.

Sprint Activo

Esta vista “sustituye” a nivel software lo que sería la pizarra scrum donde están las historias de usuario y las tareas en los estados en los que se encuentran. Es de gran utilidad aunque he de reconocer que no es fácil acostumbrarse visualmente a ella, la vista que se muestra en la figura agrupando las tareas por historia es la que al final me ha parecido más cómoda.

Espero que este post le sirva para dar el primer para crear la pizarra, crear las tareas del backlog, los sprint, asignar las historias de usuario a los sprint y a activar el sprint. En un siguiente post vamos a ver como crear las tareas técnicas y las épicas.