Jira para Agile: Scrum y Kanban con Casos Reales

Bienvenidos a esta sección. A partir de este punto, dejamos de ver Jira solo como una herramienta y empezamos a usarlo dentro de un marco de trabajo concreto: Scrum. Aquí no vamos a estudiar Scrum como teoría aislada, sino como un sistema vivo que se implementa, se ajusta y se ejecuta dentro de Jira. El objetivo es que entiendas cómo Scrum se traduce en decisiones reales dentro de la herramienta.

Para eso vamos a trabajar con el caso Mandaditos, un proyecto que simula el desarrollo de una aplicación real. A lo largo de esta sección vas a construir el backlog, definir épicas e historias, planificar sprints, ejecutar el trabajo, monitorear avances y cerrar iteraciones. No buscamos que memorices ceremonias, sino que desarrolles criterio: qué entra en un sprint, qué se queda fuera y cómo Jira refleja esas decisiones en el día a día del equipo. Comencemos.

Sesión 0 – Scrum en 10 minutos: marco de trabajo para el caso

En esta sesión introductoria se presenta un repaso ágil y práctico de Scrum, enfocado exclusivamente en los conceptos que se utilizarán en el caso: roles, backlog, sprint, sprint planning, ejecución, review y retrospectiva. No es un curso de Scrum ni una explicación teórica profunda, sino un recordatorio común para que todos los estudiantes partan del mismo marco mental antes de entrar a Jira. El objetivo es que entiendan qué vamos a hacer y por qué, sin distraernos del propósito principal del curso: usar Jira como herramienta de apoyo al trabajo ágil.

Sesión 1 – Presentación del caso Mandaditos

En esta sesión se introduce el caso práctico que guiará toda la sección: Mandaditos, una aplicación de mensajería y encargos locales (farmacia, supermercado, entregas punto a punto). Se explica el contexto del negocio, quiénes son los actores principales (cliente, mensajero, coordinador de mandados) y qué tipo de problemas resuelve el producto. Además, se aclara explícitamente que se trata de un caso pedagógico, con un backlog inicial estructurado, para poder enfocarnos en el uso de Jira sin perdernos en la definición del producto desde cero.

Esta es la primera sesión completamente práctica en Jira. Se crea el proyecto Mandaditos, se define su propósito y se explica brevemente qué significa un proyecto en Jira y por qué todo vive dentro de este contenedor. Aquí se establecen las bases del trabajo: tipo de proyecto, tablero Scrum y participantes. El objetivo de la sesión es que el estudiante entienda que antes de crear historias o sprints, es necesario construir el espacio donde el equipo va a trabajar.

En esta sesión se realiza el trabajo central del Product Owner dentro de Jira: crear las épicas del producto y las historias de usuario asociadas, basadas en el caso Mandaditos. Se utiliza el archivo de Excel como referencia, explicando claramente que los estudiantes pueden seguirlo tal cual o adaptarlo si lo desean. El foco está en cómo Jira representa épicas e historias, cómo se relacionan entre sí y cómo se organiza un backlog inicial de forma clara y legible.

En esta sesión se simula una reunión de Sprint Planning usando Jira. A partir del backlog creado, se seleccionan únicamente algunas historias de la Épica 1 para el Sprint 1, dejando explícitamente otras historias fuera. Se crea el sprint, se mueven las historias seleccionadas y se explica por qué priorizar también implica decir “no” o “no todavía”. El objetivo es mostrar cómo Jira apoya la toma de decisiones del equipo y refuerza el concepto de alcance limitado por sprint.

En esta sesión cambiamos explícitamente de perspectiva: ya no estamos “definiendo qué se quiere”, sino “cómo lo vamos a ejecutar”. Tomamos las historias que entraron al Sprint 1 y las descomponemos en tareas concretas (y, si aplica, subtareas) desde la mirada del developer. Se aprovecha para mostrar cómo Jira permite bajar de nivel: de épica → historia → tareas. El objetivo es que el estudiante vea cómo una historia de usuario se traduce en trabajo ejecutable y cómo esto se refleja en el tablero sin necesidad de “inventar” código ni desarrollo real.

Aquí entramos al uso más “vivencial” de Jira: ejecutar el sprint. Se trabaja desde el tablero moviendo tarjetas entre estados (por hacer → en progreso → hecho), asignando responsables y actualizando elementos para simular avance real. En un punto de la sesión se introduce un evento no planeado: aparece un bug/incidencia (por ejemplo, dirección inválida o producto no disponible) y se crea un issue de tipo bug relacionado a la historia correspondiente. El objetivo es mostrar cómo Jira captura lo inesperado sin romper el sprint y cómo se mantiene trazabilidad cuando surgen problemas.

En esta sesión se construye un dashboard sencillo y útil desde la perspectiva del Product Owner: algo que permita ver progreso, carga y posibles riesgos sin necesidad de memorizar métricas complejas. Se configuran uno o dos gadgets/gráficos relevantes y se muestra cómo leerlos como señales: “vamos bien”, “nos estamos atrasando”, “hay bloqueos”, “hay demasiado trabajo en progreso”, etc. El objetivo no es enseñar reporting avanzado, sino mostrar cómo Jira apoya el seguimiento y la conversación con stakeholders con información visual.

En esta sesión se cierra el Sprint 1 y se aprovecha para amarrar un concepto que suele confundir: que algo esté en “Done” en el tablero no siempre equivale a estar “cerrado” con la resolución correcta. Se muestra cómo manejar el cierre formal, qué significa “Resolution” en Jira y cómo conectarlo con la Definition of Done (DoD) como regla del equipo. El objetivo es que el estudiante entienda el cierre como disciplina: completar trabajo, documentar lo necesario y dejar trazabilidad, especialmente cuando hubo incidencias.

Bienvenidos a esta última sección del curso. Antes de entrar, quiero ser muy transparente contigo: si la “joya de la corona” de este curso era dominar Jira aplicado a Scrum y entender con criterio cuándo usar Scrum y cuándo usar Kanban… eso ya lo logramos en la sección anterior. Esa parte es el núcleo del curso, lo más importante, y lo que más valor te va a generar en la vida real.

Entonces, ¿qué es esto? Esto es un bono. Un extra. Una capa adicional para quienes quieren ir un paso más allá y ver Kanban ya aterrizado en Jira, con enfoque de operación y soporte. Si tú viniste principalmente por Scrum, y con lo que ya viste te sentís satisfecho, perfecto: podés marcar esta sección como vista sin culpa y cerrar el curso con tranquilidad. En serio, ya tenés lo esencial.

Ahora, sí querés aprovechar el bono, aquí es donde empezamos a pensar como equipos que ya liberaron un producto y viven con trabajo reactivo: bugs, incidencias, soporte, ajustes, y mejoras que llegan todo el tiempo. Vamos a ver Kanban en su hábitat natural: flujo continuo, control de capacidad y disciplina para no saturarnos. Aquí vas a entender por qué el trabajo en proceso no es un “capricho”, sino la condición para que el trabajo avance.

Y lo vamos a hacer con casos prácticos. Primero, conectamos Kanban con el caso Mandaditos. Luego, en la asignación te llevo a un escenario de soporte con PagaFácil, donde ya existe backlog real: errores y mejoras priorizadas. La meta de esta sección es que no solo “sepas qué es Kanban”, sino que puedas montarlo en Jira y usarlo para mantener estabilidad, enfoque y ritmo de entrega. Comencemos.

Sesión conceptual basada en un problema concreto de desarrollo de software: cuando el trabajo es reactivo (bugs, soporte, ajustes) y los sprints se rompen. Explicamos, con ejemplos de Mandaditos, cuándo conviene Scrum (construcción iterativa de funcionalidades) y cuándo conviene Kanban (flujo continuo y control de capacidad).

Sesión práctica donde creamos un proyecto Kanban separado para Mandaditos “en producción” (soporte/mantenimiento). Configuramos el board con columnas coherentes (Pendiente → En curso → En validación → Hecho) y cargamos issues realistas (bugs, tasks, improvements) para trabajar con un flujo continuo.