Clase 5 — Artefactos de Scrum, Estimación y Reuniones del Sprint

Resumen Ejecutivo

La sesión completó el Tema 2 de Scrum, centrándose en los artefactos (Pila de Producto y Pila de Sprint), las cuatro reuniones del marco Scrum (Planificación, Daily, Revisión y Retrospectiva) y el debate sobre técnicas de estimación (puntos de historia vs. horas). Se abordó también el Burn Down Chart como herramienta de seguimiento y extensiones como Scrumban y la combinación Scrum + XP.

Conceptos Clave

Pila de Producto (Product Backlog): Lista ordenada y priorizada de PBIs (Product Backlog Items) que representa todo lo que hay que hacer para construir el producto. Propiedad del Dueño de Producto. ⚠️ EXAMEN
Pila de Sprint (Sprint Backlog): Subconjunto de PBIs seleccionados de la Pila de Producto para una iteración. Gestionada por el equipo de desarrollo. ⚠️ EXAMEN
PBI (Product Backlog Item): Elemento genérico de la pila de producto; no necesariamente una historia de usuario. Puede ser documentación, refactorización, etc.
Historias de usuario INVEST: Independientes, Negociables, Valiosas, Estimables, Small (pequeñas), Testables. ⚠️ EXAMEN
Tareas SMART: Específicas, Medibles, Alcanzables, Relevantes, con Tiempo definido.
Puntos de historia: Miden complejidad relativa, no absoluta. No tienen traslación directa a horas. ⚠️ EXAMEN
Burn Down Chart: Gráfico de seguimiento que muestra el trabajo remanente a lo largo del sprint.
Cono de incertidumbre: Al inicio del proyecto las estimaciones tienen mayor margen de error; se reducen a medida que avanza el proyecto. ⚠️ EXAMEN

Desarrollo del Temario

1. Artefactos de Scrum

Scrum no prescribe cómo gestionar los artefactos, ni qué herramienta usar, ni que se deban emplear historias de usuario. Solo define dos artefactos principales:

Pila de Producto: - Lista ordenada y priorizada de todo lo necesario para construir el producto. - Contiene mayoritariamente requisitos funcionales, pero también tareas de mantenimiento, documentación, refactorización, etc. - Es responsabilidad del Dueño de Producto, quien debe maximizar el retorno de inversión y reducir el time to market. - Debe ser comprensible, bien priorizada, organizada y mantenible (el Scrum Master puede ayudar en esto).

Ejemplo: Un PBI podría ser "Escribir la documentación de usuario de la funcionalidad X" o "Refactorizar el código del módulo Y", no solo historias de usuario funcionales.

Pila de Sprint: - Subconjunto de PBIs que el equipo se compromete a completar en una iteración. - Se construye en la reunión de planificación, negociando entre Dueño de Producto y equipo de desarrollo. - Una vez definida, la gestiona el equipo de desarrollo. ⚠️ EXAMEN - Las historias se descomponen en tareas concretas de ingeniería para facilitar la estimación y el seguimiento.

Scrum no habla de historias de usuario. Las historias de usuario provienen de Programación Extrema (XP), no de Scrum. Scrum solo habla de "Product Backlog Items". ⚠️ EXAMEN

2. Historias de Usuario y criterio INVEST

Formato estándar: Como [rol], quiero [funcionalidad] para [beneficio] (tres elementos).

Ejemplo dado en clase: "Como redactor de la web, necesito poder guardar noticias en la nevera para que puedan publicarlas mis compañeros cuando estoy de vacaciones."

Una historia de usuario no es solo una frase; debe incluir: - Descripción extensa que ayude a comprenderla - Subtareas concretas de implementación - Asignación de responsable - Estimación (en puntos de historia u otra unidad)

Criterio INVEST para historias de usuario: ⚠️ EXAMEN

Letra	Significado	Detalle
I	Independiente	Idealmente sin dependencias entre historias (lo más difícil de lograr)
N	Negociable	Se puede discutir alcance con el Dueño de Producto
V	Valiosa	Debe aportar valor al usuario final
E	Estimable	Si no se puede estimar, probablemente es demasiado grande
S	Small (Pequeña)	Implementable en un sprint
T	Testable	Se puede verificar su correcto funcionamiento

Ejemplo de dependencia: No tiene sentido implementar el login si antes no existe el registro de usuarios. Aunque técnicamente se puede, existe una dependencia lógica.

Criterio SMART para tareas: Específicas, Medibles, Alcanzables, Relevantes, con Tiempo. Las diferencias clave respecto a INVEST: en historias hablamos de estimaciones, en tareas de mediciones. ⚠️ EXAMEN

3. Las cuatro reuniones de Scrum

El sprint es la iteración base: duración fija (1-4 semanas máximo). La duración fija es fundamental porque reduce incertidumbre en las estimaciones — el equipo aprende a calibrar mejor su capacidad al mantener un horizonte temporal constante. ⚠️ EXAMEN

3.1 Planificación del Sprint

Participan: Todos los miembros del equipo Scrum (Dueño de Producto imprescindible).
Objetivo: Definir el alcance de la iteración — qué PBIs pasan de la Pila de Producto a la Pila de Sprint.
Preguntas clave: ¿Qué se puede hacer en este sprint? ¿Cómo alcanzamos el objetivo?
Incluye el refinamiento de la pila de producto: comprensión clara de la especificación.
Los equipos se autoasignan las tareas.

3.2 Daily Scrum (Reunión diaria)

Participan: Equipo de desarrollo (el Dueño de Producto no es necesario). ⚠️ EXAMEN
Duración: Corta, solo actualización.
Tres preguntas:
¿Qué hice ayer? (permite actualizar el Burn Down Chart)
¿Qué voy a hacer hoy?
¿Tengo algún impedimento?
No es un espacio de debate, sino de seguimiento. Los problemas se resuelven después.

3.3 Revisión del Sprint (Review = Demo)

Es la demostración del incremento al Dueño de Producto. ⚠️ EXAMEN
Pueden participar stakeholders y usuarios finales.
Se evalúa si el incremento es aceptable, si cumple expectativas y si puede pasar a producción.

3.4 Retrospectiva

Es una reunión técnica del equipo de desarrollo. ⚠️ EXAMEN
El Dueño de Producto no participa (no le concierne cómo trabaja el equipo internamente). ⚠️ EXAMEN
Reflexión sobre: qué ha ido bien, qué se puede mejorar, herramientas, procesos, estimaciones.
El Scrum Master puede facilitar esta reunión, especialmente en equipos inexpertos.

Diferencia clave Revisión vs. Retrospectiva: La revisión es hacia fuera (mostrar producto al cliente); la retrospectiva es hacia dentro (mejorar el proceso del equipo). ⚠️ EXAMEN

4. Estimación: Puntos de Historia vs. Horas

Los puntos de historia miden complejidad relativa, no duración absoluta. ⚠️ EXAMEN

Engloban: incertidumbre + complejidad + riesgo.
Sirven para comparar PBIs entre sí (uno de 2 puntos es ~el doble de complejo que uno de 1 punto).
Se suelen usar escalas tipo Fibonacci simplificadas o escalas donde cada número duplica/triplica al anterior.
No existe una conversión estándar de puntos de historia a horas.
La estimación la realiza el equipo de desarrollo de forma colegiada, no el Dueño de Producto ni un jefe de proyecto. ⚠️ EXAMEN

Técnicas de estimación mencionadas: Planning Poker, Método Delphi, tallas de camiseta.

Cono de incertidumbre: Al inicio del proyecto, las estimaciones solo son útiles como orientación. A medida que avanza el proyecto y se reduce la incertidumbre, las estimaciones se vuelven más fiables y pueden usarse como compromiso. ⚠️ EXAMEN

Reflexión del profesor: Para proyectos asequibles y sprints cortos, estimar en horas descomponiendo historias en tareas de ingeniería puede ser más práctico, especialmente para equipos inexpertos. "Cada equipo decide lo que mejor le funcione."

5. Burn Down Chart (Gráfico de Quemado)

Herramienta de seguimiento que muestra el trabajo remanente durante el sprint.

Métricas posibles en el eje Y: - Número de tareas pendientes (menos preciso, curva más suave) - Horas de esfuerzo remanentes (más preciso, curva más irregular) - Puntos de historia pendientes - Número de historias completadas

Funcionamiento con sprint de 1 semana (ejemplo): - Lunes: tras la planificación, se registra el total de horas (ej. 120h) - Martes a jueves: se descuentan las horas de tareas completadas cada día - Viernes: idealmente todo completado, se dedica a Revisión + Retrospectiva

La línea de referencia (ideal) es un descenso lineal. La línea real fluctúa según el avance efectivo: - Si está por encima de la ideal → el equipo va retrasado - Si está por debajo → el equipo va adelantado (puede abordar historias adicionales) - Puede subir si se reestima la complejidad de alguna tarea

6. Extensiones de Scrum

Scrumban: Combinación de Scrum + Kanban. Se añade el tablero Kanban (To Do / In Progress / Done) para visualizar el estado de las tareas y detectar cuellos de botella. Kanban = Kan (visual) + Ban (tarjeta). ⚠️ EXAMEN

Scrum + XP (Programación Extrema): Scrum aporta el marco de trabajo (roles, artefactos, reuniones), pero no prescribe prácticas de ingeniería. XP complementa con prácticas concretas como programación en parejas, refactorización, testing, etc. Es habitual que equipos inexpertos empiecen con Scrum y vayan incorporando prácticas de XP. ⚠️ EXAMEN

Preguntas de Autoevaluación

¿Quién es el responsable de gestionar la Pila de Producto y quién gestiona la Pila de Sprint? ¿Qué diferencias hay entre ambas?
Explica el acrónimo INVEST aplicado a las historias de usuario. ¿Cuál de las seis características es, según el profesor, la más difícil de lograr y por qué?
¿Cuáles son las cuatro reuniones de Scrum? Indica en cuáles participa el Dueño de Producto y en cuáles no, justificando la respuesta.
¿Qué diferencia fundamental existe entre la Revisión y la Retrospectiva del Sprint?
¿Por qué los puntos de historia no tienen una equivalencia directa en horas? ¿Qué factores engloban además de la duración?
¿Por qué es importante que los sprints tengan duración fija? ¿Cómo afecta esto a las estimaciones del equipo?
¿Qué es el cono de incertidumbre y cómo se relaciona con la evolución de las estimaciones a lo largo de un proyecto?
Scrum no prescribe el uso de historias de usuario ni de puntos de historia. ¿De dónde provienen las historias de usuario como técnica? ¿Qué es lo que Scrum realmente define?
¿Qué es Scrumban y por qué es habitual combinar Scrum con prácticas de Programación Extrema?
En un Burn Down Chart, ¿qué significa que la línea real esté por encima de la línea ideal? ¿Y por debajo? ¿Qué acciones puede tomar el equipo en cada caso?

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