Clase 4 — Scrum en la práctica — Historias de Usuario, Kanban y Burn Down Chart

Resumen Ejecutivo

La sesión se centró en los elementos prácticos de Scrum aplicados a un proyecto de buscador de precios de combustible: cómo redactar correctamente historias de usuario, cómo construir y gestionar un tablero Kanban, y cómo elaborar e interpretar un Burn Down Chart para el seguimiento del sprint. Se realizó además un ejercicio de brainstorming para generar la pila de producto del proyecto, ilustrando las dificultades reales de la especificación de requisitos.

Conceptos Clave

Historia de Usuario: Formato estándar para expresar requisitos en la pila de producto: "Como [rol], quiero [funcionalidad] para [beneficio]"
Pila de Producto (Product Backlog): Lista priorizada de todas las historias de usuario del proyecto
Pila de Sprint (Sprint Backlog): Subconjunto de historias seleccionadas de la pila de producto para un sprint, descompuestas en tareas con estimación en horas
Tablero Kanban: Panel visual con columnas (Pendiente, En curso, Completado) que muestra el estado de las tareas
Burn Down Chart (Gráfico de Quemado): Gráfico que representa el trabajo restante (eje Y, en horas) frente a los días del sprint (eje X)
Daily (Reunión Diaria): Reunión breve al inicio de cada jornada donde cada miembro dice qué hizo, qué hará y qué impedimentos tiene
Refinamiento de historias: Proceso de descomponer historias grandes en historias más pequeñas y atómicas

Desarrollo del Temario

1. Redacción de Historias de Usuario

Las historias de usuario siguen el formato tripartito: "Como [rol], quiero [funcionalidad], para [beneficio]" ⚠️ EXAMEN

La tercera parte ("para [beneficio]") es frecuentemente olvidada pero cumple funciones críticas: - Ayuda a comprender el porqué de la funcionalidad - Permite evaluar si la historia es realmente necesaria o prioritaria - Facilita el refinamiento y la descomposición en historias más pequeñas

Ejemplo: "Como usuario de la tienda online, quiero un botón para ordenar por precio los artículos, para poder localizar los más económicos." Ejemplo: "Como administrador de la tienda online, quiero obtener un listado mensual de pedidos, para hacer un seguimiento de las ventas."

Características de una buena historia de usuario: ⚠️ EXAMEN - No debe prescribir la implementación (no mencionar botones, tablas, elementos de interfaz concretos) - Debe ser pequeña y atómica: cuanto más pequeña, más fácil de estimar y de encajar en un sprint - Debe ser comprensible por el equipo para poder estimarla - Puede tener documentación adicional por detrás (criterios de aceptación, aclaraciones) - Debe centrarse en el QUÉ, no en el CÓMO: los detalles de implementación se resuelven en diseño y desarrollo

Ejemplo de refinamiento: La historia "Buscar los servicios disponibles para elegir según las necesidades" es demasiado vaga. Se puede descomponer en: - "Como empresario, quiero poder enviar los servicios que ofrece mi estación de servicio, para que los usuarios los conozcan." - "Como usuario de la web, quiero poder visualizar los servicios que ofrece una estación de servicio, para saber si me conviene." - "Como usuario, quiero poder buscar todas las estaciones de servicio que ofrecen un servicio en concreto, para encontrar la que más me conviene."

2. De la Pila de Producto a la Pila de Sprint

La pila de producto es una lista priorizada de historias de usuario (puede gestionarse en un Excel sencillo con identificador y prioridad).

Para construir la pila de sprint: ⚠️ EXAMEN 1. Seleccionar las historias más prioritarias de la pila de producto 2. Verificar que no tengan dependencias bloqueantes con otras historias no seleccionadas 3. Descomponer cada historia en tareas concretas 4. Estimar la duración de implementación de cada tarea (en horas) 5. Verificar que la carga total sea asumible por el equipo en el sprint

Error crítico de planificación: La carga de trabajo del sprint debe ser coherente con la capacidad del equipo. ⚠️ EXAMEN

Ejemplo de error: Si el equipo tiene capacidad de 120 horas (4 personas × 6 h/día × 5 días) y el sprint solo se carga con 40 horas de trabajo, es una planificación absurda: un tercio de la capacidad queda sin utilizar. La carga debe aproximarse a la capacidad disponible, pudiendo dejar una pequeña holgura (especialmente al inicio del proyecto para no ser demasiado optimistas).

3. El Tablero Kanban

El Kanban no es exclusivo de Scrum — proviene de industrias de fabricación tradicionales.

Estructura mínima: tres columnas — Pendiente | En curso | Completado ⚠️ EXAMEN

Puede ampliarse con más columnas: Diseño, Programación, Pruebas, Documentación, Hecho.

Funcionamiento: - Cada fila contiene una historia de usuario con sus tareas - Las tareas se mueven entre columnas a medida que avanzan - Se puede usar un código de colores por desarrollador para visualizar la asignación - Se actualiza después de cada Daily

Sobre la asignación de tareas: - Al inicio del sprint, no todas las tareas están asignadas - En cada Daily, los miembros del equipo eligen qué tareas van a abordar - No se definen roles especializados en el equipo (no "diseñador", "tester", etc.) — todos trabajan para lograr el objetivo del sprint ⚠️ EXAMEN - Lo ideal es que una tarea la haga una sola persona; si se necesitan varias, probablemente la tarea no está suficientemente atomizada

4. El Burn Down Chart (Gráfico de Quemado)

Ejes: ⚠️ EXAMEN - Eje X (abscisas): Días del sprint - Eje Y (ordenadas): Trabajo restante en horas

El valor inicial (punto de partida) es la suma de horas de TODAS las tareas de la pila de sprint — NO la capacidad del equipo. ⚠️ EXAMEN

Contiene al menos dos curvas: 1. Línea de evolución ideal: recta descendente desde el total de horas hasta 0 al final del sprint (velocidad constante) 2. Línea real: se actualiza después de cada Daily, descontando las horas de las tareas completadas enteras

Ejemplo práctico: Sprint con 120 horas de trabajo total. - Lunes (tras Daily): 0 horas completadas → punto en 120h - Martes (tras Daily): se completaron tareas de 5h + 8h + 6h = 19h → punto en 101h - Miércoles (tras Daily): se completaron tareas de 10h + 8h = 18h → punto en 83h

Regla fundamental: solo se descuentan tareas completadas al 100%. No se calculan porcentajes parciales de completitud — eso va contra la filosofía ágil. ⚠️ EXAMEN

Interpretación: - Curva real por encima de la ideal → el proyecto va retrasado - Curva real por debajo de la ideal → el proyecto va adelantado - Picos hacia arriba pueden ocurrir si se descubre un bug o se reestima la duración de una tarea

Sobre los fines de semana: se excluyen sábado y domingo (no se trabaja). En sprints de dos semanas, la gráfica salta del viernes al lunes.

5. Refinamiento y Descomposición de Historias

Principio clave: las historias de usuario deben ser lo más pequeñas posible. ⚠️ EXAMEN

Razones: - Más fácil estimar su complejidad - Más fácil encajarlas en sprints cortos - Reduce la incertidumbre y el debate - Permite mejor seguimiento del progreso

Ejemplo de descomposición: La historia "Obtener las gasolineras en un radio dado y ver sus precios" puede dividirse en: - "Quiero obtener las gasolineras más próximas dentro de un radio centrado en mi ubicación" - "Quiero poder seleccionar mi ubicación con el GPS del móvil" - "Quiero poder introducir una dirección manualmente" - "Quiero ver un mapa para seleccionar la ubicación"

Nótese que una vez implementada la primera, las demás reutilizan lógica existente y son más sencillas.

6. Roles de Usuario y Definición de Perfiles

Es fundamental definir claramente los roles antes de escribir historias. La ambigüedad en los roles genera confusión.

Ejemplo del proyecto: No se había distinguido entre "usuario" y "usuario registrado", lo que generó debate sobre si el registro era necesario para usar la aplicación. Un "visitante" puede convertirse en "usuario" o en "empresario registrado" — son caminos diferentes con necesidades distintas.

Preguntas de Autoevaluación

¿Cuáles son las tres partes de una historia de usuario correctamente redactada y qué función cumple cada una?
Si un equipo de 4 desarrolladores con 8 horas diarias afronta un sprint de 2 semanas, ¿cuál es su capacidad total en horas? Si la pila de sprint suma 100 horas de tareas, ¿cuál es el valor inicial del Burn Down Chart: 100 o 320?
Tras la Daily del martes se han completado tareas por valor de 25 horas de un total inicial de 150. Una tarea de 10 horas está al 80%. ¿Qué valor se marca en el Burn Down Chart y por qué?
¿Por qué es preferible tener historias de usuario pequeñas y atómicas en lugar de historias grandes y generales?
¿Qué diferencia hay entre el valor inicial del Burn Down Chart (suma de horas de las tareas) y la capacidad del equipo? ¿Por qué no deberían coincidir exactamente?
Un equipo tiene una historia que dice "Quiero un botón rojo para filtrar gasolineras baratas". ¿Qué problema tiene esta redacción desde el punto de vista de la ingeniería de requisitos ágil?
¿Qué información comparte cada miembro del equipo en la reunión Daily y cuándo se actualiza el Burn Down Chart en relación con esta reunión?
Si en el Burn Down Chart la curva real se sitúa consistentemente por encima de la línea ideal a mitad del sprint, ¿qué indica esto y qué acciones deberían tomarse?

Guía generada automáticamente a partir de transcripción con faster-whisper + Claude Sonnet.